netdev - Re: [PATCH] net-sysfs: allow changing sysfs carrier when interface is down

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a7a73ca7dd521d632ac9b55fa17e083493765174.camel@infinera.com>
Date:   Tue, 7 Jun 2022 11:52:48 +0000
From:   Joakim Tjernlund <Joakim.Tjernlund@...inera.com>
To:     "andrew@...n.ch" <andrew@...n.ch>
CC:     "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net-sysfs: allow changing sysfs carrier when interface is
 down

On Sun, 2022-06-05 at 20:50 +0200, Andrew Lunn wrote:
> On Thu, Jun 02, 2022 at 06:01:08PM +0000, Joakim Tjernlund wrote:
> > On Thu, 2022-06-02 at 10:52 -0700, Jakub Kicinski wrote:
> > > On Thu, 2 Jun 2022 17:15:13 +0000 Joakim Tjernlund wrote:
> > > > > What is "our HW", what kernel driver does it use and why can't the
> > > > > kernel driver take care of making sure the device is not accessed
> > > > > when it'd crash the system?  
> > > > 
> > > > It is a custom asic with some homegrown controller. The full config path is too complex for kernel too
> > > > know and depends on user input.
> > > 
> > > We have a long standing tradition of not caring about user space
> > > drivers in netdev land. I see no reason to merge this patch upstream.
> > 
> > This is not a user space driver. View it as a eth controller with a dum PHY
> > which cannot convey link status. The kernel driver then needs help with managing carrier.
> 
> Please post the MAC driver then. We don't really like changes to the
> kernel without a user. You MAC driver would be such a user.

That driver is far from kernel proper/upstream worthy ..

> 
> Could you also tell us more about the PHY. What capabilities does it
> have? I assume it is not C22 compatible. Does it at least have some
> sort of indicator of link? What might make sense is to use the

There is no PHY really, from kernels POV it is just a DMA engine and all
the setup needed to setup the full path is in US.

> fixed-link code. You can provide a callback which gives the actual
> link status up/down. And the fixed-link driver looks like a real PHY,
> so the MAC driver does not need to do anything special.

The fixed PHY has the same problem as it uses the same sysfs I/F. I am just
asking that the sysfs carrier I/F should be writeable and readable when I/F is
DOWN. Now one cannot even read carrier status when I/F is down.

> 
>    Andrew