Hi,
Heads-up on this kernel Oops that happened and has been observed on
linux-next since 20201103 and was not existing in 20201030.
I didn't went further until now but wanted to report it
as soon as possible.
Could it be related to newly included patch
e4e143e26ce8 ("net: macb: add support for hi
Joe,
Please drop this chunk: it's a successive controller version number
which are all backward compatible with "fallthrough" on each case so
removing from this last one makes it inconsistent.
In sort: NACK for atmel-mci.
Best regards,
Nicolas
On 09/09/2020 at 22:06, Joe Perches wrote:
>
From: Nicolas Ferre
Handle the Wake-on-Lan interrupt for the Cadence MACB Ethernet
controller.
As we do for the GEM version, we handle of WoL interrupt in a
specialized interrupt handler for MACB version that is positionned
just between suspend() and resume() calls.
Cc: Claudiu Beznea
Cc: Harin
From: Nicolas Ferre
Hi,
Here is the second part of support for WoL magic-packet on the current macb
driver. This one
is addressing the bulk of the feature and is based on current net-next/master.
MACB and GEM code must co-exist and as they don't share exactly the same
register layout, I had to
From: Nicolas Ferre
Adapt the Wake-on-Lan feature to the Cadence GEM Ethernet controller.
This controller has different register layout and cannot be handled by
previous code.
We disable completely interrupts on all the queues but the queue 0.
Handling of WoL interrupt is done in another interrup
On 13/07/2020 at 17:45, Claudiu Beznea - M18063 wrote:
> Hi Nicolas,
>
>
> On 13.07.2020 13:05, nicolas.fe...@microchip.com wrote:
>> From: Nicolas Ferre
>>
>> Adapt the Wake-on-Lan feature to the Cadence GEM Ethernet controller.
>> This controller has different register layout and cannot be han
From: Nicolas Ferre
Adapt the Wake-on-Lan feature to the Cadence GEM Ethernet controller.
This controller has different register layout and cannot be handled by
previous code.
We disable completely interrupts on all the queues but the queue 0.
Handling of WoL interrupt is done in another interrup
From: Nicolas Ferre
Hi,
Here is the second part of support for WoL magic-packet on the current macb
driver. This one
is addressing the bulk of the feature and is based on current net-next/master.
MACB and GEM code must co-exist and as they don't share exactly the same
register layout, I had to
From: Nicolas Ferre
Handle the Wake-on-Lan interrupt for the Cadence MACB Ethernet
controller.
As we do for the GEM version, we handle of WoL interrupt in a
specialized interrupt handler for MACB version that is positionned
just between suspend() and resume() calls.
Cc: Claudiu Beznea
Cc: Harin
From: Nicolas Ferre
Hi,
Here is a split series to fix WoL magic-packet on the current macb driver. Only
fixes in this one based on current net/master.
Best regards,
Nicolas
Changes in v5:
- Addressed the error code returned by phylink_ethtool_set_wol() as suggested
by Russell.
If PHY hand
From: Nicolas Ferre
Keep previous function goals and integrate phylink actions to them.
phylink_ethtool_get_wol() is not enough to figure out if Ethernet driver
supports Wake-on-Lan.
Initialization of "supported" and "wolopts" members is done in phylink
function, no need to keep them in calling
From: Nicolas Ferre
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906 ("net: macb: add wake-on-lan support via magic packet")
Cc: Clau
From: Nicolas Ferre
As we now use the phylink call to phylink_stop() in the non-WoL path,
there is no need for this call to netif_carrier_off() anymore. It can
disturb the underlying phylink FSM.
Fixes: 7897b071ac3b ("net: macb: convert to phylink")
Cc: Claudiu Beznea
Cc: Harini Katakam
Cc: An
From: Nicolas Ferre
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
&bp->dev->dev.parent.
It's preventing the trigger of a spurious interrupt in case the
Wake-on-Lan feature is used.
Fi
From: Nicolas Ferre
Change the way the "magic-packet" DT property is handled in the
macb_probe() function, matching DT binding documentation.
Now we mark the device as "wakeup capable" instead of calling the
device_init_wakeup() function that would enable the wakeup source.
For Ethernet WoL, ena
From: Nicolas Ferre
I would like that Claudiu becomes co-maintainer of the Cadence macb
driver. He's already participating to lots of reviews and enhancements
to this driver and knows the different versions of this controller.
Signed-off-by: Nicolas Ferre
---
MAINTAINERS | 1 +
1 file changed,
From: Nicolas Ferre
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
&bp->dev->dev.parent.
It's preventing the trigger of a spurious interrupt in case the
Wake-on-Lan feature is used.
Fi
From: Nicolas Ferre
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906 ("net: macb: add wake-on-lan support via magic packet")
Signed-o
From: Nicolas Ferre
Keep previous function goals and integrate phylink actions to them.
phylink_ethtool_get_wol() is not enough to figure out if Ethernet driver
supports Wake-on-Lan.
Initialization of "supported" and "wolopts" members is done in phylink
function, no need to keep them in calling
From: Nicolas Ferre
Change the way the "magic-packet" DT property is handled in the
macb_probe() function, matching DT binding documentation.
Now we mark the device as "wakeup capable" instead of calling the
device_init_wakeup() function that would enable the wakeup source.
For Ethernet WoL, ena
From: Nicolas Ferre
As we now use the phylink call to phylink_stop() in the non-WoL path,
there is no need for this call to netif_carrier_off() anymore. It can
disturb the underlying phylink FSM.
Fixes: 7897b071ac3b ("net: macb: convert to phylink")
Signed-off-by: Nicolas Ferre
Reviewed-by: Flo
From: Nicolas Ferre
Hi,
Here is a split series to fix WoL magic-packet on the current macb driver. Only
fixes in this one based on current net/master.
Best regards,
Nicolas
Changes in v4:
- Pure bug fix series for 'net'. GEM addition and MACB update removed: will be
sent later.
Changes in
From: Nicolas Ferre
As we now use the phylink call to phylink_stop() in the non-WoL path,
there is no need for this call to netif_carrier_off() anymore. It can
disturb the underlying phylink FSM.
Fixes: 7897b071ac3b ("net: macb: convert to phylink")
Cc: Claudiu Beznea
Cc: Harini Katakam
Cc: An
From: Nicolas Ferre
Handle the Wake-on-Lan interrupt for the Cadence MACB Ethernet
controller.
As we do for the GEM version, we handle of WoL interrupt in a
specialized interrupt handler for MACB version that is positionned
just between suspend() and resume() calls.
Cc: Claudiu Beznea
Cc: Harin
From: Nicolas Ferre
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906 ("net: macb: add wake-on-lan support via magic packet")
Cc: Clau
From: Nicolas Ferre
Adapt the Wake-on-Lan feature to the Cadence GEM Ethernet controller.
This controller has different register layout and cannot be handled by
previous code.
We disable completely interrupts on all the queues but the queue 0.
Handling of WoL interrupt is done in another interrup
From: Nicolas Ferre
Hi,
Here is the 3rd series to fix WoL magic-packet on the current macb driver.
I also add, in the second part of this series the feature to GEM types of IPs.
Please tell me if they should be separated; but the two last patches cannot go
without the 5 fixes first ones.
MACB an
From: Nicolas Ferre
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
&bp->dev->dev.parent.
It's preventing the trigger of a spurious interrupt in case the
Wake-on-Lan feature is used.
Fi
From: Nicolas Ferre
Change the way the "magic-packet" DT property is handled in the
macb_probe() function, matching DT binding documentation.
Now we mark the device as "wakeup capable" instead of calling the
device_init_wakeup() function that would enable the wakeup source.
For Ethernet WoL, ena
From: Nicolas Ferre
Keep previous function goals and integrate phylink actions to them.
phylink_ethtool_get_wol() is not enough to figure out if Ethernet driver
supports Wake-on-Lan.
Initialization of "supported" and "wolopts" members is done in phylink
function, no need to keep them in calling
On 03/05/2020 at 14:32, Dejin Zheng wrote:
> A call of the function macb_init() can fail in the function
> fu540_c000_init. The related system resources were not released
> then. use devm_platform_ioremap_resource() to replace ioremap()
> to fix it.
>
> Fixes: c218ad559020ff9 ("macb: Add support f
On 18/10/2019 at 16:11, Michael Tretter wrote:
> The tx_clk, rx_clk, and tsu_clk are optional. Currently the macb driver
> marks clock as not available if it receives an error when trying to get
> a clock. This is wrong, because a clock controller might return
> -EPROBE_DEFER if a clock is not avai
On 14/05/2019 at 09:14, Luca Ceresoli wrote:
> External E-Mail
>
>
> Errors are negative numbers. Using %u shows them as very large positive
> numbers such as 4294967277 that don't make sense. Use the %d format
> instead, and get a much nicer -19.
>
> Signed-off-by: Luca Ceresoli
Indeed!
Acked
On 22/03/2019 at 11:49, Alexander Dahl wrote:
> External E-Mail
>
>
> Hei hei,
>
> while bringing up support for a new SAMA5D27 based board I noticed something
> strange in the macb driver in both U-Boot and Linux. There's a function in
> both to determine if or not the IP block in the SoC is th
$subject should begin with "net: macb: "
Parshuram,
Sorry but NACK on the series.
David,
This patch series seem pretty intrusive, so I would like that you wait
for my explicit ACK before applying even next versions of it.
More comments below...
On 25/02/2019 at 18:21, Florian Fainelli wrote
On 08/02/2019 at 19:44, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Notice that, in this particular case, the /* fall through */
> comments are placed at the bottom of the case statement, which
> is
All,
On 16/01/2019 at 10:57, Nicolas Ferre wrote:
> Hi,
>
> This series collects some little modifications to DT bindings and associated
> drivers changes for supporting the upcoming SAM9X60 SoC.
>
> I took the advantage of this series for fixing some of the leftovers in DT
> bindings for reset
On 01/02/2019 at 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
Ac
On 29/01/2019 at 19:06, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement
> may
On 24/01/2019 at 14:38, Harini Katakam wrote:
> The interrupt handler contains a workaround for RX hang applicable
> to Zynq and AT91 only. Subsequent versions do not need this
AT91RM9200 only. It's not the case for other AT91 SoCs (reading errata
list for them).
That being said I have to add a
Hi David,
On 16/01/2019 at 10:57, Nicolas Ferre wrote:
> Add a new compatibility string for this product. It's using
> at91sam9260-macb layout but has a newer hardware revision: it's safer
> to use its own string.
>
> Signed-off-by: Nicolas Ferre
I'm thinking of pushing this patch with the othe
Hi Sebastian,
On 23/01/2019 at 19:34, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Jan 16, 2019 at 10:57:42AM +0100, Nicolas Ferre wrote:
>> Add support for additional reset causes and the proper compatibility
>> string for sam9x60 SoC. The restart function is the same as the samx7.
>>
>> Signed-of
Hi Rob,
On 22/01/2019 at 02:10, Rob Herring wrote:
> On Wed, Jan 16, 2019 at 10:57:40AM +0100, Nicolas Ferre wrote:
>> This removes a line left while adding the correct compatibility string for
>> sama5d3 10/100 interface. Now use the "atmel,sama5d3-macb" string.
>>
>> Signed-off-by: Nicolas Ferre
Hi Rob,
On 22/01/2019 at 02:07, Rob Herring wrote:
> On Wed, Jan 16, 2019 at 10:57:38AM +0100, Nicolas Ferre wrote:
>> Update the Reset Controller's binding to add new SoC compatibility string.
>>
>> Signed-off-by: Nicolas Ferre
>> ---
>> Documentation/devicetree/bindings/arm/atmel-sysregs.txt
On 17/12/2018 at 11:02, Claudiu Beznea - M18063 wrote:
> From: Claudiu Beznea
>
> On some platforms (currently detected only on SAMA5D4) TX might stuck
> even the pachets are still present in DMA memories and TX start was
> issued for them. This happens due to race condition between MACB driver
>
On 07/12/2018 at 13:04, Anssi Hannula wrote:
> On 5.12.2018 22:35, David Miller wrote:
>> From: Anssi Hannula
>> Date: Fri, 30 Nov 2018 20:21:34 +0200
>>
>>> Here are a couple of race condition fixes for the macb driver. The first
>>> two are issues observed on real HW.
>> It looks like there is s
On 30/11/2018 at 19:21, Anssi Hannula wrote:
> Hi all,
>
> Here are a couple of race condition fixes for the macb driver. The first
> two are issues observed on real HW.
>
> Anssi Hannula (3):
>net: macb: fix random memory corruption on RX with 64-bit DMA
>net: macb: fix dropped R
47 matches
Mail list logo
