On Thu, 2022-06-02 at 08:56 -0700, Stephen Hemminger wrote: > On Thu, 2 Jun 2022 09:22:34 +0000 > Joakim Tjernlund <Joakim.Tjernlund@xxxxxxxxxxxx> wrote: > > > On Wed, 2022-06-01 at 18:01 -0700, Jakub Kicinski wrote: > > > On Thu, 2 Jun 2022 02:35:23 +0200 Joakim Tjernlund wrote: > > > > UP/DOWN and carrier are async events and it makes sense one can > > > > adjust carrier in sysfs before bringing the interface up. > > > > > > Can you explain your use case? > > > > Sure, our HW has config/state changes that makes it impossible for net driver > > to touch and registers or TX pkgs(can result in System Error exception in worst case. > > > > So the user space app handlings this needs to make sure that even if say dchp > > brings an I/F up, there can be no HW access by the driver. > > To do that, carrier needs to be controlled before I/F is brought up. > > > > Carrier reflects actual link status and this kan change at any time. I honestly > > don't understand why you would prevent sysfs access to carrier just > > because I/F is down? > > > > > > > > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@xxxxxxxxxxxx> > > > > Cc: stable@xxxxxxxxxxxxxxx > > > > > > Seems a little too risky of a change to push into stable. > > > > The change is minimal and only allows access to carrier when I/F is also down. > > I think this is a kernel bug and should go to stable too. > > > > For many devices when device is down, the phy is turned off so the > state of carrier is either always down or undefined. > > That is why the code had the check originally. > Maybe so but it seems to me that this limitation was put in place without much thought. Here an app takes on the role to manage carrier for that device and the app should be free to manage the carrier as it see best. Are there some use cases that must deny sysfs carrier access to its own carrier? Jocke
