Message-ID: <2024060551-grazing-handling-e9ed@gregkh>
Date: Wed, 5 Jun 2024 14:22:28 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Jakub Kicinski <kuba@...nel.org>, Jiri Slaby <jirislaby@...nel.org>,
	Jonathan Lemon <jonathan.lemon@...il.com>,
	linux-serial@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net] ptp: ocp: adjust serial port symlink creation

On Wed, Jun 05, 2024 at 12:25:26PM +0100, Vadim Fedorenko wrote:
> On 05/06/2024 12:07, Greg Kroah-Hartman wrote:
> > On Wed, Jun 05, 2024 at 11:59:30AM +0100, Vadim Fedorenko wrote:
> > > On 05/06/2024 11:41, Greg Kroah-Hartman wrote:
> > > > On Wed, Jun 05, 2024 at 11:14:28AM +0100, Vadim Fedorenko wrote:
> > > > > On 05/06/2024 11:05, Greg Kroah-Hartman wrote:
> > > > > > On Wed, Jun 05, 2024 at 12:53:13AM +0100, Vadim Fedorenko wrote:
> > > > > > > On 04/06/2024 12:50, Greg Kroah-Hartman wrote:
> > > > > > > > On Wed, May 22, 2024 at 01:39:21PM +0100, Vadim Fedorenko wrote:
> > > > > > > > > On 10/05/2024 12:13, Greg Kroah-Hartman wrote:
> > > > > > > > > > On Fri, May 10, 2024 at 11:04:05AM +0000, Vadim Fedorenko wrote:
> > > > > > > > > > > The commit b286f4e87e32 ("serial: core: Move tty and serdev to be children
> > > > > > > > > > > of serial core port device") changed the hierarchy of serial port devices
> > > > > > > > > > > and device_find_child_by_name cannot find ttyS* devices because they are
> > > > > > > > > > > no longer directly attached. Add some logic to restore symlinks creation
> > > > > > > > > > > to the driver for OCP TimeCard.
> > > > > > > > > > > 
> > > > > > > > > > > Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device")
> > > > > > > > > > > Signed-off-by: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
> > > > > > > > > > > ---
> > > > > > > > > > > v2:
> > > > > > > > > > >       add serial/8250 maintainers
> > > > > > > > > > > ---
> > > > > > > > > > >       drivers/ptp/ptp_ocp.c | 30 +++++++++++++++++++++---------
> > > > > > > > > > >       1 file changed, 21 insertions(+), 9 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> > > > > > > > > > a patch that has triggered this response.  He used to manually respond
> > > > > > > > > > to these common problems, but in order to save his sanity (he kept
> > > > > > > > > > writing the same thing over and over, yet to different people), I was
> > > > > > > > > > created.  Hopefully you will not take offence and will fix the problem
> > > > > > > > > > in your patch and resubmit it so that it can be accepted into the Linux
> > > > > > > > > > kernel tree.
> > > > > > > > > > 
> > > > > > > > > > You are receiving this message because of the following common error(s)
> > > > > > > > > > as indicated below:
> > > > > > > > > > 
> > > > > > > > > > - You have marked a patch with a "Fixes:" tag for a commit that is in an
> > > > > > > > > >        older released kernel, yet you do not have a cc: stable line in the
> > > > > > > > > >        signed-off-by area at all, which means that the patch will not be
> > > > > > > > > >        applied to any older kernel releases.  To properly fix this, please
> > > > > > > > > >        follow the documented rules in the
> > > > > > > > > >        Documentation/process/stable-kernel-rules.rst file for how to resolve
> > > > > > > > > >        this.
> > > > > > > > > > 
> > > > > > > > > > If you wish to discuss this problem further, or you have questions about
> > > > > > > > > > how to resolve this issue, please feel free to respond to this email and
> > > > > > > > > > Greg will reply once he has dug out from the pending patches received
> > > > > > > > > > from other developers.
> > > > > > > > > 
> > > > > > > > > Hi Greg!
> > > > > > > > > 
> > > > > > > > > Just gentle ping, I'm still looking for better solution for serial
> > > > > > > > > device lookup in TimeCard driver.
> > > > > > > > 
> > > > > > > > See my comment on the other patch in this thread.
> > > > > > > > 
> > > > > > > > In short, you shouldn't need to do any of this.
> > > > > > > 
> > > > > > > Got it, thanks. I'll try to find another way.
> > > > > > 
> > > > > > Wait, no, please just remove all that, it should not be needed at all.
> > > > > 
> > > > > Do you mean remove symlinks from the driver? We have open-source
> > > > > user-space software which relies on them to discover proper devices. If
> > > > > I remove symlinks it will break the software.
> > > > 
> > > > the symlinks should be done in userspace in the /dev/serial/ directory,
> > > > why would userspace need to know the symlink of the serial device in
> > > > a sysfs tree?  What exactly are you trying to represent here that
> > > > requires this to be a custom thing?
> > > 
> > > Well, the hardware exposes up to 4 different serial ports for different
> > > functions. And only driver knows which feature is attached to which port
> > > because of differences in the HW. There is no way for user-space to get
> > > this information on it's own.
> > 
> > The serial ports have a specific parent, why aren't those parents
> > described differently in userspace?  Why not tell userspace those
> > functions?
> 
> There is only 1 parent for the serial ports - the pci device driven by
> ptp_ocp. The physical devices behind these serial ports are not able to
> do proper pci function.

Then make those "physical devices" on the aux bus, splitting the PCI
device "apart".  That's what the aux bus is for.

> > > And one more thing, some HW versions
> > > expose special attributes in sysfs consumed by the same software.
> > > And there are setups with several boards in the system. Currently we
> > > separate them by providing different sysfs entries only, the software
> > > then figures all details automatically.
> > 
> > Again, export that info to userspace and have it choose, don't create
> > random symlinks in sysfs for your specific policy, that is not what
> > sysfs is for at all.
> 
> Yes, that's what I'm thinking about now - export serial ports as another
> attributes of the device.

Or use the aux bus :)

thanks,

greg k-h

Powered by blists - more mailing lists