Initializing a crypto_skcipher_spawn currently requires:
1. Set spawn->base.inst to point to the instance.
2. Call crypto_grab_skcipher().
But there's no reason for these steps to be separate, and in fact this
unneeded complication has caused at least one bug, the one fixed by
commit 6db4341017 ("crypto: adiantum - initialize crypto_spawn::inst")
So just make crypto_grab_skcipher() take the instance as an argument.
To keep the function calls from getting too unwieldy due to this extra
argument, also introduce a 'mask' variable into the affected places
which weren't already using one.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Define struct ahash_instance in a way analogous to struct
skcipher_instance, struct aead_instance, and struct akcipher_instance,
where the struct is defined to include both the algorithm structure at
the beginning and the additional crypto_instance fields at the end.
This is needed to allow allocating ahash instances directly using
kzalloc(sizeof(*inst) + sizeof(*ictx), ...) in the same way as skcipher,
aead, and akcipher instances. In turn, that's needed to make spawns be
initialized in a consistent way everywhere.
Also take advantage of the addition of the base instance to struct
ahash_instance by simplifying the ahash_crypto_instance() and
ahash_instance() functions.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Define struct shash_instance in a way analogous to struct
skcipher_instance, struct aead_instance, and struct akcipher_instance,
where the struct is defined to include both the algorithm structure at
the beginning and the additional crypto_instance fields at the end.
This is needed to allow allocating shash instances directly using
kzalloc(sizeof(*inst) + sizeof(*ictx), ...) in the same way as skcipher,
aead, and akcipher instances. In turn, that's needed to make spawns be
initialized in a consistent way everywhere.
Also take advantage of the addition of the base instance to struct
shash_instance by simplifying the shash_crypto_instance() and
shash_instance() functions.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
To allow further simplifying template ->create() functions, make
crypto_grab_spawn() handle an ERR_PTR() name by passing back the error.
For most templates, this will allow the result of crypto_attr_alg_name()
to be passed directly to crypto_grab_*(), rather than first having to
assign it to a variable [where it can then potentially be misused, as it
was in the rfc7539 template prior to commit 5e27f38f1f ("crypto:
chacha20poly1305 - set cra_name correctly")] and check it for error.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Make crypto_drop_spawn() do nothing when the spawn hasn't been
initialized with an algorithm yet. This will allow simplifying error
handling in all the template ->create() functions, since on error they
will be able to just call their usual "free instance" function, rather
than having to handle dropping just the spawns that have been
initialized so far.
This does assume the spawn starts out zero-filled, but that's always the
case since instances are allocated with kzalloc(). And some other code
already assumes this anyway.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The driver should use GFP_KERNEL for the bigger allocation
during the driver's crypto4xx_probe() and not GFP_ATOMIC in
my opinion.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
With recent kernels (>5.2), the driver fails to probe, as the
allocation of the driver's scatter buffer fails with -ENOMEM.
This happens in crypto4xx_build_sdr(). Where the driver tries
to get 512KiB (=PPC4XX_SD_BUFFER_SIZE * PPC4XX_NUM_SD) of
continuous memory. This big chunk is by design, since the driver
uses this circumstance in the crypto4xx_copy_pkt_to_dst() to
its advantage:
"all scatter-buffers are all neatly organized in one big
continuous ringbuffer; So scatterwalk_map_and_copy() can be
instructed to copy a range of buffers in one go."
The PowerPC arch does not have support for DMA_CMA. Hence,
this patch reorganizes the order in which the memory
allocations are done. Since the driver itself is responsible
for some of the issues.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
->setkey() functions provide more information about errors. But these
flags weren't actually being used or tested, and in many cases they
weren't being set correctly anyway. So they've now been removed.
Also, if someone ever actually needs to start better distinguishing
->setkey() errors (which is somewhat unlikely, as this has been unneeded
for a long time), we'd be much better off just defining different return
values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.
So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that
propagates these flags around.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The CRYPTO_TFM_RES_WEAK_KEY flag was apparently meant as a way to make
the ->setkey() functions provide more information about errors.
However, no one actually checks for this flag, which makes it pointless.
There are also no tests that verify that all algorithms actually set (or
don't set) it correctly.
This is also the last remaining CRYPTO_TFM_RES_* flag, which means that
it's the only thing still needing all the boilerplate code which
propagates these flags around from child => parent tfms.
And if someone ever needs to distinguish this error in the future (which
is somewhat unlikely, as it's been unneeded for a long time), it would
be much better to just define a new return value like -EKEYREJECTED.
That would be much simpler, less error-prone, and easier to test.
So just remove this flag.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to
make the ->setkey() functions provide more information about errors.
However, no one actually checks for this flag, which makes it pointless.
Also, many algorithms fail to set this flag when given a bad length key.
Reviewing just the generic implementations, this is the case for
aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,
rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably
many more in arch/*/crypto/ and drivers/crypto/.
Some algorithms can even set this flag when the key is the correct
length. For example, authenc and authencesn set it when the key payload
is malformed in any way (not just a bad length), the atmel-sha and ccree
drivers can set it if a memory allocation fails, and the chelsio driver
sets it for bad auth tag lengths, not just bad key lengths.
So even if someone actually wanted to start checking this flag (which
seems unlikely, since it's been unused for a long time), there would be
a lot of work needed to get it working correctly. But it would probably
be much better to go back to the drawing board and just define different
return values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.
So just remove this flag.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The flag CRYPTO_TFM_RES_BAD_BLOCK_LEN is never checked for, and it's
only set by one driver. And even that single driver's use is wrong
because the driver is setting the flag from ->encrypt() and ->decrypt()
with no locking, which is unsafe because ->encrypt() and ->decrypt() can
be executed by many threads in parallel on the same tfm.
Just remove this flag.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The tfm result flags CRYPTO_TFM_RES_BAD_KEY_SCHED and
CRYPTO_TFM_RES_BAD_FLAGS are never used, so remove them.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only
fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated
any error as a "bad key length" error. Fix it to correctly propagate
the -ENOMEM error code and not set any tfm result flags.
Fixes: 81d8750b2b ("crypto: atmel-sha - add support to hmac(shaX)")
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The chelsio crypto driver is casting 'struct crypto_aead' directly to
'struct crypto_tfm', which is incorrect because the crypto_tfm isn't the
first field of 'struct crypto_aead'. Consequently, the calls to
crypto_tfm_set_flags() are modifying some other field in the struct.
Also, the driver is setting CRYPTO_TFM_RES_BAD_KEY_LEN in
->setauthsize(), not just in ->setkey(). This is incorrect since this
flag is for bad key lengths, not for bad authentication tag lengths.
Fix these bugs by removing the broken crypto_tfm_set_flags() calls from
->setauthsize() and by fixing them in ->setkey().
Fixes: 324429d741 ("chcr: Support for Chelsio's Crypto Hardware")
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Atul Gupta <atul.gupta@chelsio.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
skcipher_walk_aead() is unused and is identical to
skcipher_walk_aead_encrypt(), so remove it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The use of __sync functions for atomic memory access is not
supported in the kernel, and can result in a link error depending
on configuration:
ERROR: "__tsan_atomic32_compare_exchange_strong" [drivers/crypto/hisilicon/sec2/hisi_sec2.ko] undefined!
ERROR: "__tsan_atomic64_fetch_add" [drivers/crypto/hisilicon/sec2/hisi_sec2.ko] undefined!
Use the kernel's own atomic interfaces instead. This way the
debugfs interface actually reads the counter atomically.
Fixes: 416d82204d ("crypto: hisilicon - add HiSilicon SEC V2 driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
amd-drm-fixes-5.5-2020-01-08:
amdgpu:
- Stability fix for raven
- Reduce pixel encoding to if max clock is exceeded on HDMI
to allow additional high res modes
UAPI:
- enable DRIVER_SYNCOBJ_TIMELINE for amdgpu
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108213649.5485-1-alexander.deucher@amd.com
-sun4i: Fix RGB_DIV clock min divider on old hardware (Chen-Yu)
-fb_helper: Fix bits_per_pixel param set behavior to round up (Geert)
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEHF6rntfJ3enn8gh8cywAJXLcr3kFAl4WQl4ACgkQcywAJXLc
r3kQYwf7Bb+9TIlGf2WTWHbkoPdCN3qgu5XHWGbMv4OjcBVMeBE1+Lx4X5ihwFkC
DuRKvlnW9gfMJg9l+i1PdYuBMFUlcGg3pBmdBEdz0eIZfP0ZL3J9J/s6oZSwuz4v
TDWQEXKD+9MRmR3MtW+C8qIf6EevWHaVZpvvKhmVjf9Sredm2gEQwkBpUXSGGJ/w
FBhvC4zL/iLQOp3wX0sjdnfBc6uXM7JB+mHMXTcAJ3eey9HGAQXQvbWROaTCKuGq
L5hdz4RMiJ8+gTO9tZ6dzlfzZdY/wTQgwdVw3yVeGfeeC32VOjsUGWI5Jpb/SA03
gcHwNt/tMXZ8c0TCq5QNGAoTWUcrrg==
=4GUy
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2020-01-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
mst: Fix NO_STOP_BIT bit offset (Wayne)
sun4i: Fix RGB_DIV clock min divider on old hardware (Chen-Yu)
fb_helper: Fix bits_per_pixel param set behavior to round up (Geert)
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108205949.GA233273@art_vandelay
In some Mediatek SoC, there is no "shadow"
registers for performaing an atomic video mode
set or page flip at vblank/vsync.
The CMDQ (Commend Queue) is used to help
update all relevant display controller registers
with critical time limation.
Signed-off-by: YT Shen <yt.shen@mediatek.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
The CMDQ (Command Queue) in some Mediatek SoC is used
to help update all relevant display controller registers
with critical time limation.
This patch add cmdq interface in ddp_comp interface,
let all ddp_comp interface can support cpu/cmdq function
at the same time.
Signed-off-by: YT Shen <yt.shen@mediatek.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
drm_sched_job_timedout works with drm_sched_stop as a pair,
so we'd better use the drm_sched_fault helper to make the
error and timeout handling go the same path.
This also fixes application hang when task error.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Tested-by: Andreas Baierl <ichgeh@imkreisrum.de>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200101103831.22429-1-yuq825@gmail.com
In my attempt to fix a memory leak, I introduced a double-free in the
pstore error path. Instead of trying to manage the allocation lifetime
between persistent_ram_new() and its callers, adjust the logic so
persistent_ram_new() always takes a kstrdup() copy, and leaves the
caller's allocation lifetime up to the caller. Therefore callers are
_always_ responsible for freeing their label. Before, it only needed
freeing when the prz itself failed to allocate, and not in any of the
other prz failure cases, which callers would have no visibility into,
which is the root design problem that lead to both the leak and now
double-free bugs.
Reported-by: Cengiz Can <cengiz@kernel.wtf>
Link: https://lore.kernel.org/lkml/d4ec59002ede4aaf9928c7f7526da87c@kernel.wtf
Fixes: 8df955a32a ("pstore/ram: Fix error-path memory leak in persistent_ram_new() callers")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
UAPI Changes:
- Allow overriding number of bootup penguins in fbcon using fbcon=logo-count:n.
Cross-subsystem Changes:
- fbdev fixes for mmp, and make it work with CONFIG_COMPILE_TEST.
- Use devm_platform_ioremap_resource in fbdev drivers.
- Various small fbdev fixes.
Core Changes:
- Support scanline alignment for dumb buffers.
- Add atomic_check() hook to bridge ops, to support bus format negotiation.
- Add gem_create_object() to vram helpers.
Driver Changes:
- Rockchip: Add support for PX30.
- Use generic fbdev code and dumb helpers in hisilicon/hibmc.
- Add support for Leadtek LTK500HD1829 panel, and xinpeng XPP055C272.
- Clock fixes for atmel-hlcdc.
- Various smaller fixes to all drivers.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl4UcF4ACgkQ/lWMcqZw
E8PKXQ/8DDTNq4kN7fInb1Bo/X/K5nGPABDrT8RaZn794D0w7WqE8pVQ+sLkAx/Q
m5kNpfulh6ws5eZ/4mhntsKRpMVObfjhUZ4/4XL6BiMW2OmTe0Vv5b/YDmQrW+3H
cANXyrJNWR1mzvU6Z1eFeHMKXcmujyrqxpKGHmeaRxb9dsrlOqpIOzkvRPN1SzWv
4iiblr608uhTy0Df7+3pjjnveq6MWI38lZpezDu8+iEjfQYQH/pIdgC0IK6Ydowp
dyZ2tmJwghag4YIqN62q7uCb1FjPHXrXqq46/U35k6zwrL6FxzP7Q6oLyJW0uEI7
OGfgssiqp4GlVmo6NmBd68orx3WrwloJzz7bIIrgSnfX5hpoDSyErV9bQuvHcsLj
uh6drY+XJaX1zr/i1Jj83ChU81LUIKDsHimbksNcpEiyqgCNnPfmYd8w3YBXoRJW
FA54vv0+IxwWMZS/Ylx66Exxt2kVL7PYuZA529GLBTrLC5PFuwuhEcugmh5LjAXB
TRMCcDf2CTuFMqBipewP+XyonMdoZDHD+dTNfbCgByp1vfyXrzwVV8Py2CLa+JlN
dAEasoI1ENSRu95lYm2Xkbrw0Avqaya2ru8z3wwSnh/bLGoaZkMx/qxamSHXplR5
hR8b86z88LzDy+H2eufCC/KgMopxDJ6x3h2dtuFlFlWQLTY2D6U=
=L7fz
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2020-01-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.6:
UAPI Changes:
- Allow overriding number of bootup penguins in fbcon using fbcon=logo-count:n.
Cross-subsystem Changes:
- fbdev fixes for mmp, and make it work with CONFIG_COMPILE_TEST.
- Use devm_platform_ioremap_resource in fbdev drivers.
- Various small fbdev fixes.
Core Changes:
- Support scanline alignment for dumb buffers.
- Add atomic_check() hook to bridge ops, to support bus format negotiation.
- Add gem_create_object() to vram helpers.
Driver Changes:
- Rockchip: Add support for PX30.
- Use generic fbdev code and dumb helpers in hisilicon/hibmc.
- Add support for Leadtek LTK500HD1829 panel, and xinpeng XPP055C272.
- Clock fixes for atmel-hlcdc.
- Various smaller fixes to all drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8eff1e3f-ef0a-2dd9-9a14-6273b1d6f963@linux.intel.com
The new helper drm_of_lvds_get_dual_link_pixel_order() introduced in
commit 6529007522 has a fallback stub when CONFIG_OF is not set, but
the stub is declared in drm_of.h without a static inline. This causes
multiple definitions of the function to be linked when the CONFIG_OF
option isn't set. Fix it by making the stub static inline.
Fixes: 6529007522 ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191219103703.8547-1-laurent.pinchart+renesas@ideasonboard.com
param->rx_mini_pending is __u32 variable, it will never
be less than zero.
Signed-off-by: yuehaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the driver is built-in but ipv6 is a module, the flower
support produces a link error:
drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.o: In function `nfp_tunnel_keep_alive_v6':
tunnel_conf.c:(.text+0x2aa8): undefined reference to `nd_tbl'
Add a Kconfig dependency to avoid that configuration.
Fixes: 9ea9bfa122 ("nfp: flower: support ipv6 tunnel keep-alive messages from fw")
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the enetc driver is disabled, the mdio support fails to
get built:
drivers/net/dsa/ocelot/felix_vsc9959.o: In function `vsc9959_mdio_bus_alloc':
felix_vsc9959.c:(.text+0x19c): undefined reference to `enetc_hw_alloc'
felix_vsc9959.c:(.text+0x1d1): undefined reference to `enetc_mdio_read'
felix_vsc9959.c:(.text+0x1d8): undefined reference to `enetc_mdio_write'
Change the Makefile to enter the subdirectory for this as well.
Fixes: bdeced75b1 ("net: dsa: felix: Add PCS operations for PHYLINK")
Fixes: 6517798dd3 ("enetc: Make MDIO accessors more generic and export to include/linux/fsl")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use constant EnAnaPLL for bit 14 as in vendor driver. The vendor
driver sets this bit for chip version 02 only, but I'm not aware of
any issues, so better leave it as it is.
In addition remove the useless debug message.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Smatch complains that the NULL checking isn't done consistently:
net/ethtool/strset.c:253 strset_prepare_data()
error: we previously assumed 'dev' could be null (see line 233)
It looks like there is a missing return on this path.
Fixes: 71921690f9 ("ethtool: provide string sets with STRSET_GET request")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
The "ret < 0" comparison is never true because "ret" is still zero.
Fixes: 728480f124 ("ethtool: default handlers for GET requests")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
If ethnl_default_parse() fails then we need to free a couple
memory allocations before returning.
Fixes: 728480f124 ("ethtool: default handlers for GET requests")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Florian Fainelli says:
====================
Broadcom tags support for 531x5/539x families
This patch series finally allows us to enable Broadcom tags on the
BCM531x5/BCM539x switch series which are very often cascaded onto
another on-chip Broadcom switch. Because of that we need to be able to
detect that Broadcom tags are already enabled on our DSA master which
happens to be a DSA slave in that case since they are not part of the
same DSA switch tree, the protocol does not support that.
Due to the way DSA works, get_tag_protocol() is called prior to
ds->ops->setup and we do not have all data structures set-up (in
particular dsa_port::cpu_dp is not filed yet) so doing this at the time
get_tag_protocol() is called and without exporting a helper function is
desirable to limit our footprint into the framework.
Having the core (net/dsa/dsa2.c) return and enforce DSA_TAG_PROTO_NONE
was considered and done initially but this leaves the driver outside of
the decision to force/fallback to a particular protocol, instead of
letting it in control. Also there is no reason to suspect that all
tagging protocols are problematic, e.g.: "inner" Marvell EDSA with
"outer" Broadcom tag may work just fine, and vice versa.
This was tested on:
- Lamobo R1 which now has working Broadcom tags for its external BCM53125 switch
- BCM7445 which has a BCM53125 hanging off one of its internal switch
port, the BCM53125 still works with DSA_TAG_PROTO_NONE
- BCM7278 which has a peculiar dual CPU port set-up (so dual IMP mode
needs to be enabled)
- Northstar Plus with DSA_TAG_PROTO_BRCM_PREPEND and no external
switches hanging off the internal switch
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The BCM531x5 and BCM539x families require that the IMP port be enabled
within the management page and that management mode (SM_SW_FWD_MODE) be
turned on. Once this is done, everything works as expected, including
multicast with standalone DSA devices or bridge devices.
Because such switches are frequencly cascaded with other internal
Broadcom switches on which we want to enable Broadcom tags, update
b53_can_enable_brcm_tags() to check the kind of DSA master tagging
protocol being used, if it is one of the two supported Broadcom tagging
protocols, force DSA_TAG_PROTO_NONE.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is possible to stack multiple DSA switches in a way that they are not
part of the tree (disjoint) but the DSA master of a switch is a DSA
slave of another. When that happens switch drivers may have to know this
is the case so as to determine whether their tagging protocol has a
remove chance of working.
This is useful for specific switch drivers such as b53 where devices
have been known to be stacked in the wild without the Broadcom tag
protocol supporting that feature. This allows b53 to continue supporting
those devices by forcing the disabling of Broadcom tags on the outermost
switches if necessary.
The get_tag_protocol() function is therefore updated to gain an
additional enum dsa_tag_protocol argument which denotes the current
tagging protocol used by the DSA master we are attached to, else
DSA_TAG_PROTO_NONE for the top of the dsa_switch_tree.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current 'tipc_wait_for_connect()' function does a wait-loop for the
condition 'sk->sk_state != TIPC_CONNECTING' to conclude if the socket
connecting has done. However, when the condition is met, it returns '0'
even in the case the connecting is actually failed, the socket state is
set to 'TIPC_DISCONNECTING' (e.g. when the server socket has closed..).
This results in a wrong return code for the 'connect()' call from user,
making it believe that the connection is established and go ahead with
building, sending a message, etc. but finally failed e.g. '-EPIPE'.
This commit fixes the issue by changing the wait condition to the
'tipc_sk_connected(sk)', so the function will return '0' only when the
connection is really established. Otherwise, either the socket 'sk_err'
if any or '-ETIMEDOUT'/'-EINTR' will be returned correspondingly.
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a socket is suddenly shutdown or released, it will reject all the
unreceived messages in its receive queue. This applies to a connected
socket too, whereas there is only one 'FIN' message required to be sent
back to its peer in this case.
In case there are many messages in the queue and/or some connections
with such messages are shutdown at the same time, the link layer will
easily get overflowed at the 'TIPC_SYSTEM_IMPORTANCE' backlog level
because of the message rejections. As a result, the link will be taken
down. Moreover, immediately when the link is re-established, the socket
layer can continue to reject the messages and the same issue happens...
The commit refactors the '__tipc_shutdown()' function to only send one
'FIN' in the situation mentioned above. For the connectionless case, it
is unavoidable but usually there is no rejections for such socket
messages because they are 'dest-droppable' by default.
In addition, the new code makes the other socket states clear
(e.g.'TIPC_LISTEN') and treats as a separate case to avoid misbehaving.
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vikas Gupta says:
====================
Devlink notification after recovery complete by bnxt_en driver
This patchset adds following feature in devlink
1) Recovery complete direct call API to be used by drivers when it
successfully completes. It is required as recovery triggered by
devlink may return with EINPROGRESS and eventually recovery
completes in different context.
2) A notification when health status is updated by reporter.
Patchset also contains required changes in bnxt_en driver to
mark recovery in progress when recovery is triggered from kernel
devlink.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Return EINPROGRESS to devlink health reporter recover as we are not yet
done and call devlink_health_reporter_recovery_done once reset is
successfully completed from workqueue context.
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
add a devlink notification when reporter update the health
state.
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is possible that a reporter recovery completion do not finish
successfully when recovery is triggered via
devlink_health_reporter_recover as recovery could be processed in
different context. In such scenario an error is returned by driver when
recover hook is invoked and successful recovery completion is
intimated later.
Expose devlink recover done API to update recovery stats.
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The rk3399-roc-pc uses a MP8859 DC/DC converter for 12V supply.
This supplies 5V only in default state after booting.
Now we can control the output voltage via I2C interface.
Add a node for the driver to reach 12V.
Signed-off-by: Markus Reichl <m.reichl@fivetechno.de>
Link: https://lore.kernel.org/r/20200106211633.2882-6-m.reichl@fivetechno.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Missing netns context in arp_tables, from Florian Westphal.
2) Underflow in flowtable reference counter, from wenxu.
3) Fix incorrect ethernet destination address in flowtable offload,
from wenxu.
4) Check for status of neighbour entry, from wenxu.
5) Fix NAT port mangling, from wenxu.
6) Unbind callbacks from destroy path to cleanup hardware properly
on flowtable removal.
7) Fix missing casting statistics timestamp, add nf_flowtable_time_stamp
and use it.
8) NULL pointer exception when timeout argument is null in conntrack
dccp and sctp protocol helpers, from Florian Westphal.
9) Possible nul-dereference in ipset with IPSET_ATTR_LINENO, also from
Florian.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The recovery mode pin is currently named 'REC_MODE_L', which is
how the signal is called in the schematics. The Chrome OS ABI
requires the pin to be named 'RECOVERY_SW_L', which is also how
it is called on all other veyron devices. Rename the pin to match
the ABI.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200108092908.1.I3afd3535b65460e79f3976e9ebfa392a0dd75e01@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Jason A. Donenfeld says:
====================
reduce open coded skb->next access for gso segment walking
This patchset introduces the skb_list_walk_safe helper macro, in order
to add some sanity to the myrid ways drivers have of walking through gso
segments. The goal is to reduce future bugs commonly caused by open
coding these sorts of things, and to in the future make it easier to
swap out the underlying list representation.
This first patch series addresses the easy uses of drivers iterating
over the returned list of skb_gso_segments, for drivers that live in
drivers/net/*. There are still other use cases to tackle later for
net/*, and after these low-hanging fruits are taken care of, I imagine
there are more subtle cases of gso segment walking that isn't just a
direct return value from skb_gso_segments, and eventually this will have
to be tackled. This series is the first in that direction.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
