Re: [PATCH v2] can: c_can: move runtime PM enable/disable to c_can_platform

hose pm_enable/disable code to > c_can_platform. I can confirm this makes the warning go away on a Congatec Atom board. I didn't do any further runtime tests. Tested-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König

[PATCH v2] vio: make remove callback return void

ed-by: Greg Kroah-Hartman Signed-off-by: Uwe Kleine-König --- Hello, I dropped the sparc specific files (i.e. all that Michael Ellerman didn't characterize as powerpc specific and verified that they are indeed sparc-only). The commit log is adapted accordingly. Best regards Uwe arch/powerpc/i

[PATCH v2] vio: make remove callback return void

Acked-by: Greg Kroah-Hartman Signed-off-by: Uwe Kleine-König --- Hello, v1 (sent with Message-Id: 20210127215010.99954-1-...@kleine-koenig.org> had an back then unfulfilled precondition for a patch to drivers/net/ethernet/ibm/ibmvnic.c. That patch already got into v5.11 as 5e9eff5dfa46 "

[PATCH v2 2/2] mei: bus: change remove callback to return void

id and return 0 unconditionally in mei_cl_device_remove(). The only driver that could return an error value is modified to emit an explicit warning in the error case. Acked-by: Guenter Roeck Signed-off-by: Uwe Kleine-König --- drivers/misc/mei/bus.c | 5 ++--- drivers/misc/mei/hdcp

[PATCH v2 0/2] mei: bus: Some cleanups

Hello, changes since v1: - Added a missing ; found by kernel test robot, thanks - Added an Ack for Guenter rangediff can be found below. Uwe Kleine-König (2): mei: bus: simplify mei_cl_device_remove() mei: bus: change remove callback to return void drivers/misc/mei/bus.c | 11

[PATCH v2 1/2] mei: bus: simplify mei_cl_device_remove()

at is not the first one. So cldev only can become NULL if dev is (void *)0xc (for archs with 32 bit pointers) or (void *)0x18 (for archs with 64 bit pointers).) Signed-off-by: Uwe Kleine-König --- drivers/misc/mei/bus.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/dr

[PATCH v1 1/2] mei: bus: simplify mei_cl_device_remove()

at is not the first one. So cldev only can become NULL if dev is (void *)0xc (for archs with 32 bit pointers) or (void *)0x18 (for archs with 64 bit pointers).) Signed-off-by: Uwe Kleine-König --- drivers/misc/mei/bus.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/dr

[PATCH v1 2/2] mei: bus: change remove callback to return void

id and return 0 unconditionally in mei_cl_device_remove(). The only driver that could return an error value is modified to emit an explicit warning in the error case. Signed-off-by: Uwe Kleine-König --- drivers/misc/mei/bus.c | 5 ++--- drivers/misc/mei/hdcp/mei_hdcp.c | 7 +-- drivers/nfc/

Re: [PATCH] vio: make remove callback return void

Hello Sukadev, On 1/28/21 8:07 PM, Sukadev Bhattiprolu wrote: Slightly off-topic, should ndo_stop() also return a void? Its return value seems to be mostly ignored and [...] I don't know enough about the network stack to tell. Probably it's a good idea to start a separate thread for this and

[PATCH] vio: make remove callback return void

o a driver without a remove callback vio_cmo_bus_remove(viodev) wasn't called. As the device core still considers the device unbound after vio_bus_remove() returns calling this unconditionally is the consistent behaviour which is implemented here. Signed-off-by: Uwe Kleine-König --- Hello,

[PATCH v2 0/3] isa: Make the remove callback for isa drivers return void

given that this is the most affected tree. This is fine for me. Otherwise I can also provide an immutable branch. For both variants we still need a few acks though. Best regards Uwe Uwe Kleine-König (3): watchdog: pcwd: drop always-false if from remove callback media/radio: Make

[PATCH v2 3/3] isa: Make the remove callback for isa drivers return void

an1.c Acked-by: William Breathitt Gray Acked-by: Wolfram Sang # for drivers/i2c/ Reviewed-by: Takashi Iway # for sound/ Signed-off-by: Uwe Kleine-König --- drivers/base/isa.c | 2 +- drivers/i2c/busses/i2c-elektor.c | 4 +--- drivers/i2c/busses/i2c-pca-isa.c | 4 +--- dr

[PATCH v1 2/2] isa: Make the remove callback for isa drivers return void

The driver core ignores the return value of the remove callback, so don't give isa drivers the chance to provide a value. Adapt all isa_drivers with a remove callbacks accordingly; they all return 0 unconditionally anyhow. Signed-off-by: Uwe Kleine-König --- drivers/base/

[PATCH v1 0/2] isa: Make the remove callback for isa drivers return void

centive to believe they could return an error. There is only a single isa driver in the tree (assuming I didn't miss any) that has a remove callback that can return a non zero return code. This is "fixed" in the first patch, to make the second patch more obviously correct. Best regards

Re: [PATCH net RFC] ibmvnic: device remove has higher precedence over reset

t_bit(0, &adapter->resetting)) { > - spin_unlock_irqrestore(&adapter->state_lock, flags); > - return -EBUSY; > - } > - > adapter->state = VNIC_REMOVING; > spin_unlock_irqrestore(&adapter->state_lock, flags); Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature

Re: ibmvnic: Race condition in remove callback

Hello Dany, On Tue, Jan 19, 2021 at 10:14:25AM -0800, Dany Madden wrote: > On 2021-01-17 02:12, Uwe Kleine-König wrote: > > while working on some cleanup I stumbled over a problem in the ibmvnic's > > remove callback. Since commit > > > > 7d7195a026ba

ibmvnic: Race condition in remove callback

e_driver() in drivers/base/dd.c calling dev->bus->remove()). -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature

Re: [PATCH] net: ethernet: fec: Clear stale flag in IEVENT register before MII transfers

Hi Andrew, On Wed, Dec 09, 2020 at 03:44:13PM +0100, Andrew Lunn wrote: > On Wed, Dec 09, 2020 at 11:29:59AM +0100, Uwe Kleine-König wrote: > Do you have > > ommit 1e6114f51f9d4090390fcec2f5d67d8cc8dc4bfc > Author: Greg Ungerer > Date: Wed Oct 28 15:22:32 2020 +1000 >

[PATCH] net: ethernet: fec: Clear stale flag in IEVENT register before MII transfers

quot;) Signed-off-by: Uwe Kleine-König --- Hello, I tried (shortly) to find out what actually results in this bit being set because looking at f166f890c8f0 I'd say it cares enough. It's just proven by the real world that it's not good enough :-) Best regards Uwe drivers/net/ethern

Re: [PATCH 2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void

Hello Michael, On Sat, Nov 28, 2020 at 09:48:30AM +0100, Takashi Iwai wrote: > On Thu, 26 Nov 2020 17:59:50 +0100, > Uwe Kleine-König wrote: > > > > The driver core ignores the return value of struct device_driver::remove > > because there is only little that can b

Re: [PATCH 1/2] ALSA: ppc: drop if block with always false condition

On Fri, Nov 27, 2020 at 09:35:39AM +0100, Geert Uytterhoeven wrote: > Hi Uwe, > > On Thu, Nov 26, 2020 at 6:03 PM Uwe Kleine-König > wrote: > > The remove callback is only called for devices that were probed > > successfully before. As the matching probe function can

[PATCH 2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void

truct ps3_system_bus_driver::remove return void, too. All users already unconditionally return 0, this commit makes it obvious that returning an error code is a bad idea and ensures future users behave accordingly. Signed-off-by: Uwe Kleine-König --- arch/powerpc/include/asm/ps3.h

[PATCH 1/2] ALSA: ppc: drop if block with always false condition

The remove callback is only called for devices that were probed successfully before. As the matching probe function cannot complete without error if dev->match_id != PS3_MATCH_ID_SOUND, we don't have to check this here. Signed-off-by: Uwe Kleine-König --- sound/ppc/snd_ps3.c | 2 --

Re: [PATCH] docs: dt: fix broken links due to txt->yaml renames

h would broke a link I would > have it fixed before it hits any tree. What about adding a check to check_patch? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ |

network unreliable on ReadyNAS 104 with Debian kernel

Hello Arnaud, hello Thomas, I own a ReadyNAS 104 (CPU: Armada 370, mvneta driver) and since some time its network driver isn't reliable any more. I see things like: $ rsync -a remotehost:dir /srv/dir ssh_dispatch_run_fatal: Connection to $remoteaddress port 22: message authentica

Re: net: micrel: confusion about phyids used in driver

omeone who knows > > something... > > Forwarded to Yuiko. Will do follow-up. Nothing happend here, right? Would it be possible to get more detailed documentation about the affected chips than available on the website such that someone outside of microchip can address the probl

Re: [PATCH] lib: dimlib: fix help text typos

On 9/26/19 2:20 AM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix help text typos for DIMLIB. > > Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files") > Signed-off-by: Randy Dunlap > Cc: Uwe Kleine-König Acked-by: Uwe Kleine-König Thanks for

[PATCH v2] dimlib: make DIMLIB a hidden symbol

According to Tal Gilboa the only benefit from DIM comes from a driver that uses it. So it doesn't make sense to make this symbol user visible, instead all drivers that use it should select it (as is already the case AFAICT). Signed-off-by: Uwe Kleine-König --- Hello David, On Tue, Sep 24,

[PATCH] arcnet: provide a buffer big enough to actually receive packets

: sta...@vger.kernel.org # v2.4.0+ Signed-off-by: Uwe Kleine-König --- Hello, the problem exists in v2.4.0 already, I didn't look further to identify the offending commit. Best regards Uwe --- drivers/net/arcnet/arcnet.c | 31 +-- 1 file changed, 17 insertions(+

Re: dsa traffic priorization

talked to our customer and he verified that their > Ethercat traffic still goes through even when the ports with the general > traffic are jammed with packets. So yes, I think this is what I want. Moreover egressing the cpu port has the advantage that network participants on other po

Re: net: micrel: confusion about phyids used in driver

Hello Nicolas, there are some open questions regarding details about some PHYs supported in the drivers/net/phy/micrel.c driver. On Thu, Aug 08, 2019 at 10:36:37AM +0200, Uwe Kleine-König wrote: > On Tue, Jul 02, 2019 at 08:55:07PM +, yuiko.osh...@microchip.com wrote: > > >On

Re: net: micrel: confusion about phyids used in driver

Hello, On Tue, Jul 02, 2019 at 08:55:07PM +, yuiko.osh...@microchip.com wrote: > >On Fri, May 10, 2019 at 09:22:43AM +0200, Uwe Kleine-König wrote: > >> On Thu, May 09, 2019 at 11:07:45PM +0200, Andrew Lunn wrote: > >> > On Thu, May 09, 2019 at 10:55:29PM +

Re: net: micrel: confusion about phyids used in driver

Hello Yuiko Oshino, On Fri, May 10, 2019 at 09:22:43AM +0200, Uwe Kleine-König wrote: > On Thu, May 09, 2019 at 11:07:45PM +0200, Andrew Lunn wrote: > > On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote: > > > On 09.05.2019 22:29, Uwe Kleine-König wrote: > >

Re: net: micrel: confusion about phyids used in driver

On Thu, May 09, 2019 at 11:07:45PM +0200, Andrew Lunn wrote: > On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote: > > On 09.05.2019 22:29, Uwe Kleine-König wrote: > > > I have a board here that has a KSZ8051MLL (datasheet: > > > http://ww1.microchip

net: micrel: confusion about phyids used in driver

and assume that writing to a reserved register bit does nothing? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

Hello, On Tue, Apr 30, 2019 at 10:12:27AM +0200, Uwe Kleine-König wrote: > On Thu, Apr 25, 2019 at 09:17:32PM +0200, Aurelien Jarno wrote: > > On 2019-04-25 14:50, Aurelien Jarno wrote: > > > On 2019-04-23 22:16, Aurelien Jarno wrote: > > > > Source: li

Re: Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

; The following ones don't: > > - linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb > > - linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb > > > > My guess (I don't have time to try more now) is that the issue is caused > > by the following change: &g

Re: [PATCH 1/2] net: sch_generic: add flag IFF_FIFO_QUEUE to use pfifo_fast as default scheduler

ice is lower dev of a failover master device > * @IFF_L3MDEV_RX_HANDLER: only invoke the rx handler of L3 master device > + * @IFF_FIFO_QUEUE: device must run with FIFO qdisc attached. skb drop > without NET_XMIT_DROP is fatal Do you need the FIFO property or only that the qdisc doesn

Re: [PATCH 4/4] can: flexcan: fix NULL pointer exception during bringup

flexcan: add self wakeup support") > > > How should we proceed with this patch? When I posted the commit I also posted one that fits on top of v4.19.x. I would expect that the same also fits on v4.20.x. If not, tell me. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: [PATCH 4/4] can: flexcan: fix NULL pointer exception during bringup

On Tue, Jan 22, 2019 at 02:21:16PM +0100, Marc Kleine-Budde wrote: > From: Uwe Kleine-König > > Commit cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX") > introduced a loop letting i run up to (including) ARRAY_SIZE(regs->mb) > and in the body accessed re

[PATCH] can: flexcan: fix NULL pointer exception during bringup

exception. This only affects devices compatible with "fsl,p1010-flexcan", "fsl,imx53-flexcan", "fsl,imx35-flexcan", "fsl,imx25-flexcan", "fsl,imx28-flexcan", so newer i.MX SoCs are not affected. Fixes: cbffaf7aa09e ("can: flexcan: Always use last

[PATCH v4.19.x] can: flexcan: fix out-of-bounds array access

("can: flexcan: Always use last mailbox for TX") Signed-off-by: Uwe Kleine-König --- drivers/net/can/flexcan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index 75ce11395ee8..ae219b8a7754 100644 --- a/drivers/n

Re: [PATCH 11/20] can: flexcan: Always use last mailbox for TX

e (e581) [ 11.162068] ---[ end trace aaa0ccd32b1426b3 ]--- I have a fix for 4.19.14 that doesn't fit as is on current mainline. I didn't check if mainline is still affected, but will do so later today. I will send the fix for 4.19.x as a reply to this mail. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: [PATCH] net: macb: Fix regression breaking non-MDIO fixed-link PHYs

> - err = of_mdiobus_register(bp->mii_bus, np); > if (err) > goto err_out_free_mdiobus; > > @@ -606,9 +612,9 @@ static int macb_mii_init(struct macb *bp) > > err_out_unregister_bus: > mdiobus_unregister(bp->mii_bus); >

Re: [PATCH] net: dsa: mv88e6xxx: fix races between lock and irq freeing

On Sun, Jul 22, 2018 at 01:04:11PM -0700, David Miller wrote: > From: Uwe Kleine-König > Date: Sun, 22 Jul 2018 21:00:35 +0200 > > > On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote: > >> From: Uwe Kleine-König > >> Date: Fri, 20 Jul 2018 11:53:15 +0

Re: [PATCH] net: dsa: mv88e6xxx: fix races between lock and irq freeing

Hello, On Sat, Jul 21, 2018 at 10:44:09PM -0700, David Miller wrote: > From: Uwe Kleine-König > Date: Fri, 20 Jul 2018 11:53:15 +0200 > > > free_irq() waits until all handlers for this IRQ have completed. As the > > relevant handler (mv88e6xxx_g1_irq_thread_fn()) take

[PATCH] net: dsa: mv88e6xxx: fix races between lock and irq freeing

in a NULL-pointer exception. Signed-off-by: Uwe Kleine-König --- drivers/net/dsa/mv88e6xxx/chip.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 437cd6eb4faa..9ef07a06aceb 100644 ---

Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031

s can hold the whole domain of u16 should be fine. > + } > + } Maybe issue a warning if reading MII_CTRL1000 failed? > } > > return ksz9031_center_flp_timing(phydev); Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: BUG?: receiving on a packet socket with .sll_protocoll and bridging

Hello Willem, On Sun, May 06, 2018 at 06:58:34PM +0200, Willem de Bruijn wrote: > On Sat, May 5, 2018 at 10:57 AM, Uwe Kleine-König > wrote: > > For testing purposes I created a veth device pair (veth0 veth1), open a > > socket for each of the devices and send packets aroun

BUG?: receiving on a packet socket with .sll_protocoll and bridging

but also with the same symptoms on an arm64 with 4.16 and a dsa switch. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: [PATCH v3 net-next 1/2] net: dsa: mv88e6xxx: Use the DT IRQ trigger mode

Hi Andrew, On Mon, Mar 26, 2018 at 12:02:37AM +0200, Andrew Lunn wrote: > On Sun, Mar 25, 2018 at 11:54:24PM +0200, Uwe Kleine-König wrote: > > On Sun, Mar 25, 2018 at 11:43:14PM +0200, Andrew Lunn wrote: > > > By calling request_threaded_irq() with the flag IRQF_TRIGGER_FALLING

Re: [PATCH v3 net-next 1/2] net: dsa: mv88e6xxx: Use the DT IRQ trigger mode

riptions use. > > Suggested-by: Uwe Kleine-König > Signed-off-by: Andrew Lunn Thanks Andrew for the respin. Acked-by: Uwe Kleine-König Tested-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions

[PATCH v2 0/3] net: dsa: mv88e6xxx: some fixes

gards Uwe Uwe Kleine-König (3): net: dsa: mv88e6xxx: Fix name of switch 88E6141 net: dsa: mv88e6xxx: Fix typo in a comment net: dsa: mv88e6xxx: Fix interrupt name for g2 irq drivers/net/dsa/mv88e6xxx/chip.c| 4 ++-- drivers/net/dsa/mv88e6xxx/global2.c | 2 +- 2 files changed, 3 insertions(

[PATCH v2 3/3] net: dsa: mv88e6xxx: Fix interrupt name for g2 irq

This changes the respective line in /proc/interrupts from 49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g1 to 49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g2 which makes more sense. Reviewed-by: Andrew Lunn Signed-off-by: Uwe Kleine-König --- drivers

[PATCH v2 1/3] net: dsa: mv88e6xxx: Fix name of switch 88E6141

The switch name is emitted in the kernel log, so having the right name there is nice. Fixes: 1558727a1c1b ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141") Reviewed-by: Andrew Lunn Signed-off-by: Uwe Kleine-König --- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- 1 file

[PATCH v2 2/3] net: dsa: mv88e6xxx: Fix typo in a comment

Reviewed-by: Andrew Lunn Signed-off-by: Uwe Kleine-König --- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 6439f7d6c4d6..fd78378ad6b1 100644 --- a/drivers/net/dsa

Re: [PATCH 0/4] net: dsa: mv88e6xxx: novice fixes and irq handling

it a hardware limitation, or > just missing from the pinctrl driver? I didn't check yet. This is an Armada 3720, the hardware specification is available from Marvell. I'll take a look after resending my series with your Reviewed-by tags. Best regards Uwe -- Pengutronix e.K.

Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Use the DT IRQ trigger mode

ame(chip->dev), chip); You could join the shortend line with the next here. Other than that: Acked-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

[PATCH 3/4] net: dsa: mv88e6xxx: fix interrupt name for g2 irq

This changes the respective line in /proc/interrupts from 49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g1 to 49: x x mv88e6xxx-g1 7 Edge mv88e6xxx-g2 which makes more sense. Signed-off-by: Uwe Kleine-König --- drivers/net/dsa/mv88e6xxx/global2

[PATCH 4/4] net: dsa: mv88e6xxx: guess number of g1 irqs

I don't have access to the documentation of the marvell switches, but with this change the switch driver successfully binds on the espressobin after its device tree makes use of the switch's irq line. --- drivers/net/dsa/mv88e6xxx/chip.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/driver

[PATCH 1/4] net: dsa: mv88e6xxx: Fix name of switch 88E6141

The switch name is emitted in the kernel log, so having the right name there is nice. Fixes: 1558727a1c1b ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141") Signed-off-by: Uwe Kleine-König --- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH 0/4] net: dsa: mv88e6xxx: novice fixes and irq handling

sted the second change however the driver still failed because the gpio controller doesn't support level sensitive irqs. :-| Looking forward to your comments Uwe Kleine-Köníg Uwe Kleine-König (4): net: dsa: mv88e6xxx: Fix name of switch 88E6141 net: dsa: mv88e6xxx: Fix typo in a comment n

[PATCH 2/4] net: dsa: mv88e6xxx: fix typo in a comment

Signed-off-by: Uwe Kleine-König --- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index e2d3df9908e0..38fe875b9631 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b

add "net: fec: Allow reception of frames bigger than 1522 bytes" to stable

erry-picked to 4.9.x without conflict and IMHO should be applied to all stable branches before v4.14. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: [PATCH net-next] net: ethernet: ax88796: support generating a random mac address

Hello David, On Thu, May 25, 2017 at 10:55:11PM +0200, Uwe Kleine-König wrote: > Instead of falling back to 00:00:00:00:00:00 generate a random address > if none is provided via platform data or from the the device's register s/the the/the/ should I resend for this, or can you fixu

[PATCH net-next] net: ethernet: ax88796: support generating a random mac address

Instead of falling back to 00:00:00:00:00:00 generate a random address if none is provided via platform data or from the the device's register space. Signed-off-by: Uwe Kleine-König --- drivers/net/ethernet/8390/ax88796.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/driver

[PATCH net] net: ethernet: ax88796: don't call free_irq without request_irq first

The function ax_init_dev (which is called only from the driver's .probe function) calls free_irq in the error path without having requested the irq in the first place. So drop the free_irq call in the error path. Fixes: 825a2ff1896e ("AX88796 network driver") Signed-off-by: U

[PATCH] net: phy: put genphy_config_init's EXPORT_SYMBOL directly after the function

ned-off-by: Uwe Kleine-König --- drivers/net/phy/phy_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 1219eeab69d1..0780e9f9e167 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/ph

Re: pull-request: can 2017-04-04

ixes-for-4.12-20170404 that contains the commit id Marc mentioned. (Found using git ls-remote git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git | grep ca257b9e2 .) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: Initializing MAC address at run-time

t; In my mind, doing it early in Linux is similar in spirit to doing it > at the boot loader stage, in that it's neatly separated from the rest > of the setup. Sure you can do this. But it won't be accepted mainline for sure. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: Initializing MAC address at run-time

st above. d) doesn't work, but instead you can pass the partitioning on the kernel commandline. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: [PATCH net-next 1/2] net: dsa: make "label" property optional for dsa2

e current behavior is unchanged, and the optional "label" > property for user ports has precedence over the enumerated name. > > Signed-off-by: Vivien Didelot Acked-by: Uwe Kleine-König Thanks Uwe signature.asc Description: OpenPGP digital signature

Re: [PATCH net-next 1/2] net: dsa: make "label" property optional for dsa2

Hello, On 01/06/2017 11:47 PM, Florian Fainelli wrote: > On 01/06/2017 02:20 PM, Andrew Lunn wrote: >>> If one wants to rename an interface, udev rules can be used as usual. >> >> Hi Vivien >> >> Do you have some examples? >> >> A quick look at udevadm info suggests we can use >> >> ATTR{phys_port

Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support

On 11/28/2016 02:17 PM, Andrew Lunn wrote: >> I still wonder (and didn't get an answer back when I asked about this) >> why a comment is preferred here. For other devices I know it's usual and >> requested by the maintainers to use: >> >> compatible = "exact name", "earlyer device to match dri

Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support

Hello Andrew, On Mon, Nov 28, 2016 at 12:10:09AM +0100, Andrew Lunn wrote: > > Try to see it from my perspective: I see that some vf610 device I don't > > have (found via `git grep marvell,mv88e6` or so) uses > > "marvell,mv88e6085". I then assume it has that device on board. How > > would I know

[PATCH v3] net/phy: add trace events for mdio accesses

Make it possible to generate trace events for mdio read and write accesses. Signed-off-by: Uwe Kleine-König --- drivers/net/phy/mdio_bus.c | 11 +++ include/trace/events/mdio.h | 42 ++ 2 files changed, 53 insertions(+) create mode 100644

[PATCH v2] net/phy: add trace events for mdio accesses

Make it possible to generate trace events for mdio read and write accesses. Signed-off-by: Uwe Kleine-König --- Changes since (implicit) v1: - make use of TRACE_EVENT_CONDITION Alternatively to this patch the condition could be + TP_CONDITION(err == 0), but then we'd need in the

[PATCH] net/phy: add trace events for mdio accesses

Make it possible to generate trace events for mdio read and write accesses. Signed-off-by: Uwe Kleine-König --- drivers/net/phy/mdio_bus.c | 15 +++ include/trace/events/mdio.h | 40 2 files changed, 55 insertions(+) create mode 100644

[PATCH] net: phy: marvell: optimize logic for page changing during init

Instead of remembering if the page was changed, just compare the current page to the saved one. This is easier and has the advantage to save a register write if the page was already restored. Signed-off-by: Uwe Kleine-König --- drivers/net/phy/marvell.c | 6 ++ 1 file changed, 2 insertions

[PATCH] net: fec: drop check for clk==NULL before calling clk_*

clk_prepare, clk_enable and their counterparts (at least the common clk ones, but also most others) do check for the clk being NULL anyhow (and return 0 then), so there is no gain when the caller checks, too. Signed-off-by: Uwe Kleine-König --- drivers/net/ethernet/freescale/fec_main.c | 25

Re: Alignment issues with freescale FEC driver

dy for the 4.X+1 merge window. Of course some fixes might have to go in, but these hopefully won't disturb much. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: [PATCH] net: fec: set mac address unconditionally

On Thu, Sep 22, 2016 at 08:08:36AM +0200, Uwe Kleine-König wrote: > Acked-by: Uwe Kleine-König huch, cut and paste borkage: This should be Acked-by: Uwe Kleine-König of course. Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Li

Re: [PATCH] net: fec: set mac address unconditionally

d/cannot be written in .ndo_set_mac_address()/ > sets the mac address unconditionally in fec_restart(...) and ensures > consistens between fec registers and the network layer. s/consistens/consistency/ Other than that: Acked-by: Uwe Kleine-König Thanks Uwe -- Pengutronix

About enet_out clk on i.MX28, i.MX6 and i.MX7

ould still handle dtbs that don't have enet_out in the fec node. That affects dtbs built between v3.6-rc1~144^2~7^2~11 = 3143bbb42b3d ("ARM: mxs: convert apx4devkit board to device tree") and v3.10-rc1~63^2~10^2~20 = f231a9fe7f80 ("ARM: dts: mxs: add enet_out clock to devicetree") .) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

[PATCH] net: ipconfig: fix use after free

eady changed. So delay freeing until after the autoconfig results are reported. Fixes: 2647cffb2bc6 ("net: ipconfig: Support using "delayed" DHCP replies") Reported-by: Geert Uytterhoeven Signed-off-by: Uwe Kleine-König --- net/ipv4/ipconfig.c | 17 + 1 f

Re: Regression introduced by "net: ipconfig: Support using "delayed" DHCP replies"

not surprising. e068853409aa1720 was only possible because of 2647cffb2bc6fbed163d377390eb7ca552c7c1cb. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

[PATCH 1/3] net: ipconfig: Add device name to debug messages

This simplifies understanding what happens when there is more than one device. Signed-off-by: Uwe Kleine-König --- net/ipv4/ipconfig.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c index 1d71c40eaaf3..369e4a004850

[PATCH 2/3] net: ipconfig: Support using "delayed" DHCP replies

accordingly. The relevant change then is to reset d to ic_dev on a reply to assert that the followup request goes through the right device. Signed-off-by: Uwe Kleine-König --- net/ipv4/ipconfig.c | 29 ++--- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/net

[PATCH 3/3] net: ipconfig: drop inter-device timeout

Now that ipconfig learned to handle "delayed replies" in the previous commit, there is no reason any more to delay sending a first request per device. Signed-off-by: Uwe Kleine-König --- net/ipv4/ipconfig.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH 0/3] net: ipconfig: improve DHCP timeout handling

slow DHCP servers at all in some configurations and improves boot speed in general. The first patch is not really necessary, it only helps decoding debug messages when there is more than one device. Best regards Uwe Uwe Kleine-König (3): net: ipconfig: Add device name to debug messages net: ipconfi

Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

yet), just considered these patches low-hanging fruits. But when looking again there, I will provide some numbers. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

ip=dhcp woes

x e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |

Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

Hello, On Wed, Jul 27, 2016 at 05:11:54PM +0300, Grygorii Strashko wrote: > On 07/27/2016 10:03 AM, Uwe Kleine-König wrote: > > On Tue, Jul 26, 2016 at 05:36:49PM +0300, Grygorii Strashko wrote: > >> On 07/26/2016 03:02 PM, Uwe Kleine-König wrote: > >>> Hello, >

Re: [PATCH 2/2] net: davinci_cpdma: reduce time holding chan->lock in cpdma_chan_submit

Hello, On Tue, Jul 26, 2016 at 05:25:58PM +0300, Grygorii Strashko wrote: > On 07/26/2016 03:02 PM, Uwe Kleine-König wrote: > > Allocating and preparing a dma descriptor doesn't need to happen under > > the channel's lock. So do this before taking the channel's l

Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

On Tue, Jul 26, 2016 at 05:36:49PM +0300, Grygorii Strashko wrote: > On 07/26/2016 03:02 PM, Uwe Kleine-König wrote: > >Hello, > > > >these patches are based on next-20160726. I didn't check yet how latency > >improves by using these patches, but even if the impr

[PATCH 2/2] net: davinci_cpdma: reduce time holding chan->lock in cpdma_chan_submit

ned-off-by: Uwe Kleine-König --- drivers/net/ethernet/ti/davinci_cpdma.c | 38 + 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c index 5ffa04a306c6..ba3462707ae3 100644 --

[PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

Hello, these patches are based on next-20160726. I didn't check yet how latency improves by using these patches, but even if the improvment is small, it's still a good idea to have them. A second pair of eyes checking what I did would be great. Best regards Uwe Uwe Kleine-König

[PATCH 1/2] net: davinci_cpdma: reduce time holding ctlr->lock in cpdma_control_set

The only user of cpdma_control_set (i.e. cpsw_ndo_open) doesn't check the return code, so it doesn't matter, which error triggers. So the checks that are independant of the fields protected by ctlr->lock can be moved out of the critical section. Signed-off-by: Uwe Kleine-König ---

[PATCH v2] net: davinci_cpdma: remove excessive dump of register values to kernel log

Kleine-König --- Notes: Changes since (implicit) v1, sent with Message-Id: 1469217534-6232-1-git-send-email-u.kleine-koe...@pengutronix.de: - drop cpdma_state_str variable to fix build warning found by the kbuild test robot drivers/net/ethernet/ti/davinci_cpdma.c | 121

[PATCH] net: davinci_cpdma: remove excessive dump of register values to kernel log

Kleine-König --- drivers/net/ethernet/ti/davinci_cpdma.c | 119 drivers/net/ethernet/ti/davinci_cpdma.h | 2 - drivers/net/ethernet/ti/davinci_emac.c | 96 -- 3 files changed, 217 deletions(-) diff --git a/drivers/net/ethernet/ti

  1   2   >