* Re: [PATCH] net: ethernet: cpsw-phy-sel: prefer phandle for phy sel and update binding
From: Tony Lindgren @ 2018-08-08 13:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, linux-omap, devicetree, Grygorii Strashko,
Ivan Khoronzhuk, Mark Rutland, Murali Karicheri, Rob Herring
In-Reply-To: <20180808115838.GA18314@lunn.ch>
* Andrew Lunn <andrew@lunn.ch> [180808 12:02]:
> > +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> > @@ -19,6 +19,9 @@ Required properties:
> > - slaves : Specifies number for slaves
> > - active_slave : Specifies the slave to use for time stamping,
> > ethtool and SIOCGMIIPHY
> > +- cpsw-phy-sel : Specifies the phandle to the CPSW phy mode selection
> > + device. Note that in legacy cases cpsw-phy-sel may be
> > + a child device instead of a phandle.
>
> Hi Tony
>
> It would be good to reference cpsw-phy-sel.txt.
OK will add.
> > --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
> > +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> > @@ -170,10 +170,13 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
> > struct device_node *node;
> > struct cpsw_phy_sel_priv *priv;
> >
> > - node = of_get_child_by_name(dev->of_node, "cpsw-phy-sel");
> > + node = of_parse_phandle(dev->of_node, "cpsw-phy-sel", 0);
> > if (!node) {
>
> Do you need to handle EPROBE_DEFER here? The phandle points to a
> device which has not yet been loaded? I'm not sure exactly where it
> will be returned, maybe it is bus_find_device(), but i expect to see
> some handling of it somewhere in this function.
With the proper interconnect hierarchy in the device tree there should be
no EPROBE_DEFER happening here as the interconnects are probed in the
right order with the always on interrupt with system control module first :)
But then again, adding support for EPROBE_DEFER here won't hurt either,
will take a look.
Regards,
Tony
^ permalink raw reply
* Re: Is it currently possible to connect SFP to dsa port?
From: Andrew Lunn @ 2018-08-08 13:52 UTC (permalink / raw)
To: Marek Behún; +Cc: netdev, Russell King - ARM Linux
In-Reply-To: <20180808150013.250727c7@dellmb.labs.office.nic.cz>
> Let me know when you have the first version ready, I will try it. Our
> router can connect SFP board directly to the CPU board, or there may up
> to three mv88e6190 switch boards between SFP board and cpu board.
So you are using D in DSA? The board i'm using has two SFF modules,
both on the second switch in the chain. But D in DSA makes no
difference to SFPs.
> Do you already have a stable dts binding for how to bind sfp to dsa
> port?
Nothing special is needed. It just follows the standard SFP binding
for a MAC port. The DT changes for the board i'm using will be part of
the patchset i send.
> The mv88e6190/6390 can configure ports 9 and 10 to either
> 1000BASE-X/SGMII od 2500BASE-X, but this has to be done by setting a
> pin and reseting the switch.
I've been using 6390X, not 6390. The cmode nibble is writable for
ports 9 and 10. So you can change between 1000BASE-X, SGMII and
2500BASE-X by writing to the cmode. I assume 6390 is the same. As
Russell pointed out, you need this dynamic behaviour, since SFP
modules are hot pluggable, and you need to configure the mode
depending on what the module is. Also, what the peer is can also make
a difference. The board i have, the MAC/SFF combination can do
2500Base-X, by my peer cannot. Phylink defaults to 2500Base-X, so i
need to use ethtool to force it to 1000Base-X in order to get a link
with the peer.
Andrew
^ permalink raw reply
* Re: [PATCH 03/28] nvmem: add a notifier chain
From: Andrew Lunn @ 2018-08-08 16:13 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-4-brgl@bgdev.pl>
On Wed, Aug 08, 2018 at 05:31:25PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Add a blocking notifier chain with two events (add and remove) so that
> users can get notified about the addition of nvmem devices they're
> waiting for.
>
> We'll use this instead of the at24 setup callback in the mityomapl138
> board file.
Hi Bartosz
What context is this notifier chain called in?
I did something similar using the i2c notifier to try to work around
the impending disappearing of the setup callback. But i got lockdep
splats, because the notifier was called while some locks were being
held, so it was not possible to register other i2c devices.
The at24 setup callback is done as part of probe, so no important
locks are held. Are any locks held when this notifier chain is called?
Thanks
Andrew
^ permalink raw reply
* Re: Hello
From: Heba Oudeh @ 2018-08-08 13:19 UTC (permalink / raw)
Dear Sir/Madam,
My name is Heba Oudeh from Damascus Syria, i am 28 years old. I contacted you to know if you can
help me to claim my inheritance. Please do not misunderstand this message because you are the 4th
person i have sent this message to and they called me lots of names. Please i beg you, if you are
not confortable with my request, kindly do not reply. If you can assist me, please reply to this
Email:hebaoudeh22@gmail.com
Best Regards,
Heba Oudeh
^ permalink raw reply
* Re: [PATCH 06/28] mtd: Add support for reading MTD devices via the nvmem API
From: Andrew Lunn @ 2018-08-08 16:20 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-7-brgl@bgdev.pl>
On Wed, Aug 08, 2018 at 05:31:28PM +0200, Bartosz Golaszewski wrote:
> From: Alban Bedel <albeu@free.fr>
>
> Allow drivers that use the nvmem API to read data stored on MTD devices.
> For this the mtd devices are registered as read-only NVMEM providers.
> On OF systems only devices that have the 'nvmem-provider' property
> are registered, on non-OF system all MTD devices are registered.
> @@ -570,6 +613,11 @@ int add_mtd_device(struct mtd_info *mtd)
> if (error)
> goto fail_added;
>
> + /* Add the nvmem provider */
> + error = mtd_nvmem_add(mtd);
> + if (error)
> + goto fail_nvmem_add;
> +
Hi Bartosz
Maybe it is hiding somewhere, but i don't see any code looking into
device tree looking for the 'nvmem-provider' property.
Andrew
^ permalink raw reply
* Re: [PATCH 06/28] mtd: Add support for reading MTD devices via the nvmem API
From: Bartosz Golaszewski @ 2018-08-08 16:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner
In-Reply-To: <20180808162042.GG7275@lunn.ch>
2018-08-08 18:20 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
> On Wed, Aug 08, 2018 at 05:31:28PM +0200, Bartosz Golaszewski wrote:
>> From: Alban Bedel <albeu@free.fr>
>>
>> Allow drivers that use the nvmem API to read data stored on MTD devices.
>> For this the mtd devices are registered as read-only NVMEM providers.
>> On OF systems only devices that have the 'nvmem-provider' property
>> are registered, on non-OF system all MTD devices are registered.
>> @@ -570,6 +613,11 @@ int add_mtd_device(struct mtd_info *mtd)
>> if (error)
>> goto fail_added;
>>
>> + /* Add the nvmem provider */
>> + error = mtd_nvmem_add(mtd);
>> + if (error)
>> + goto fail_nvmem_add;
>> +
>
> Hi Bartosz
>
> Maybe it is hiding somewhere, but i don't see any code looking into
> device tree looking for the 'nvmem-provider' property.
>
> Andrew
Ugh, I copied the commit message from Alban's patch. For the moment
there's no such thing, you're right. I'll fix it for v2.
Bart
^ permalink raw reply
* Re: [PATCH bpf-next 12/13] docs: net: Fix various minor typos
From: Markus Heiser @ 2018-08-08 16:26 UTC (permalink / raw)
To: Daniel Borkmann, Jonathan Corbet, Tobin C. Harding
Cc: Alexei Starovoitov, David S. Miller, linux-doc, netdev,
linux-kernel
In-Reply-To: <99c50323-601e-91ea-cac3-98c1f381f9ac@iogearbox.net>
Am Mittwoch, den 08.08.2018, 15:45 +0200 schrieb Daniel Borkmann:
> On 08/08/2018 03:23 PM, Jonathan Corbet wrote:
> > On Wed, 8 Aug 2018 11:42:48 +1000
> > "Tobin C. Harding" <me@tobin.cc> wrote:
> >
> > > Thanks for doing such a careful review that you noticed this. I'm
> > > working on this more ATM and I've moved the document to use double
> > > spaces between _all_ full stops. Currently the document uses mostly
> > > single spaces but there are some sections with double space. The
> > > internet tells me this is a 'style' issue not a rule. And I've seen
> > > single and double spacing in tree and do not know if one is favoured.
> > >
> > > Do you care?
> >
> > I'm not Daniel, but let me just say that, for docs in general, I'm
> > absolutely uninterested in patches adjusting the number of spaces after
> > periods. It really doesn't matter one way or the other, and I don't think
> > we benefit from that kind of churn.
>
> Yep, agree.
FWIW: even if it is not a patch worth, 'fill-paragraph' within emacs benefit
from.
-- Markus --
^ permalink raw reply
* Re: [PATCH v6 8/9] net/mlx5: Do not call pcie_print_link_status()
From: Alex G. @ 2018-08-08 16:33 UTC (permalink / raw)
To: Tal Gilboa, Leon Romanovsky
Cc: linux-pci, bhelgaas, jakub.kicinski, keith.busch, alex_gagniuc,
austin_bolen, shyam_iyer, Ariel Elior, everest-linux-l2,
David S. Miller, Michael Chan, Ganesh Goudar, Jeff Kirsher,
Tariq Toukan, Saeed Mahameed, Dirk van der Merwe, netdev,
linux-kernel, intel-wired-lan, linux-rdma, oss-drivers
In-Reply-To: <5578cd9a-e4f0-85ab-4a86-bfa23eec136c@mellanox.com>
On 08/08/2018 10:56 AM, Tal Gilboa wrote:
> On 8/8/2018 6:41 PM, Leon Romanovsky wrote:
>> On Wed, Aug 08, 2018 at 05:23:12PM +0300, Tal Gilboa wrote:
>>> On 8/8/2018 9:08 AM, Leon Romanovsky wrote:
>>>> On Mon, Aug 06, 2018 at 06:25:42PM -0500, Alexandru Gagniuc wrote:
>>>>> This is now done by the PCI core to warn of sub-optimal bandwidth.
>>>>>
>>>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>>>>> ---
>>>>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ----
>>>>> 1 file changed, 4 deletions(-)
>>>>>
>>>>
>>>> Thanks,
>>>> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
>>>>
>>>
>>> Alex,
>>> I loaded mlx5 driver with and without these series. The report in
>>> dmesg is
>>> now missing. From what I understood, the status should be reported at
>>> least
>>> once, even if everything is in order.
>>
>> It is not what this series is doing and it removes prints completely if
>> fabric can deliver more than card is capable.
>>
>>> We need this functionality to stay.
>>
>> I'm not sure that you need this information in driver's dmesg output,
>> but most probably something globally visible and accessible per-pci
>> device.
>
> Currently we have users that look for it. If we remove the dmesg print
> we need this to be reported elsewhere. Adding it to sysfs for example
> should be a valid solution for our case.
I think a stop-gap measure is to leave the pcie_print_link_status() call
in drivers that really need it for whatever reason. Implementing a
reliable reporting through sysfs might take some tinkering, and I don't
think it's a sufficient reason to block the heart of this series --
being able to detect bottlenecks and link downtraining.
Alex
>>
>>>
>>> net-next (dmesg output for 07:00.0):
>>> [270498.625351] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
>>> [270498.632130] mlx5_core 0000:07:00.0: 63.008 Gb/s available PCIe
>>> bandwidth
>>> (8 GT/s x8 link)
>>> [270499.169533] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
>>> uc(1024) max mc(16384)
>>> [270499.182358] mlx5_core 0000:07:00.0: Port module event: module 0,
>>> Cable
>>> plugged
>>>
>>> net-next + patches (dmesg output for 07:00.0):
>>> [ 331.608472] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
>>> [ 332.564938] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
>>> uc(1024) max mc(16384)
>>> [ 332.616271] mlx5_core 0000:07:00.0: Port module event: module 0,
>>> Cable
>>> plugged
>>>
>>>
^ permalink raw reply
* Re: [PATCH net-next 13/14] net: core: add new/replace rate estimator lock parameter
From: Marcelo Ricardo Leitner @ 2018-08-08 14:18 UTC (permalink / raw)
To: Vlad Buslov
Cc: netdev, davem, jhs, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, keescook
In-Reply-To: <vbfo9ed2g7i.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Wed, Aug 08, 2018 at 03:30:41PM +0300, Vlad Buslov wrote:
> On Wed 08 Aug 2018 at 01:37, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> > On Mon, Aug 06, 2018 at 09:54:24AM +0300, Vlad Buslov wrote:
> >> Extend rate estimator 'new' and 'replace' APIs with additional spinlock
> >> parameter to be used by rtnl-unlocked actions to protect rate_est pointer
> >> from concurrent modification.
> >
> > I'm wondering if this additional parameter is really needed. So far,
> > the only case in which it is not NULL, the same lock that is used to
> > protect the stats is also used in this new parameter.
> >
> > ...
> >
> >> --- a/net/sched/act_police.c
> >> +++ b/net/sched/act_police.c
> >> @@ -138,7 +138,7 @@ static int tcf_act_police_init(struct net *net, struct nlattr *nla,
> >>
> >> if (est) {
> >> err = gen_replace_estimator(&police->tcf_bstats, NULL,
> >> - &police->tcf_rate_est,
> >> + &police->tcf_rate_est, NULL,
> >> &police->tcf_lock,
> >> NULL, est);
> >
> > Which is here, and this new NULL arg is replaced by &police->tcf_lock
> > in the next patch.
> >
> > Do you foresee a case in which a different lock will be used?
>
> Not in my use-case, no.
>
> > Or maybe it is because the current one is explicitly aimed towards the
> > stats?
>
> Yes, stats lock is only taken when fetching counters. You think better
> approach would be to rely on the fact that, in case of police action,
> same lock is already passed as stats lock? Having it as standalone
And the fact that we have no foreseeable user of two different locks.
> argument looked like cleaner approach to me. If you think this change is
> too much code for very little benefit, I can reuse stats lock.
That's my current thinking, yes. Especially considering the amount of
parameters this function already has, I would refrain from adding yet
another unless really needed.
Maybe s/stats_lock/lock/ in function parameter (struct member doesn't
need to be changed) and doctext:
* @lock: lock for statistics and control path.
wdyt?
>
> >
> > Marcelo
>
> Thank you for reviewing my code!
^ permalink raw reply
* editing the images
From: Julian Jones @ 2018-08-08 12:01 UTC (permalink / raw)
To: netdev
You have needs for image editing for our studio?
Our studio does different image editing for e-commerce photos, jewelry
images, and portrait mages.
It includes cutting out and clipping path and the others, like retouching
etc.
Drop us a photo, testing will be provided.
Thanks,
Julian
^ permalink raw reply
* Re: [PATCH 2/3] net:af_iucv: get rid of the unneeded variable 'err' in afiucv_pm_freeze
From: David Miller @ 2018-08-08 16:41 UTC (permalink / raw)
To: zhongjiang; +Cc: anna.schumaker, netdev, linux-kernel
In-Reply-To: <1533640809-1221-3-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Tue, 7 Aug 2018 19:20:08 +0800
> We will not use the variable 'err' after initalization, So remove it and
> return 0.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 3/3] net:mod: remove unneeded variable 'ret' in init_p9
From: David Miller @ 2018-08-08 16:41 UTC (permalink / raw)
To: zhongjiang; +Cc: anna.schumaker, netdev, linux-kernel
In-Reply-To: <1533640809-1221-4-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Tue, 7 Aug 2018 19:20:09 +0800
> The ret is modified after initalization, so just remove it and
> return 0.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH 00/28] at24: remove at24_platform_data
From: Andrew Lunn @ 2018-08-08 16:44 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Wolfram Sang, Sekhar Nori, Srinivas Kandagatla, linux-i2c,
Mauro Carvalho Chehab, Rob Herring, Florian Fainelli,
Kevin Hilman, Richard Weinberger, Bartosz Golaszewski, linux-doc,
Russell King, Marek Vasut, Paolo Abeni, Dan Carpenter,
Grygorii Strashko, David Lechner, Arnd Bergmann,
Sven Van Asbroeck, Boris Brezillon, linux-mtd, Linux-OMAP,
arm-soc
In-Reply-To: <CAMpxmJXVNiyqF4qaYtNhPUG3mSZVdvBSGUqDYK-nh59BKeh=Gw@mail.gmail.com>
On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
> 2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>:
> > On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
> >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >>
> >> This is a follow-up to the previously rejected series[1] which partially
> >> removed the at24_platform_data structure. After further development and
> >> taking reviews into account, this series finally removes that struct
> >> completely but not without touching many different parts of the code
> >> base.
> >>
> >> Since I took over maintainership of the at24 driver I've been working
> >> towards removing at24_platform_data in favor for device properties.
> >
> > Wooha, nice work. I can't really comment on it but wondered how you want
> > to upstream it (after reviews)? Pull request of an immutable branch for
> > nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
> > it. Probably same situation for arm-soc...
> >
>
> I initially wanted to merge small parts of it starting with v4.18, but
> there were some voices against merging APIs without users. I'm not
> sure how it should go in. There'll be a need for multiple immutable
> branches most probably...
Hi Bartosz
What this series does is show all the different parts are now
available, and can be reviewed as a whole. Once that review is
completed, merging in parts then becomes possible.
It looks like you could probably merge the nvmem, mtd and net parts
independently via there maintainers for 4.20, since i don't think
there are any dependencies. The arm-soc changes in 4.21, and the
removal of the platform data in 4.22?
Andrew
^ permalink raw reply
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
From: Neftin, Sasha @ 2018-08-08 14:24 UTC (permalink / raw)
To: Camille Bordignon, Alexander Duyck
Cc: Netdev, intel-wired-lan, David S. Miller
In-Reply-To: <20180807064222.GA30741@super_plancton>
On 8/7/2018 09:42, Camille Bordignon wrote:
> Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
>> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
>> <camille.bordignon@easymile.com> wrote:
>>> Hello,
>>>
>>> Recently we experienced some issues with intel NIC (I219-LM and I219-V).
>>> It seems that after a wire reconnection, auto-negotation "fails" and
>>> link speed drips to 10 Mbps.
>>>
>>> From kernel logs:
>>> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
>>> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
>>> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
>>>
>>>
>>> $ethtool enp0s31f6
>>> Settings for enp0s31f6:
>>> Supported ports: [ TP ]
>>> Supported link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Supported pause frame use: No
>>> Supports auto-negotiation: Yes
>>> Supported FEC modes: Not reported
>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Advertised pause frame use: No
>>> Advertised auto-negotiation: Yes
>>> Advertised FEC modes: Not reported
>>> Speed: 10Mb/s
>>> Duplex: Full
>>> Port: Twisted Pair
>>> PHYAD: 1
>>> Transceiver: internal
>>> Auto-negotiation: on
>>> MDI-X: on (auto)
>>> Supports Wake-on: pumbg
>>> Wake-on: g
>>> Current message level: 0x00000007 (7)
>>> drv probe link
>>> Link detected: yes
>>>
>>>
>>> Notice that if disconnection last less than about 5 seconds,
>>> nothing wrong happens.
>>> And if after last failure, disconnection / connection occurs again and
>>> last less than 5 seconds, link speed is back to 1000 Mbps.
>>>
>>> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
>>> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
>>>
>>> The following patch seems to fix this issue.
>>> However I don't clearly understand why.
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> index 3ba0c90e7055..763c013960f1 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
>>> case e1000_media_type_copper:
>>> if (hw->mac.get_link_status) {
>>> ret_val = hw->mac.ops.check_for_link(hw);
>>> - link_active = !hw->mac.get_link_status;
>>> + link_active = false;
>>> } else {
>>> link_active = true;
>>> }
>>>
>>> Maybe this is related to watchdog task.
>>>
>>> I've found out this fix by comparing with last commit that works fine :
>>> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
>>> However I don't know if this information is relevant.
>>>
>>> Thank you.
>>> Camille Bordignon
>>
>> What kernel were you testing this on? I know there have been a number
>> of changes over the past few months in this area and it would be
>> useful to know exactly what code base you started out with and what
>> the latest version of the kernel is you have tested.
>>
>> Looking over the code change the net effect of it should be to add a 2
>> second delay from the time the link has changed until you actually
>> check the speed/duplex configuration. It is possible we could be
>> seeing some sort of timing issue and adding the 2 second delay after
>> the link event is enough time for things to stabilize and detect the
>> link at 1000 instead of 10/100.
>>
>> - Alex
>
> We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
>
> Then I've tested wth a more recent version of the driver v4.18-rc7 but
> behavior looks the same.
>
> Thanks for you reply.
>
> Camille Bordignon
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>
I've agree with Alex. Let's try add 2s delay after a link event. Please,
let us know if it will solve your problem.
Also, I would like recommend try work with different link partner and
see if you see same problem.
^ permalink raw reply
* Re: [PATCH net] vhost: reset metadata cache when initializing new IOTLB
From: David Miller @ 2018-08-08 16:45 UTC (permalink / raw)
To: jasowang; +Cc: mst, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <1533699784-4950-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 8 Aug 2018 11:43:04 +0800
> We need to reset metadata cache during new IOTLB initialization,
> otherwise the stale pointers to previous IOTLB may be still accessed
> which will lead a use after free.
>
> Reported-by: syzbot+c51e6736a1bf614b3272@syzkaller.appspotmail.com
> Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache")
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks Jason.
^ permalink raw reply
* Re: [PATCH 1/1] net-next: hinic: fix a problem in free_tx_poll()
From: David Miller @ 2018-08-08 16:46 UTC (permalink / raw)
To: zhaochen6
Cc: linux-kernel, netdev, tony.qu, yin.yinshi, luoshaokai, fy.wang,
luoxianjun, wangzhou1
In-Reply-To: <20180808063730.12198-1-zhaochen6@huawei.com>
From: Zhao Chen <zhaochen6@huawei.com>
Date: Wed, 8 Aug 2018 06:37:30 +0000
> This patch fixes the problem below. The problem can be reproduced by the
> following steps:
> 1) Connecting all HiNIC interfaces
> 2) On server side
> # sudo ifconfig eth0 192.168.100.1 up #Using MLX CX4 card
> # iperf -s
> 3) On client side
> # sudo ifconfig eth0 192.168.100.2 up #Using our HiNIC card
> # iperf -c 192.168.101.1 -P 10 -t 100000
>
> after hours of testing, we will see errors:
...
> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
Applied, thank you.
^ permalink raw reply
* have editing
From: Julian Jones @ 2018-08-08 12:48 UTC (permalink / raw)
To: netdev
You have needs for image editing for our studio?
Our studio does different image editing for e-commerce photos, jewelry
images, and portrait mages.
It includes cutting out and clipping path and the others, like retouching
etc.
Drop us a photo, testing will be provided.
Thanks,
Julian
^ permalink raw reply
* Re: [PATCH 00/28] at24: remove at24_platform_data
From: Bartosz Golaszewski @ 2018-08-08 16:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bartosz Golaszewski, Wolfram Sang, Jonathan Corbet, Sekhar Nori,
Kevin Hilman, Russell King, Arnd Bergmann, Greg Kroah-Hartman,
David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Grygorii Strashko, David S . Miller,
Srinivas Kandagatla, Naren, Mauro Carvalho Chehab, Andrew Morton
In-Reply-To: <20180808164402.GH7275@lunn.ch>
2018-08-08 18:44 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
> On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
>> 2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>:
>> > On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
>> >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> >>
>> >> This is a follow-up to the previously rejected series[1] which partially
>> >> removed the at24_platform_data structure. After further development and
>> >> taking reviews into account, this series finally removes that struct
>> >> completely but not without touching many different parts of the code
>> >> base.
>> >>
>> >> Since I took over maintainership of the at24 driver I've been working
>> >> towards removing at24_platform_data in favor for device properties.
>> >
>> > Wooha, nice work. I can't really comment on it but wondered how you want
>> > to upstream it (after reviews)? Pull request of an immutable branch for
>> > nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
>> > it. Probably same situation for arm-soc...
>> >
>>
>> I initially wanted to merge small parts of it starting with v4.18, but
>> there were some voices against merging APIs without users. I'm not
>> sure how it should go in. There'll be a need for multiple immutable
>> branches most probably...
>
> Hi Bartosz
>
> What this series does is show all the different parts are now
> available, and can be reviewed as a whole. Once that review is
> completed, merging in parts then becomes possible.
>
> It looks like you could probably merge the nvmem, mtd and net parts
> independently via there maintainers for 4.20, since i don't think
> there are any dependencies. The arm-soc changes in 4.21, and the
> removal of the platform data in 4.22?
>
> Andrew
We need the first batch of SoC changes for the net part and then the
second batch depends on those net changes. Also: dragging the merge
for this over a year is a bit overkill.
Sekhar: I know you're usually provided with immutable branches from
framework maintainers for the SoC changes - is it ok for you to
provide the net maintainers with an immutable branch after applying
the first part of davinci board file changes?
Bart
^ permalink raw reply
* Re: [PATCH v2 0/2] net/sctp: Avoid allocating high order memory with kmalloc()
From: Marcelo Ricardo Leitner @ 2018-08-08 14:48 UTC (permalink / raw)
To: David Laight
Cc: 'Michael Tuexen', Konstantin Khorenko,
oleg.babin@gmail.com, netdev@vger.kernel.org,
linux-sctp@vger.kernel.org, David S . Miller, Vlad Yasevich,
Neil Horman, Xin Long, Andrey Ryabinin
In-Reply-To: <561fae7f72d34f0b983bfbad5d766bdf@AcuMS.aculab.com>
On Mon, Aug 06, 2018 at 09:34:05AM +0000, David Laight wrote:
> From: Michael Tuexen
> > Sent: 03 August 2018 21:57
> ...
> > >> Given how useless SCTP streams are, does anything actually use
> > >> more than about 4?
> > >
> > > Maybe Michael can help us with that. I'm also curious now.
> > In the context of SIGTRAN I have seen 17 streams...
>
> Ok, I've seen 17 there as well, 5 is probably more common.
>
> > In the context of WebRTC I have seen more streams. In general,
> > the streams concept seems to be useful. QUIC has lots of streams.
That means the migration to flex_array should not have a noticeable
impact, as for a small number of streams it will behave just as the
same as it does now. (yes, considering the app won't use high-order
stream id's just because)
...
>
> Thought....
> Could we let the application set large stream-ids, but actually mask them
> down to (say) 32 for the protocol code?
This would require both peers to know about the mapping, as stream ids
must be same on both sides. Seems to be it is better to just adjust
the application and make use of low numbers.
Marcelo
^ permalink raw reply
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
From: Neftin, Sasha @ 2018-08-08 15:00 UTC (permalink / raw)
To: Camille Bordignon, Alexander Duyck
Cc: Netdev, intel-wired-lan, David S. Miller
In-Reply-To: <001556a4-c49c-b96b-0be8-b3c4be7bb09c@intel.com>
On 8/8/2018 17:24, Neftin, Sasha wrote:
> On 8/7/2018 09:42, Camille Bordignon wrote:
>> Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
>>> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
>>> <camille.bordignon@easymile.com> wrote:
>>>> Hello,
>>>>
>>>> Recently we experienced some issues with intel NIC (I219-LM and
>>>> I219-V).
>>>> It seems that after a wire reconnection, auto-negotation "fails" and
>>>> link speed drips to 10 Mbps.
>>>>
>>>> From kernel logs:
>>>> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
>>>> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex,
>>>> Flow Control: None
>>>> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
>>>> disabling TSO
>>>>
>>>>
>>>> $ethtool enp0s31f6
>>>> Settings for enp0s31f6:
>>>> Supported ports: [ TP ]
>>>> Supported link modes: 10baseT/Half 10baseT/Full
>>>> 100baseT/Half 100baseT/Full
>>>> 1000baseT/Full
>>>> Supported pause frame use: No
>>>> Supports auto-negotiation: Yes
>>>> Supported FEC modes: Not reported
>>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>>> 100baseT/Half 100baseT/Full
>>>> 1000baseT/Full
>>>> Advertised pause frame use: No
>>>> Advertised auto-negotiation: Yes
>>>> Advertised FEC modes: Not reported
>>>> Speed: 10Mb/s
>>>> Duplex: Full
>>>> Port: Twisted Pair
>>>> PHYAD: 1
>>>> Transceiver: internal
>>>> Auto-negotiation: on
>>>> MDI-X: on (auto)
>>>> Supports Wake-on: pumbg
>>>> Wake-on: g
>>>> Current message level: 0x00000007 (7)
>>>> drv probe link
>>>> Link detected: yes
>>>>
>>>>
>>>> Notice that if disconnection last less than about 5 seconds,
>>>> nothing wrong happens.
>>>> And if after last failure, disconnection / connection occurs again and
>>>> last less than 5 seconds, link speed is back to 1000 Mbps.
>>>>
>>>> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
>>>> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full
>>>> Duplex, Flow Control: None
>>>>
>>>> The following patch seems to fix this issue.
>>>> However I don't clearly understand why.
>>>>
>>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> index 3ba0c90e7055..763c013960f1 100644
>>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
>>>> e1000_adapter *adapter)
>>>> case e1000_media_type_copper:
>>>> if (hw->mac.get_link_status) {
>>>> ret_val = hw->mac.ops.check_for_link(hw);
>>>> - link_active = !hw->mac.get_link_status;
>>>> + link_active = false;
>>>> } else {
>>>> link_active = true;
>>>> }
>>>>
>>>> Maybe this is related to watchdog task.
>>>>
>>>> I've found out this fix by comparing with last commit that works fine :
>>>> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
>>>> However I don't know if this information is relevant.
>>>>
>>>> Thank you.
>>>> Camille Bordignon
>>>
>>> What kernel were you testing this on? I know there have been a number
>>> of changes over the past few months in this area and it would be
>>> useful to know exactly what code base you started out with and what
>>> the latest version of the kernel is you have tested.
>>>
>>> Looking over the code change the net effect of it should be to add a 2
>>> second delay from the time the link has changed until you actually
>>> check the speed/duplex configuration. It is possible we could be
>>> seeing some sort of timing issue and adding the 2 second delay after
>>> the link event is enough time for things to stabilize and detect the
>>> link at 1000 instead of 10/100.
>>>
>>> - Alex
>>
>> We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
>>
>> Then I've tested wth a more recent version of the driver v4.18-rc7 but
>> behavior looks the same.
>>
>> Thanks for you reply.
>>
>> Camille Bordignon
>> _______________________________________________
>> Intel-wired-lan mailing list
>> Intel-wired-lan@osuosl.org
>> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>>
> I've agree with Alex. Let's try add 2s delay after a link event. Please,
> let us know if it will solve your problem.
> Also, I would like recommend try work with different link partner and
> see if you see same problem.
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Camille,
My apologies, I wrong understand Alex. Please, do not try add delay.
Please, check if you see same problem with different link partners.
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 04/28] nvmem: provide nvmem_device_name()
From: Andy Shevchenko @ 2018-08-08 17:42 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-5-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Kernel users don't have any means of checking the names of nvmem
> devices. Add a routine that returns the name of the nvmem provider.
>
> This will be useful for nvmem notifier subscribers - otherwise they
> can't check what device is being added/removed.
> +const char *nvmem_device_name(struct nvmem_device *nvmem)
> +{
> + return dev_name(&nvmem->dev);
> +}
> +EXPORT_SYMBOL_GPL(nvmem_device_name);
Just wondering if *_dev_name() is more common pattern in the kernel
(at least pci_dev_name() comes immediately to mind).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 07/28] ARM: davinci: dm365-evm: use nvmem lookup for mac address
From: Andy Shevchenko @ 2018-08-08 17:43 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-8-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We now support nvmem lookups for machine code. Add a lookup for
> mac-address.
> #include <linux/spi/spi.h>
> #include <linux/spi/eeprom.h>
> #include <linux/v4l2-dv-timings.h>
> +#include <linux/nvmem-provider.h>
It looks from this context that your patch broke the order.
P.S. Can you verify all in the series for this?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720
From: Marek Behún @ 2018-08-08 15:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Gregory CLEMENT, Tomas Hlavacek, Marek Behún,
Russell King - ARM Linux, netdev
In-Reply-To: <20180808152706.21727-1-marek.behun@nic.cz>
For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
networking driver behaves weirdly when using napi_gro_receive.
For example downloading a big file from a local network (low ping) is
fast, but when downloading from a remote server (higher ping), the
download speed is at first high but drops rapidly to almost nothing or
absolutely nothing.
This is fixed when using netif_receive_skb instead of napi_gro_receive.
Signed-off-by: Marek Behun <marek.behun@nic.cz>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 0ad2f3f7da85..27f3017d94c5 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
skb->protocol = eth_type_trans(skb, dev);
mvneta_rx_csum(pp, rx_status, skb);
- napi_gro_receive(&port->napi, skb);
+ if (pp->neta_armada3700)
+ netif_receive_skb(skb);
+ else
+ napi_gro_receive(&port->napi, skb);
rcvd_pkts++;
rcvd_bytes += rx_bytes;
@@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
mvneta_rx_csum(pp, rx_status, skb);
- napi_gro_receive(&port->napi, skb);
+ if (pp->neta_armada3700)
+ netif_receive_skb(skb);
+ else
+ napi_gro_receive(&port->napi, skb);
}
if (rcvd_pkts) {
--
2.16.4
^ permalink raw reply related
* Re: [PATCH 14/28] net: split eth_platform_get_mac_address() into subroutines
From: Andy Shevchenko @ 2018-08-08 17:50 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-15-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We want do add more sources from which to read the MAC address. In
> order to avoid bloating this function too much, start by splitting it
> into subroutines, each of which takes care of reading the MAC from
> one source.
> +static int mac_address_from_of(struct device *dev, u8 *mac_addr)
> {
> const unsigned char *addr;
> + struct device_node *np;
>
> + np = dev_is_pci(dev) ? pci_device_to_OF_node(to_pci_dev(dev))
> + : dev->of_node;
I didn't get these manipulations.
What the scenario when pci_dev->dev.of_node != dev->of_node?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 10/28] ARM: davinci: da830-evm: use nvmem lookup for mac address
From: Bartosz Golaszewski @ 2018-08-08 15:31 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180808153150.23444-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We now support nvmem lookups for machine code. Add a lookup for
mac-address.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 14a6fc061744..4a2fe8142a2f 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -29,6 +29,7 @@
#include <linux/platform_data/spi-davinci.h>
#include <linux/platform_data/usb-davinci.h>
#include <linux/regulator/machine.h>
+#include <linux/nvmem-provider.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -409,6 +410,15 @@ static inline void da830_evm_init_lcdc(int mux_mode)
static inline void da830_evm_init_lcdc(int mux_mode) { }
#endif
+static struct nvmem_cell_lookup da830_evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ },
+ .nvmem_name = "1-00500",
+};
+
static struct at24_platform_data da830_evm_i2c_eeprom_info = {
.byte_len = SZ_256K / 8,
.page_size = 64,
@@ -618,6 +628,8 @@ static __init void da830_evm_init(void)
pr_warn("%s: spi 0 registration failed: %d\n", __func__, ret);
regulator_has_full_constraints();
+
+ nvmem_add_lookup_table(&da830_evm_mac_address_cell, 1);
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox