Re: [PATCH] carl9170: remove get_tid_h

On 02/04/2021 23:31, Christophe JAILLET wrote: 'get_tid_h()' is the same as 'ieee80211_get_tid()'. So this function can be removed to save a few lines of code. Signed-off-by: Christophe JAILLET Acked-by: Christian Lamparter --- drivers/net/wireless/ath/car

Re: [PATCH] carl9170: fix struct alignment conflict

ructures to only apply packing where it does not violate the alignment requirement of the contained structure. Signed-off-by: Arnd Bergmann Acked-by: Christian Lamparter I've also applied this patch and a previous one dealing with VLAs to the firmware source at <https://github.com/chunk

Re: [PATCH] wireless: remove unneeded break

On 19/10/2020 17:05, t...@redhat.com wrote: From: Tom Rix A break is not needed if it is preceded by a return or goto Signed-off-by: Tom Rix diff --git a/drivers/net/wireless/intersil/p54/eeprom.c b/drivers/net/wireless/intersil/p54/eeprom.c index 5bd35c147e19..3ca9d26df174 100644 --- a/d

Re: R: [PATCH 2/2] dt: bindings: ath10k: Document qcom, ath10k-pre-calibration-data-mtd

On 2020-09-18 20:31, ansuels...@gmail.com wrote: -Messaggio originale- Da: Christian Lamparter Inviato: venerdì 18 settembre 2020 18:54 A: Ansuel Smith ; Kalle Valo Cc: devicet...@vger.kernel.org; netdev@vger.kernel.org; linux- wirel...@vger.kernel.org; linux-ker...@vger.kernel.org

Re: [PATCH 2/2] dt: bindings: ath10k: Document qcom, ath10k-pre-calibration-data-mtd

On 2020-09-18 18:29, Ansuel Smith wrote: Document use of qcom,ath10k-pre-calibration-data-mtd bindings used to define from where the driver will load the pre-cal data in the defined mtd partition. Signed-off-by: Ansuel Smith Q: Doesn't mtd now come with nvmem support from the get go? So the M

Re: [PATCH v2 08/30] net: wireless: ath: carl9170: Convert 'ar9170_qmap' to inline function

const-variable=] > > NB: Snipped - lots of these repeat > > Cc: Christian Lamparter > Cc: Kalle Valo > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Johannes Berg > Cc: linux-wirel...@vger.kernel.org > Cc: netdev@vger.kernel.org > Suggested-by:

Re: [PATCH][next] carl9170: Use fallthrough pseudo-keyword

-off-by: Gustavo A. R. Silva Acked-by: Christian Lamparter

Re: [PATCH 00/32] Set 2: Rid W=1 warnings in Wireless

On 2020-08-21 09:16, Lee Jones wrote: This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. I see that after our discussion about the carl9170 change in this thread following your patch:

Re: [PATCH 03/16] wireless: ath: convert tasklets to use new tasklet_setup() API

Pais wrote: From: Allen Pais In preparation for unconditionally passing the struct tasklet_struct pointer to all tasklet callbacks, switch to using the new tasklet_setup() and from_tasklet() to pass the tasklet pointer explicitly. Signed-off-by: Romain Perier Signed-off-by: Allen Pais Seems to w

Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as __maybe_unused

On 2020-08-17 14:59, Kalle Valo wrote: Rasmus Villemoes writes: On 14/08/2020 17.14, Christian Lamparter wrote: On 2020-08-14 13:39, Lee Jones wrote: 'ar9170_qmap' is used in some source files which include carl9170.h, but not all of them.  Mark it as __maybe_unused to show that t

Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as __maybe_unused

On 2020-08-14 18:40, Lee Jones wrote: On Fri, 14 Aug 2020, Christian Lamparter wrote: On 2020-08-14 13:39, Lee Jones wrote: 'ar9170_qmap' is used in some source files which include carl9170.h, but not all of them. Mark it as __maybe_unused to show that this is not only okay, it&

Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as __maybe_unused

eless/ath/carl9170/carl9170.h:71:17: warning: ‘ar9170_qmap’ defined but not used [-Wunused-const-variable=] Cc: Christian Lamparter Cc: Kalle Valo Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Johannes Berg Cc: linux-wirel...@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-

[PATCH] net: dsa: qca8k: replace legacy gpio include

egacy") Reported-by: kbuild test robot Link: https://www.spinics.net/lists/netdev/msg584447.html Fixes: a653f2f538f9 ("net: dsa: qca8k: introduce reset via gpio feature") Signed-off-by: Christian Lamparter --- drivers/net/dsa/qca8k.c | 2 +- 1 file changed, 1 insertion(+), 1 delet

Re: [net-next:master 342/422] drivers/net/dsa/qca8k.c:1050:21: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_gpio_request_one'?

(let's hope that the gmail web interface doesn't mangle this too much) On Mon, Jul 8, 2019 at 10:16 AM kbuild test robot wrote: > > tree: > https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next.git > master > head: 61a582be1a668a0c1407a46f779965bfeff88784 > commit: a653f2f

[PATCH v1 1/2] dt-bindings: net: dsa: qca8k: document reset-gpios property

This patch documents the qca8k's reset-gpios property that can be used if the QCA8337N ends up in a bad state during reset. Signed-off-by: Christian Lamparter --- Documentation/devicetree/bindings/net/dsa/qca8k.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Document

[PATCH v1 2/2] net: dsa: qca8k: introduce reset via gpio feature

ffers from detection issues after a SoC reset. Please note that the qca8k_probe() function does currently require to read the chip's revision register for identification purposes. Signed-off-by: Christian Lamparter --- drivers/net/dsa/qca8k.c | 15 +++ drivers/net/dsa/qca8k.h | 2 ++

Re: [PATCH net-next 1/1] net: dsa: qca8k: Fix internal PHY MDIO address

On Thursday, March 21, 2019 8:55:55 PM CET Marek Behun wrote: > Hi, > > Oh, I didn't know about Christian's patch. > > I shall test on our device tomorrow. If it works, we will use internal > PHY access. > > But I think that qca8k_port_to_phy should be used in the external mode > as well. On our

[PATCH v4 3/4] net: dsa: qca8k: remove leftover phy accessors

SA subsystem will create a slave mdio-bus not knowing that the qca8k_phy_(read|write) accessors operate on the external mdio-bus. So the same "bus" gets effectively duplicated. Cc: sta...@vger.kernel.org Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family"

Re: [PATCH net-next 1/1] net: dsa: qca8k: Fix internal PHY MDIO address

On Friday, March 22, 2019 12:01:20 AM CET Marek Behun wrote: > > Hm, it's not really a "external mode". But let's try one more time. > > The idea is that if an external mdio-bus (from the SoC) has already > > registered the PHY 0x0 - 0x4 from the QCA8337, the qca8k should not > > expose the same PH

[PATCH v4 1/4] dt-bindings: net: dsa: qca8k: fix example

In the example, the phy at phy@0 is clashing with the switch0@0 at the same address. Usually, the switches are accessible through pseudo PHYs which in case of the qca8k are located at 0x10 - 0x18. Reviewed-by: Florian Fainelli Signed-off-by: Christian Lamparter --- Documentation/devicetree

[PATCH v4 2/4] dt-bindings: net: dsa: qca8k: support internal mdio-bus

This patch updates the qca8k's binding to document to the approach for using the internal mdio-bus of the supported qca8k switches. Reviewed-by: Florian Fainelli Signed-off-by: Christian Lamparter --- .../devicetree/bindings/net/dsa/qca8k.txt | 69 +-- 1 file change

[PATCH v4 4/4] net: dsa: qca8k: extend slave-bus implementations

n order to prevent a duplicated discovery and enumeration of the same PHYs. Don't use mixed external and internal mdio-bus configurations, as this is not supported by the hardware. Signed-off-by: Christian Lamparter --- Changes from v3: - removed unneccessary PHYAD checks - let dsa subsystem

Re: [PATCH net-next 1/1] net: dsa: qca8k: Fix internal PHY MDIO address

(Bottom post?) On Thursday, March 21, 2019 8:55:55 PM CET Marek Behun wrote: > Hi, > > Oh, I didn't know about Christian's patch. > > I shall test on our device tomorrow. If it works, we will use internal > PHY access. > > But I think that qca8k_port_to_phy should be used in the external mode >

Re: [PATCH net-next 1/1] net: dsa: qca8k: Fix internal PHY MDIO address

On Thursday, March 21, 2019 7:26:08 PM CET Florian Fainelli wrote: > +Christian, > > On 3/21/19 11:23 AM, Marek Behún wrote: > > The MDIO addresses of the internal PHYs on this switch for ports 1-5 > > have addresses 0-4, not 1-5. > > > > Can you provide a Fixes: tag for this? Your change will c

Re: [PATCH v3 3/3] net: dsa: qca8k: extend slave-bus implementations

Sorry. I hit Sent by accident and then I had to run... This is the full response. On Wednesday, March 20, 2019 7:27:09 PM CET Florian Fainelli wrote: > On 3/19/19 12:54 PM, Christian Lamparter wrote: > > This patch implements accessors for the QCA8337 MDIO access > > through

Re: [PATCH v3 3/3] net: dsa: qca8k: extend slave-bus implementations

On Wednesday, March 20, 2019 7:27:09 PM CET Florian Fainelli wrote: > On 3/19/19 12:54 PM, Christian Lamparter wrote: > > This patch implements accessors for the QCA8337 MDIO access > > through the MDIO_MASTER register, which makes it possible to > > access the PHYs on slave-b

[PATCH v3 3/3] net: dsa: qca8k: extend slave-bus implementations

n order to prevent a duplicated discovery and enumeration of the same PHYs. Don't use mixed external and internal mdio-bus configurations, as this is not supported by the hardware. Signed-off-by: Christian Lamparter --- Changes from v2: - Make it compatible with existing configurations - make

[PATCH v3 2/3] dt-bindings: net: dsa: qca8k: support internal mdio-bus

This patch updates the qca8k's binding to document to the approach for using the internal mdio-bus of the supported qca8k switches. Signed-off-by: Christian Lamparter --- .../devicetree/bindings/net/dsa/qca8k.txt | 69 +-- 1 file changed, 64 insertions(+), 5 dele

[PATCH v3 1/3] dt-bindings: net: dsa: qca8k: fix example

In the example, the phy at phy@0 is clashing with the switch0@0 at the same address. Usually, the switches are accessible through pseudo PHYs which in case of the qca8k are located at 0x10 - 0x18. Signed-off-by: Christian Lamparter --- Documentation/devicetree/bindings/net/dsa/qca8k.txt | 4

Re: [PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation

On Wednesday, February 6, 2019 11:29:18 PM CET Florian Fainelli wrote: > On 2/6/19 1:57 PM, Christian Lamparter wrote: > > On Tuesday, February 5, 2019 11:29:36 PM CET Florian Fainelli wrote: > >> On 2/5/19 2:12 PM, Christian Lamparter wrote: > >>> On Tuesday, Fe

Re: [PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation

On Tuesday, February 5, 2019 11:29:36 PM CET Florian Fainelli wrote: > On 2/5/19 2:12 PM, Christian Lamparter wrote: > > On Tuesday, February 5, 2019 10:29:34 PM CET Andrew Lunn wrote: > >>> For now, I added the DT binding update to the patch as well. > >>> Bu

Re: [PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation

On Tuesday, February 5, 2019 10:29:34 PM CET Andrew Lunn wrote: > > For now, I added the DT binding update to the patch as well. > > But if this is indeed the way to go, it'll get a separate patch. > > Hi Christian > > You need to be careful with the DT binding. You need to keep backwards > comp

[PATCH v3] net: emac: remove IBM_EMAC_RX_SKB_HEADROOM

The EMAC driver had a custom IBM_EMAC_RX_SKB_HEADROOM Kconfig option that reserved additional skb headroom for RX. This patch removes the option and migrates the code to use napi_alloc_skb() and netdev_alloc_skb_ip_align() in its place. Signed-off-by: Christian Lamparter --- v2 -> v3: d

Re: [PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation

this is indeed the way to go, it'll get a separate patch. Cheers, Christian --- >From e4951353e5e25f725a777b3a380c16bf55b2b7c1 Mon Sep 17 00:00:00 2001 From: Christian Lamparter Date: Fri, 1 Feb 2019 22:54:32 +0100 Subject: [PATCH v2] net: dsa: qca8k: replace slave-bus implementation The

Re: [PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation

On Tuesday, February 5, 2019 3:45:33 AM CET Andrew Lunn wrote: > On Mon, Feb 04, 2019 at 10:35:55PM +0100, Christian Lamparter wrote: > > The QCA8337 enumerates 5 PHYs on the MDC/MDIO access: PHY0-PHY4. > > Based on the System Block Diagram in Section 1.2 of the > > QCA8337&#x

Re: [PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation

Hello Andrew and Florian. I concated both replies into this post. On Monday, February 4, 2019 11:26:41 PM CET Andrew Lunn wrote: > On Mon, Feb 04, 2019 at 10:35:55PM +0100, Christian Lamparter wrote: > > The QCA8337 enumerates 5 PHYs on the MDC/MDIO access: PHY0-PHY4. > > Base

[PATCH v2] net: emac: remove IBM_EMAC_RX_SKB_HEADROOM

The EMAC driver had a custom IBM_EMAC_RX_SKB_HEADROOM Kconfig option that reserved additional skb headroom for RX. This patch removes the option and migrates the code to use napi_alloc_skb() and netdev_alloc_skb_ip_align() in its place. Signed-off-by: Christian Lamparter --- drivers/net

[PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation

rite() nor the dsa framework is set up for that. This version of the patch uses the existing phy-handle properties of each specified DSA Port in the DT to map each PORT/MAC to its exposed PHY on the MDIO bus. This is supported by the current binding document qca8k.txt as well. Signed-off-by:

[PATCH v1] net: emac: remove IBM_EMAC_RX_SKB_HEADROOM

The EMAC driver had a custom IBM_EMAC_RX_SKB_HEADROOM Kconfig option that reserved additional skb headroom for RX. This patch removes the option and migrates the code to use napi_alloc_skb() and netdev_alloc_skb_ip_align() in its place. Signed-off-by: Christian Lamparter --- drivers/net

[PATCH v4 1/3] net: emac: implement 802.1Q VLAN TX tagging support

E was already enabled. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 32 drivers/net/ethernet/ibm/emac/core.h | 6 +- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/eth

[PATCH v4 2/3] net: emac: implement TCP segmentation offload (TSO)

This patch enables TSO(v4) hw feature for emac driver. As atleast the APM82181's TCP/IP acceleration hardware controller (TAH) provides TCP segmentation support in the transmit path. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c

[PATCH v4 3/3] net: emac: remove IBM_EMAC_RX_SKB_HEADROOM

The EMAC driver had a custom IBM_EMAC_RX_SKB_HEADROOM Kconfig option that reserved additional skb headroom for RX. This patch removes the option and migrates the code to use napi_alloc_skb() and netdev_alloc_skb_ip_align() in its place. Signed-off-by: Christian Lamparter --- drivers/net

[PATCH v3 3/4] net: emac: remove IBM_EMAC_RX_SKB_HEADROOM

The EMAC driver had a custom IBM_EMAC_RX_SKB_HEADROOM Kconfig option that reserved additional skb headroom for RX. This patch removes the option and migrates the code to use napi_alloc_skb() and netdev_alloc_skb_ip_align() in its place. Signed-off-by: Christian Lamparter --- drivers/net

[PATCH v3 2/4] net: emac: implement TCP segmentation offload (TSO)

This patch enables TSO(v4) hw feature for emac driver. As atleast the APM82181's TCP/IP acceleration hardware controller (TAH) provides TCP segmentation support in the transmit path. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c

[PATCH v3 4/4] net: emac: add deprecation notice to emac custom phy users

IS8201, BCM5248, ET1011C, Marvell 88E and 88E1112, AR8035. And Linux has dedicated PHYLIB drivers for all but the BCM5248 which can be supported by the generic phy driver. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/phy.c | 4 1 file changed, 4 insertions(+

[PATCH v3 1/4] net: emac: implement 802.1Q VLAN TX tagging support

E was already enabled. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 32 drivers/net/ethernet/ibm/emac/core.h | 6 +- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/eth

[PATCH v2 1/4] net: emac: implement 802.1Q VLAN TX tagging support

E was already enabled. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 32 drivers/net/ethernet/ibm/emac/core.h | 6 +- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/eth

[PATCH v2 4/4] net: emac: add deprecation notice to emac custom phy users

From: Christian Lamparter This patch starts the deprecation process of emac's small library of supported phys by adding a message to inform all remaining users to start looking into converting their platform's device-tree to PHYLIB. EMAC's phy.c support is limited to mostly

[PATCH v2 2/4] net: emac: implement TCP segmentation offload (TSO)

This patch enables TSO(v4) hw feature for emac driver. As atleast the APM82181's TCP/IP acceleration hardware controller (TAH) provides TCP segmentation support in the transmit path. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c

[PATCH v2 3/4] net: emac: remove IBM_EMAC_RX_SKB_HEADROOM

The EMAC driver had a custom IBM_EMAC_RX_SKB_HEADROOM Kconfig option that reserved additional skb headroom for RX. This patch removes the option and migrates the code to use napi_alloc_skb() and netdev_alloc_skb_ip_align() in its place. Signed-off-by: Christian Lamparter --- drivers/net

Re: [PATCH 1/2] net: emac: implement 802.1Q VLAN TX tagging support

On Wednesday, October 17, 2018 10:09:10 PM CEST Florian Fainelli wrote: > On 10/17/2018 01:08 PM, Florian Fainelli wrote: > > On 10/17/2018 12:53 PM, Christian Lamparter wrote: > >> As per' APM82181 Embedded Processor User Manual 26.1 EMAC Features: > >> VLAN: &g

Re: [PATCH 2/2] net: emac: implement TCP TSO

Hello, On Wednesday, October 17, 2018 10:09:44 PM CEST Florian Fainelli wrote: > On 10/17/2018 12:53 PM, Christian Lamparter wrote: > > This patch enables TSO(v4) hw feature for emac driver. > > As atleast the APM82181's TCP/IP acceleration hardware > > controller (TAH)

[PATCH 1/2] net: emac: implement 802.1Q VLAN TX tagging support

E was already enabled. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 32 drivers/net/ethernet/ibm/emac/core.h | 6 +- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/eth

[PATCH 2/2] net: emac: implement TCP TSO

This patch enables TSO(v4) hw feature for emac driver. As atleast the APM82181's TCP/IP acceleration hardware controller (TAH) provides TCP segmentation support in the transmit path. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c

[PATCH] net: emac: fix fixed-link setup for the RTL8363SB switch

ng on the original driver code, when it was necessary to set the phy_address and phy_map to 0x. But I guess without access to the old PPC405/440/460 hardware, it's not possible to know. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 15 ++---

Re: [PATCH 2/2] net/ibm/emac: wrong bit is used for STA control register write

On Monday, January 22, 2018 8:01:46 PM CET Ivan Mikhaylov wrote: > >Something looks wrong here?! The commit message talks about bit 18, 19 and > >20. > >However, 0x0800, 0x1000, 0x2000 and are like bit 11, 12 and 13? Furthermore, > >what about the EMAC_STACR_STAC_MASK? shouldn't it be 0x1800 now (

Re: [PATCH 2/2] net/ibm/emac: wrong bit is used for STA control register write

On Monday, January 22, 2018 5:00:38 PM CET Ivan Mikhaylov wrote: > STA control register has areas of mode and opcodes for opeations. 18 bit is > using for mode selection, where 0 is old MIO/MDIO access method and 1 is > indirect access mode. 19-20 bits are using for setting up read/write > operatio

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

On Friday, January 12, 2018 7:39:50 PM CET Dan Williams wrote: > On Fri, Jan 12, 2018 at 6:42 AM, Christian Lamparter > wrote: > > On Friday, January 12, 2018 1:47:46 AM CET Dan Williams wrote: > >> Static analysis reports that 'queue' may be a user controlled va

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

block > speculative execution of the instruction stream that could issue reads > based on an invalid result of 'ar9170_qmap[queue]'. In this case the > value of 'ar9170_qmap[queue]' is immediately reused as an index to the > 'ar->edcf' array. > > B

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

On Saturday, January 6, 2018 4:06:21 PM CET Alan Cox wrote: > > The only way a user can set this in any meaningful way would be via > > a NL80211_CMD_SET_WIPHY netlink message. However, the value will get > > vetted there by cfg80211's parse_txq_params [0]. This is long before > > Far more than a

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

block > speculative execution of the instruction stream that could issue reads > based on an invalid result of 'ar9170_qmap[queue]'. In this case the > value of 'ar9170_qmap[queue]' is immediately reused as an index to the > 'ar->edcf' array. > > B

[PATCH v3 2/3] net: ibm: emac: replace custom PHY_MODE_* macros

. And finally, it purges the old macros for good. Signed-off-by: Christian Lamparter --- Extra change in zmii.c to make checkpatch happy. --- drivers/net/ethernet/ibm/emac/core.c | 20 +- drivers/net/ethernet/ibm/emac/emac.h | 13 drivers/net/ethernet/ibm/emac/phy.c

[PATCH v3 3/3] net: ibm: emac: support RGMII-[RX|TX]ID phymode

The RGMII spec allows compliance for devices that implement an internal delay on TXC and/or RXC inside the transmitter. This patch adds the necessary RGMII_[RX|TX]ID mode code to handle such PHYs with the emac driver. Signed-off-by: Christian Lamparter --- v3: - replace PHY_MODE_* with

[PATCH v3 1/3] net: ibm: emac: replace custom rgmii_mode_name with phy_modes

phy_modes() in the common phy.h already defines the same phy mode names in lower case. The deleted rgmii_mode_name() is used only in one place and for a "notice-level" printk. Hence, it will not be missed. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/rg

Re: [PATCH v2] net: ibm: emac: support RGMII-[RX|TX]ID phymode

On Wednesday, December 20, 2017 3:10:46 PM CET David Miller wrote: > From: Christian Lamparter > Date: Wed, 20 Dec 2017 17:02:01 +0100 > > > diff --git a/drivers/net/ethernet/ibm/emac/emac.h > > b/drivers/net/ethernet/ibm/emac/emac.h > > index 5afcc27ceebb..8c6d2af728

[PATCH v2] net: ibm: emac: support RGMII-[RX|TX]ID phymode

The RGMII spec allows compliance for devices that implement an internal delay on TXC and/or RXC inside the transmitter. This patch adds the necessary RGMII_[RX|TX]ID mode code to handle such PHYs with the emac driver. Signed-off-by: Christian Lamparter --- v2: - utilize

[PATCH] net: ibm: emac: support RGMII-[RX|TX]ID phymode

The RGMII spec allows compliance for devices that implement an internal delay on TXC and/or RXC inside the transmitter. This patch adds the necessary RGMII_[RX|TX]ID mode code to handle such PHYs with the emac driver. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c

Re: [PATCH v2] p54: don't unregister leds when they are not initialized

2a/0x40 arch/x86/entry/entry_64.S:431 > > Signed-off-by: Andrey Konovalov Cc: sta...@vger.kernel.org Acked-by: Christian Lamparter Thanks for making the patch too!

[RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

This got rejected by gmail once. Let's see if it works now. On Thursday, September 21, 2017 8:22:45 PM CEST Andrey Konovalov wrote: > On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg > wrote: > > On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote: > > > >&

Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

On Wednesday, September 20, 2017 8:37:08 PM CEST Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > INFO: trying to register non-static key. > the code is fine but needs loc

[PATCH] net: emac: Fix napi poll list corruption

g such new work then we will violate the new caller contract. This patch fixes this by not touching any work when we reschedule in emac. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/mal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/ne

Re: hung task in mac80211

On Wednesday, September 6, 2017 1:57:47 PM CEST Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO: ta

Re: [PATCH] net: ibm: emac: Fix some error handling path in 'emac_probe()'

On Saturday, August 19, 2017 1:07:57 AM CEST Christophe JAILLET wrote: > If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is > known to be 0 at this point. > So return -ENODEV instead in the first case and propagate the error > returned by 'of_address_to_resource()' in the 2nd

[PATCH v2 1/2] net: emac: fix reset timeout with AR8035 phy

t. LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687> Cc: Chris Blake Reported-by: Russell Senior Fixes: 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT") Signed-off-by: Christian Lamparter --- v1 -> v2: - made it clear, that the clo

[PATCH v2 2/2] net: emac: fix and unify emac_mdio functions

tween emac_setup_aneg() and emac_mdio_setup_forced(). And furthermore it removes a chunk of emac_mdio_init_phy(), that was copying the same data into itself. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 41 1 file changed, 18 insertions(+

Re: [PATCH v1 2/2] net: emac: fix and unify emac_mdio functions

On Monday, June 5, 2017 11:43:33 PM CEST Andrew Lunn wrote: > On Mon, Jun 05, 2017 at 10:49:40PM +0200, Christian Lamparter wrote: > > emac_mdio_read_link() was not copying the requested phy settings > > back into the emac driver's own phy api. This has caused a link > >

Re: [PATCH v1 1/2] net: emac: fix reset timeout with AR8035 phy

On Monday, June 5, 2017 11:26:17 PM CEST Andrew Lunn wrote: > > In order to stay compatible with existing configurations, the > > driver will try the normal reset first and only falls back to > > to the internal clock, after the first reset fails. If the > > second reset fails as well, it will give

[PATCH v1 1/2] net: emac: fix reset timeout with AR8035 phy

e-project.org/index.php?do=details&task_id=687> Cc: Chris Blake Reported-by: Russell Senior Fixes: 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT") Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 32 +--- 1 fil

[PATCH v1 2/2] net: emac: fix and unify emac_mdio functions

tween emac_setup_aneg() and emac_mdio_setup_forced(). And furthermore it removes a chunk of emac_mdio_init_phy(), that was copying the same data into itself. Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 41 1 file changed, 18 insertions(+

Re: [PATCH] p54: add null pointer check before releasing socket buffer

On Monday, April 10, 2017 1:54:14 PM CEST Myungho Jung wrote: > On Mon, Apr 10, 2017 at 02:12:54PM +0200, Christian Lamparter wrote: > > On Sunday, April 9, 2017 10:23:20 PM CEST Myungho Jung wrote: > > > Kernel panic is caused by trying to dereference null pointer. Check if &g

Re: [PATCH] p54: add null pointer check before releasing socket buffer

(Added linux-wireless, since this is a wireless driver) On Sunday, April 9, 2017 10:23:20 PM CEST Myungho Jung wrote: > Kernel panic is caused by trying to dereference null pointer. Check if > the pointer is null before freeing space. Do you have the kernel panic somewhere? I think you have an eve

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 6:41:59 PM CEST Andrew Lunn wrote: > > Oh, in that case you should probably go "all out" and ask on the > > LKML to remove all of the ath9k and ath10k ahb work. From what I > > know all the "users" are running some sort of OpenWRT/LEDE or a > > derivative. This is becau

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 5:18:37 PM CEST Andrew Lunn wrote: > > But LEDE/OpenWRT rely on the firmware loading API more than ever and > > currently there is not a replacement for it. > > > > > > I looked into 10-ath9k-eeprom [0] of LEDE's AR71XX target and I noticed > > that quite a few d

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 10:44:41 AM CEST Alban wrote: > On Mon, 27 Mar 2017 18:11:15 +0200 > Christian Lamparter wrote: > > > On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > > > The current binding only cover PCI devices so extend it for SoC devices. > &g

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > The current binding only cover PCI devices so extend it for SoC devices. > > Most SoC platforms use an MTD partition for the calibration data > instead of an EEPROM. The qca,no-eeprom property was added to allow > loading the EEPROM content

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Thursday, March 23, 2017 3:43:28 PM CET Alban wrote: > On Tue, 14 Mar 2017 00:53:55 +0100 > Christian Lamparter wrote: > > > On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > > > Currently SoC platforms use a firmware request to get the EEPROM data. > > &g

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > Currently SoC platforms use a firmware request to get the EEPROM data. > This is mostly a hack and rely on using a user-helper scripts which is > deprecated. A nicer alternative is to use the nvmem API which was > designed for this kind of ta

[PATCH] net: ibm: emac: fix regression caused by emac_dt_phy_probe()

patch also removes the unused variable in emac_dt_phy_connect(). Fixes: a577ca6badb5261d ("net: emac: add support for device-tree based PHY discovery and setup") Reported-by: Julian Margetson Signed-off-by: Christian Lamparter --- drivers/net/ethernet/ibm/emac/core.c | 25

[PATCH v1.2] dt: emac: document device-tree based phy discovery and setup

tly stuck with a few privately defined phy implementations. It has no support for PHYs which are supported by the generic phylib. Acked-by: Rob Herring Signed-off-by: Christian Lamparter --- Fixed: phy node - so it conforms to phy.txt. --- --- .../devicetree/bindings/powerpc/4xx/emac.txt | 61

[PATCH v1.1] dt: emac: document device-tree based phy discovery and setup

tly stuck with a few privately defined phy implementations. It has no support for PHYs which are supported by the generic phylib. Acked-by: Rob Herring Signed-off-by: Christian Lamparter --- Resent - no changes. --- .../devicetree/bindings/powerpc/4xx/emac.txt | 64 +- 1 fil

[PATCH v2] dt: emac: document device-tree based phy discovery and setup

tly stuck with a few privately defined phy implementations. It has no support for PHYs which are supported by the generic phylib. Acked-by: Rob Herring Reviewed-by: Florian Fainelli Signed-off-by: Christian Lamparter --- --- .../devicetree/bindings/powerpc/4xx/emac.txt | 62

Re: [PATCH v1.1] net: emac: add support for device-tree based PHY discovery and setup

On Wednesday, February 22, 2017 3:37:35 PM CET David Miller wrote: > From: Christian Lamparter > Date: Mon, 20 Feb 2017 20:10:58 +0100 > > > This patch adds glue-code that allows the EMAC driver to interface > > with the existing dt-supported PHYs in drivers/net/phy. >

[PATCH v1.1] net: emac: add support for device-tree based PHY discovery and setup

generic phy library. Another reason is that PHYLIB also supports the BCM54610, which was used for the Western Digital My Book Live. This will now also make EMAC select PHYLIB. Signed-off-by: Christian Lamparter --- RFC->v1: - added PHYLIB (fixes kbuild-bot error) - used the corr

[PATCH v1 2/2] net: emac: add support for device-tree based PHY discovery and setup

generic phy library. Another reason is that PHYLIB also supports the BCM54610, which was used for the Western Digital My Book Live. This will now also make EMAC select PHYLIB. Signed-off-by: Christian Lamparter --- RFC->v1: - added PHYLIB (fixes kbuild-bot error) - used the corr

[PATCH v1 1/2] dt: emac: document device-tree based phy discovery and setup

tly stuck with a few privately defined phy implementations. It has no support for PHYs which are supported by the generic phylib. Acked-by: Rob Herring Signed-off-by: Christian Lamparter --- I rewrote the "phy-handle" property in order to make the links to net/ethernet.txt consistent with

Re: [PATCH][CFT] Saner error handling in skb_copy_datagram_iter() et.al.

> reverting ->msg_iter both on EINVAL and EFAULT. Comments? I've tested it. It also fixes the corruption issue I can reproduce with my setup.: # tc qdisc add dev eth0 root netem corrupt 0.1% (and the dlbug code) So, for what's worth: Tested-by: Christian Lamparter > diff --

Re: [RFC 1/2] dt: emac: document device-tree based phy discovery and setup

On Sunday, February 5, 2017 2:33:44 PM CET Florian Fainelli wrote: > Le 02/05/17 à 14:25, Christian Lamparter a écrit : > > This patch adds documentation for a new "phy-handler" property > > and "mdio" sub-node. These allows the enumeration of PHYs which > &g

Re: [RFC 2/2] net: emac: add support for device-tree based PHY discovery and setup

On Wednesday, February 15, 2017 3:23:08 PM CET Andrew Lunn wrote: > > > > Is the PHY just powered down by chance (BMCR_PWRDN set?) and resetting > > > > it implicitly clears the power down that seems to be what is going on. > > > > > > Yes, the PHY is just in the BMCR_PDOWN state. I can do the sam

Re: [RFC 2/2] net: emac: add support for device-tree based PHY discovery and setup

On Tuesday, February 14, 2017 12:38:42 AM CET Christian Lamparter wrote: > > >>> diff --git a/drivers/net/ethernet/ibm/emac/core.c > > >>> b/drivers/net/ethernet/ibm/emac/core.c > > >>> --- a/drivers/net/ethernet/ibm/emac/core.c >

Re: [RFC 2/2] net: emac: add support for device-tree based PHY discovery and setup

On Saturday, February 11, 2017 3:07:04 PM CET Florian Fainelli wrote: > Le 02/11/17 à 14:45, Christian Lamparter a écrit : > > On Sunday, February 5, 2017 2:44:54 PM CET Florian Fainelli wrote: > >> Le 02/05/17 à 14:25, Christian Lamparter a écrit : > >>

  1   2   >