> Hi all,
>
> This patch series adds support for retrieving PHY statistics with DSA switches
> when the CPU port uses a PHY to PHY connection (as opposed to MAC to MAC).
> To get there a number of things are done:
Tested-By: Nikita Yushchenko <nikita.yo...@cogentembedded.com
> Hi,
>
> I am getting the following kernel crash with linux-next 20170208
> running on a imx53-qsb board.
>
> Any ideas?
Same here, on zii-dev-revB and zii-dev-revC boards.
Crash is in phy_attach_direct() in line
if (!try_module_get(d->driver->owner)) {
caused by d->driver being NULL.
where such restriction might be inconvenient,
> consider a hardware design where "rstn" is connected to a pin of I2C/SPI
> GPIO expander chip.
>
> Cc: Chris Healy <cphe...@gmail.com>
> Signed-off-by: Andrey Smirnov <andrew.smir...@gmail.com>
Reviewed-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
increase, Rx architecture
change is needed.
Use of MTU=1956 gives about 1.5% throughput improvement between two Vybrid
boards, compared to default MTU=1500.
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
drivers/net/ethernet/freescale/fec.h | 2 +
drivers/net/et
t handling of !defined(CONFIG_M5272) case.
Fixes: 80cca775cdc4 ("net: fec: cache statistics while device is down")
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
Changes from v3:
- fix reference commit id to match upstream tree
drivers/net/ethernet
> +#define FEC_STATS_SIZE (ARRAY_SIZE(fec_stats) * sizeof(u64))
>
>
> Do I take it right this actually translates to (sizeof(fec_stats) /
> sizeof(u64) * sizeof(u64))?
No.
fec_stats is an array of structs, each struct has car arrsy and integer,
and size of that is definitely not
t handling of !defined(CONFIG_M5272) case.
Fixes: 4dfb80d18d05 ("net: fec: cache statistics while device is down")
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
Changes since v2:
- fix typo that caused compile problem, double-check that it compiles
and works
> From: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
> Date: Mon, 5 Dec 2016 16:55:04 +0300
>
>> Aieee I was typing too fast today, sorry...
>>
>> send separate "fix for the fix", or re-send patch without that silly typo?
>
> If the
;
> Aieee I was typing too fast today, sorry...
>
> send separate "fix for the fix", or re-send patch without that silly typo?
>
> Nikita
>
>> Hi Nikita,
>>
>> [auto build test ERROR on net/master]
>>
>> url:
>> https://github
Aieee I was typing too fast today, sorry...
send separate "fix for the fix", or re-send patch without that silly typo?
Nikita
> Hi Nikita,
>
> [auto build test ERROR on net/master]
>
> url:
> https://github.com/0day-ci/linux/commits/Nikita-Yu
t handling of !defined(CONFIG_M5272) case.
Fixes: 4dfb80d18d05 ("net: fec: cache statistics while device is down")
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
Changes since v1:
- instead of #ifdef'ing calls to fec_enet_update_ethtool_stats(),
f !defined(CONFIG_M5272).
Fixes: 4dfb80d18d05 ("net: fec: cache statistics while device is down")
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
drivers/net/ethernet/freescale/fec_main.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
>> (1) When DSA is in use, frames processed by FEC chip contain DSA tag and
>> thus can be larger than hardcoded limit of 1522. This issue is not
>> FEC-specific, any driver that hardcodes maximum frame size to 1522 (many
>> do) will have this issue if used with DSA.
>
> BTW I'm trying to
> But I think it is not necessary since the driver don't support jumbo frame.
Hardcoded 1522 raises two separate issues.
(1) When DSA is in use, frames processed by FEC chip contain DSA tag and
thus can be larger than hardcoded limit of 1522. This issue is not
FEC-specific, any driver that
size up to entire buffer.
At the same time possible Tx size is increased as well, because hardware
uses the same register field to limit Rx and Tx.
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
drivers/net/ethernet/freescale/fec_main.
is not needed, since cached statistics is accessed
either before device is registered, or under rtnl_lock().
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
Changes since v1:
- initialize cache at device probe time
drivers/net/ethernet/freescale/fec.h | 2 ++
d
> >
> >+ fec_enet_update_ethtool_stats(ndev);
> >+
> If user never open the interface, ethtool_stats[] always is 0 that are not
> expected.
> So, it also should be called at . fec_enet_init() ?
I don't think that zero stats is wrong for never-opened interface.
However a call at init path
statistics is always
updated under rtnl_lock().
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
drivers/net/ethernet/freescale/fec.h | 2 ++
drivers/net/ethernet/freescale/fec_main.c | 21 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff
28.11.2016 04:29, David Miller пишет:
> From: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
> Date: Fri, 25 Nov 2016 13:02:00 +0300
>
>> +int i, ret;
>> +
>> +ret = pm_runtime_get_sync(>pdev->dev);
>> +if (IS_ERR_VALUE(ret)) {
,
and later access to sysfs attributes of that switch cause OOPS.
To fix, need to add kref_get() call to dsa_get_dst().
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
Fixes: 83c0afaec7b7 ("net: dsa: Add new binding implementation")
Reviewed-by: Andrew Lunn <and..
,
and later access to sysfs attributes of that switch cause OOPS.
To fix, need to add kref_get() call to dsa_get_dst().
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
net/dsa/dsa2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/dsa/dsa2.c b/n
is that fec_enet_get_ethtool_stats() accesses fec
registers while IPG clock is stopped by PM.
Fix that by wrapping statistics extraction into pm_runtime_get_sync()
... pm_runtime_put_autosuspend() braces.
Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com>
---
drivers/net/ethernet/fre
>>> It would make more sense to update the DMA API for
>>> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if
>>> the direction is DMA_FROM_DEVICE.
>>
>> No, in generic case it's unsafe.
>>
>> If CPU issued a write to a location, and sometime later that location is
>> used as
> It would make more sense to update the DMA API for
> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if
> the direction is DMA_FROM_DEVICE.
No, in generic case it's unsafe.
If CPU issued a write to a location, and sometime later that location is
used as DMA buffer, there is
>>> To get some throughput improvement, I propose removal of that
>>> sync_for_device() before reusing buffer. Will you accept such a patch ;)
>>
>> Not one that gets rid of sync_for_device() in the driver. From what I
>> can tell there are some DMA APIs that use that to perform the
>>
>>> The main reason why this isn't a concern for the igb driver is because
>>> we currently pass the page up as read-only. We don't allow the stack
>>> to write into the page by keeping the page count greater than 1 which
>>> means that the page is shared. It isn't until we unmap the page that
Hi Alexander
Thanks for your explanation.
> The main reason why this isn't a concern for the igb driver is because
> we currently pass the page up as read-only. We don't allow the stack
> to write into the page by keeping the page count greater than 1 which
> means that the page is shared. It
>> All the data has been synced
>
> Non-synced data is write done by CPU executing upper layers of network stack,
Upper layers shall never get area that is still dma_map()ed and will be
dma_unmap()ed in future. But with igb, this is exactly what happens.
>> Hmm... I'm not about device writing to memory.
>
> This absolutely is about whether the device wrote into the
> area or not.
Not only.
>> Sequence in igb driver is:
>>
>> dma_map(full_page)
>>
>> sync_to_cpu(half_page);
>> skb_add_rx_frag(skb, half_page);
>> napi_gro_receive(skb);
>>
>> With this scheme, page used for Rx is completely dma_map()ed at
>> allocation time, split into two buffers, and individual buffer is
>> sync_to_cpu()ed AND PASSED TO NETWORK STACK via skb_add_rx_frag() -
>> while driver driver still uses other buffer. Later, when driver decides
>> to no longer
.
Could somebody please comment on this?
Nikita Yushchenko
31 matches
Mail list logo
