Hi Andreas,
On 08.03.2021 21:30, Andreas Schwab wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> One of the changes to the macb driver between 5.10 and 5.11 has broken
> the SiFive HiFive Unleashed. These are the last messages before the
On 11.02.2021 23:32, Heiner Kallweit wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Claudiu reported that on his system S2R cuts off power to the PHY and
> after resuming certain PHY settings are lost. The PM folks confirmed
> that cuttin
Hi, Rafael, Pavel,
I know you may be busy. Just a gentle ping on this topic. It would be nice
to have your input in this.
Thank you,
Claudiu Beznea
On 14.01.2021 13:05, Heiner Kallweit wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On
On 22.01.2021 13:20, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-01-22 10:10, schrieb claudiu.bez...@microchip.com:
>> On 21.01.2021 11:41, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open atta
On 21.01.2021 11:41, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Claudiu,
>
> Am 2021-01-21 10:19, schrieb claudiu.bez...@microchip.com:
>> On 20.01.2021 21:43, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click l
Hi Michael,
On 20.01.2021 21:43, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> If the MII interface is used, the PHY is the clock master, thus don't
> set the clock rate. On Zynq-7000, this will prevent the following
> war
On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
>
> As I've said, if phylib/PHY driver is not restoring the state of the
> PHY on resume from suspend-to-ram, then that's an issue with phylib
> and/or the phy driver.
In the patch I proposed in this thread the restoring is done in PHY
Hi, Rafael, Pavel,
I recently posted a patch for re-configuring an ethernet PHY on its
.resume() callback as this PHY is in a setup with SAMA7G5 SoC that supports
a power saving mode (called backup). In this power saving mode most of the
SoC devices' power is cut of (except the RAM + its controlle
On 13.01.2021 13:09, Heiner Kallweit wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 13.01.2021 10:29, claudiu.bez...@microchip.com wrote:
>> Hi Heiner,
>>
>> On 08.01.2021 18:31, Heiner Kallweit wrote:
>>> EXTERNAL EMAIL: Do not clic
Hi Heiner,
On 08.01.2021 18:31, Heiner Kallweit wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 08.01.2021 16:45, Claudiu Beznea wrote:
>> KSZ9131 is used in setups with SAMA7G5. SAMA7G5 supports a special
>> power saving mode (backup
Hi Charles,
On 04.01.2021 12:38, Charles Keepax wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> A new flag MACB_CAPS_CLK_HW_CHG was added and all callers of
> macb_set_tx_clk were gated on the presence of this flag.
>
> - if (!clk)
> +
Hi Andrew,
On 05.12.2020 16:30, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Fri, Dec 04, 2020 at 02:34:17PM +0200, Claudiu Beznea wrote:
>> Unprepare clocks in case of any failure in fu540_c000_clk_init().
>
> Hi Claud
Hi Willy,
On 14.10.2020 19:27, Willy Tarreau wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Claudiu,
>
> first, thanks for your feedback!
>
> On Wed, Oct 14, 2020 at 04:08:00PM +, claudiu.bez...@microchip.com wrote:
>>> @@ -3994
Hi Willy,
On 11.10.2020 12:09, Willy Tarreau wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The at91rm9200 variant used by a few chips including the MSC313 supports
> two Tx descriptors (one frame being serialized and another one queued)
Hi Dinghao,
On 20.08.2020 08:52, Dinghao Liu wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> When devm_clk_get() returns -EPROBE_DEFER, spi_priv
> should be freed just like when wilc_cfg80211_init()
> fails.
>
> Fixes: 854d66df74aed ("st
On 20.08.2020 08:48, Dinghao Liu wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> When devm_clk_get() returns -EPROBE_DEFER, sdio_priv
> should be freed just like when wilc_cfg80211_init()
> fails.
>
> Fixes: 8692b047e86cf ("staging: wil
On 23.07.2020 21:59, Florian Fainelli wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 7/21/20 10:13 AM, Codrin Ciubotariu wrote:
>> The MACB embeds an MDIO bus controller. For this reason, the PHY nodes
>> were represented as sub-node
On 22.07.2020 14:38, Codrin Ciubotariu - M19940 wrote:
> On 22.07.2020 13:32, Claudiu Beznea - M18063 wrote:
>>
>>
>> On 21.07.2020 20:13, Codrin Ciubotariu wrote:
>>> Adding the PHY nodes directly under the Ethernet node became deprecated,
>>> so the aim of this patch series is to make MACB use
On 21.07.2020 20:13, Codrin Ciubotariu wrote:
> Adding the PHY nodes directly under the Ethernet node became deprecated,
> so the aim of this patch series is to make MACB use an MDIO node as
> container for MDIO devices.
> This patch series starts with a small patch to use the device-managed
> de
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 handled by
> previous code.
> We disable completely interrupts on all
Hi Andrew, Florian,
On 30.06.2020 06:35, Florian Fainelli wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 6/29/2020 5:45 PM, Andrew Lunn wrote:
>> On Mon, Jun 29, 2020 at 10:26:36AM +0300, Claudiu Beznea wrote:
>>> In case of_mdiobus_r
Please ignore this one!
I'll send a v2.
On 24.06.2020 10:26, Claudiu Beznea wrote:
> DMA buffers were not freed on failure path of at91ether_open().
> Along with changes for freeing the DMA buffers the enable/disable
> interrupt instructions were moved to at91ether_start()/at91ether_stop()
> funct
On 30.04.2020 13:34, Andy Shevchenko wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Thu, Apr 30, 2020 at 07:59:41AM +, claudiu.bez...@microchip.com wrote:
>>
>>
>> On 27.04.2020 13:51, Andy Shevchenko wrote:
>>> EXTERNAL EMAIL: D
On 27.04.2020 13:51, Andy Shevchenko wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The commit e6a41c23df0d, while trying to fix an issue,
>
> ("net: macb: ensure interface is not suspended on at91rm9200")
>
> introduced a refcoun
On 23.09.2019 11:33, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> macb_64b_desc is always called when HW_DMA_CAP_64B is defined.
> So the return NULL can never be reached. Remove the dead code.
>
> Signed-off-by: Shubhrajyoti Datta
Reviewed-by: Claudiu Beznea
> ---
>
On 16.09.2019 13:14, Andreas Schwab wrote:
> External E-Mail
>
>
> On Sep 16 2019, wrote:
>
>> I will have a look on it. It would be good if you could give me some
>> details about the steps to reproduce it.
>
> You need to trigger OOM.
Ok, thank you!
>
> Andreas.
>
Hi Andreas,
I will have a look on it. It would be good if you could give me some
details about the steps to reproduce it.
Thank you,
Claudiu Beznea
On 16.09.2019 10:41, Andreas Schwab wrote:
> When there is an OOM situation, the macb driver cannot recover from it:
>
> [245622.872993] macb 10090
Hi Klaus,
Thanks for reporting this.
On 09.03.2019 07:50, Harini Katakam wrote:
> Hi Klaus,
>
>> -Original Message-
>> From: Klaus Doth [mailto:k...@doth.eu]
>> Sent: Friday, March 8, 2019 10:19 PM
>> To: netdev@vger.kernel.org
>> Cc: da...@davemloft.net; claudiu.bez...@microchip.com; Ha
On 12.02.2019 18:00, Yang Wei wrote:
> From: Yang Wei
>
> dev_consume_skb_irq() should be called in at91ether_interrupt() when
> skb xmit done. It makes drop profiles(dropwatch, perf) more friendly.
>
> Signed-off-by: Yang Wei
Reviewed-by: Claudiu Beznea
> ---
> drivers/net/ethernet/caden
From: Claudiu Beznea
Commit 653e92a9175e ("net: macb: add support for padding and fcs
computation") introduced a bug fixed by commit 899ecaedd155 ("net:
ethernet: cadence: fix socket buffer corruption problem"). Code removed
in this patch is not reachable at all so remove it.
Fixes: 653e92a9175e
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
updating next TX buffer descriptor to be used and IP reading the s
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
updating next TX buffer descriptor to be used and IP reading the s
On 12.12.2018 13:27, Anssi Hannula wrote:
> On 12.12.2018 12:58, claudiu.bez...@microchip.com wrote:
>>
>> On 11.12.2018 15:21, Anssi Hannula wrote:
>>> On 10.12.2018 12:34, claudiu.bez...@microchip.com wrote:
On 07.12.2018 14:00, Anssi Hannula wrote:
> On 6.12.2018 16:14, claudiu.bez...
On 11.12.2018 15:21, Anssi Hannula wrote:
> On 10.12.2018 12:34, claudiu.bez...@microchip.com wrote:
>> On 07.12.2018 14:00, Anssi Hannula wrote:
>>> On 6.12.2018 16:14, claudiu.bez...@microchip.com wrote:
Hi Anssi,
>>> Hi!
>>>
On 05.12.2018 16:00, Anssi Hannula wrote:
> On 5.12.201
On 10.12.2018 13:32, claudiu.bez...@microchip.com wrote:
>
>
> On 10.12.2018 12:58, Nicolas Ferre - M43238 wrote:
>> 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
On 10.12.2018 12:58, Nicolas Ferre - M43238 wrote:
> 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
tw
On 07.12.2018 14:00, Anssi Hannula wrote:
> On 6.12.2018 16:14, claudiu.bez...@microchip.com wrote:
>> Hi Anssi,
>
> Hi!
>
>> On 05.12.2018 16:00, Anssi Hannula wrote:
>>> On 5.12.2018 14:37, claudiu.bez...@microchip.com wrote:
On 30.11.2018 20:21, Anssi Hannula wrote:
> When reading b
Hi David,
Please ignore this one for the moment, I'll have to run few more tests on it.
Thank you,
Claudiu Beznea
On 06.12.2018 19:44, Claudiu Beznea - M18063 wrote:
> From: Claudiu Beznea
>
> On some platforms (currently detected only on SAMA5D4) TX might stuck
> even the pachets are still pr
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
updating next TX buffer descriptor to be used and IP reading the s
On 05.12.2018 22:32, David Miller wrote:
> From: Anssi Hannula
> Date: Fri, 30 Nov 2018 20:21:35 +0200
>
>> @@ -682,6 +682,11 @@ static void macb_set_addr(struct macb *bp, struct
>> macb_dma_desc *desc, dma_addr_
>> if (bp->hw_dma_cap & HW_DMA_CAP_64B) {
>> desc_64 = macb_64b
Hi Anssi,
On 05.12.2018 16:00, Anssi Hannula wrote:
> On 5.12.2018 14:37, claudiu.bez...@microchip.com wrote:
>>
>> On 30.11.2018 20:21, Anssi Hannula wrote:
>>> When reading buffer descriptors on RX or on TX completion, an
>>> RX_USED/TX_USED bit is checked first to ensure that the descriptor has
On 30.11.2018 20:21, Anssi Hannula wrote:
> Bit RX_USED set to 0 in the address field allows the controller to write
> data to the receive buffer descriptor.
>
> The driver does not ensure the ctrl field is ready (cleared) when the
> controller sees the RX_USED=0 written by the driver. The ctrl
On 30.11.2018 20:21, Anssi Hannula wrote:
> When reading buffer descriptors on RX or on TX completion, an
> RX_USED/TX_USED bit is checked first to ensure that the descriptor has
> been populated. However, there are no memory barriers to ensure that the
> data protected by the RX_USED/TX_USED bit
Hi Anssi,
Few comments... Otherwise I tested this series on a SAMA5D2 Xplained and
SAMA5D4 Xplained under heavy traffic and it seems to behave OK.
Thank you,
Claudiu Beznea
On 30.11.2018 20:21, Anssi Hannula wrote:
> 64-bit DMA addresses are split in upper and lower halves that are
> written in
On 29.11.2018 12:38, Harini Katakam wrote:
> Hi Claudiu,
> On Thu, Nov 29, 2018 at 3:51 PM wrote:
>>
>>
>>
>> On 23.11.2018 11:59, Harini Katakam wrote:
>
>>> - if (status & MACB_BIT(RXUBR)) {
>>> + if ((bp->errata & MACB_ERRATA_RXLOCKUP) &&
>>> + (status
On 28.11.2018 02:35, Andrew Lunn wrote:
>> Then, do you think it would be better to have a new API part of struct
>> mii_bus that drivers should register so that, the mii core to check if the
>> bus is idle before lunching a new request?
>
> I'm not sure that actually brings anything useful. Th
On 23.11.2018 11:59, Harini Katakam wrote:
> The interrupt handler contains a workaround for RX hang applicable
> to Zynq and AT91 only. Subsequent versions do not need this
> workaround. This workaround unecessarily reset RX whenever RX used
> bit read is observed, which can be often under heavy
On 28.11.2018 23:09, Brandon Streiff wrote:
> On 11/23/2018 3:59 AM, Harini Katakam wrote:
>> +/* Errata mask bits */
>> +#define MACB_ERRATA_RXLOCKUP0x0001
>> +
>> /* LSO settings */
>> #define MACB_LSO_UFO_ENABLE 0x01
>> #define MACB_LSO_TSO_ENABLE
Hi Harini,
On 27.11.2018 08:25, Harini Katakam wrote:
> Hi Claudiu,
>
> On Mon, Nov 26, 2018 at 8:16 PM wrote:
>>
>>
>>
>> On 26.11.2018 09:07, Harini Katakam wrote:
>
>>
>> In the previous version you said you encountered some crashes while
>> stressing this part if macb_open()/macb_close() wa
Hi Andrew, Harini,
On 27.11.2018 07:36, Harini Katakam wrote:
> Hi Claudiu,
> On Mon, Nov 26, 2018 at 8:22 PM Andrew Lunn wrote:
>>
>> On Mon, Nov 26, 2018 at 02:46:01PM +, claudiu.bez...@microchip.com wrote:
>>> Hi Harini,
>>>
>>> On 26.11.2018 09:07, Harini Katakam wrote:
From: Harini
On 26.11.2018 09:07, Harini Katakam wrote:
> From: Harini Katakam
>
> Add runtime pm functions and move clock handling there.
> Add runtime PM calls to mdio functions to allow for active mdio bus.
>
> Signed-off-by: Shubhrajyoti Datta
> Signed-off-by: Harini Katakam
> ---
> v2 changes:
> All
On 26.11.2018 09:07, Harini Katakam wrote:
> When macb device is suspended and system is powered down, the clocks
> are removed and hence macb should be closed gracefully and restored
> upon resume. This patch does the same by switching off the net device,
> suspending phy and performing necessar
Hi Harini,
On 26.11.2018 09:07, Harini Katakam wrote:
> From: Harini Katakam
>
> Replace the while loop in MDIO read/write functions with a timeout.
> In addition, add a check for MDIO bus busy before initiating a new
> operation as well to make sure there is no ongoing MDIO operation.
Is this
On 30.10.2018 21:36, Tristram Ha - C24268 wrote:
>> Could you check on your side that applying this on top of your patch, your
>> scenario is still working?
>>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>> b/drivers/net/ethernet/cadence/macb_main.c
>> index 1d86b4d5645a..e1347d6d1b5
On 29.10.2018 23:40, Tristram Ha - C24268 wrote:
>> Could you, please, tell me if the above variable was false in your case?
>>
>> bool cloned = skb_cloned(*skb) || skb_header_cloned(*skb);
>>
>> If yes, then, the proper fix would be as follows:
>>
>> diff --git a/drivers/net/ethernet/cadence/mac
Hi Tristram,
Could you, please, tell me if the above variable was false in your case?
bool cloned = skb_cloned(*skb) || skb_header_cloned(*skb);
If yes, then, the proper fix would be as follows:
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
in
56 matches
Mail list logo
