diff mbox series

[v2,net] ptp: ocp: adjust serial port symlink creation

Message ID 20240510110405.15115-1-vadim.fedorenko@linux.dev (mailing list archive)
State Not Applicable
Delegated to: Netdev Maintainers
Headers show
Series [v2,net] ptp: ocp: adjust serial port symlink creation | expand

Checks

Context Check Description
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for net
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag present in non-next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 925 this patch: 925
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers fail 1 blamed authors not CCed: tony@atomide.com; 3 maintainers not CCed: tony@atomide.com vadfed@linux.dev richardcochran@gmail.com
netdev/build_clang success Errors and warnings before: 936 this patch: 936
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success Fixes tag looks correct
netdev/build_allmodconfig_warn success Errors and warnings before: 936 this patch: 936
netdev/checkpatch warning WARNING: line length of 94 exceeds 80 columns
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
netdev/contest success net-next-2024-05-14--00-00 (tests: 1022)

Commit Message

Vadim Fedorenko May 10, 2024, 11:04 a.m. UTC
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@linux.dev>
---
v2:
 add serial/8250 maintainers
---
 drivers/ptp/ptp_ocp.c | 30 +++++++++++++++++++++---------
 1 file changed, 21 insertions(+), 9 deletions(-)

Comments

Greg Kroah-Hartman May 10, 2024, 11:13 a.m. UTC | #1
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@linux.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.

thanks,

greg k-h's patch email bot
Vadim Fedorenko May 22, 2024, 12:39 p.m. UTC | #2
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@linux.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.

Thanks,
Vadim
Jakub Kicinski May 23, 2024, 3:39 p.m. UTC | #3
On Fri, 10 May 2024 11:04:05 +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@linux.dev>
> ---
> v2:
>  add serial/8250 maintainers
> ---
>  drivers/ptp/ptp_ocp.c | 30 +++++++++++++++++++++---------
>  1 file changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
> index ee2ced88ab34..50b7cb9db3be 100644
> --- a/drivers/ptp/ptp_ocp.c
> +++ b/drivers/ptp/ptp_ocp.c
> @@ -25,6 +25,8 @@
>  #include <linux/crc16.h>
>  #include <linux/dpll.h>
>  
> +#include "../tty/serial/8250/8250.h"

Hi Greg, Jiri, does this look reasonable to you?
The cross tree include raises an obvious red flag.

Should serial / u8250 provide a more official API?
Can we use device_for_each_child() to deal with the extra
layer in the hierarchy?

>  #define PCI_VENDOR_ID_FACEBOOK			0x1d9b
>  #define PCI_DEVICE_ID_FACEBOOK_TIMECARD		0x0400
>  
> @@ -4330,11 +4332,9 @@ ptp_ocp_symlink(struct ptp_ocp *bp, struct device *child, const char *link)
>  }
>  
>  static void
> -ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
> +ptp_ocp_link_child(struct ptp_ocp *bp, struct device *dev, const char *name, const char *link)
>  {
> -	struct device *dev, *child;
> -
> -	dev = &bp->pdev->dev;
> +	struct device *child;
>  
>  	child = device_find_child_by_name(dev, name);
>  	if (!child) {
> @@ -4349,27 +4349,39 @@ ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
>  static int
>  ptp_ocp_complete(struct ptp_ocp *bp)
>  {
> +	struct device *dev, *port_dev;
> +	struct uart_8250_port *port;
>  	struct pps_device *pps;
>  	char buf[32];
>  
> +	dev = &bp->pdev->dev;
> +
>  	if (bp->gnss_port.line != -1) {
> +		port = serial8250_get_port(bp->gnss_port.line);
> +		port_dev = (struct device *)port->port.port_dev;
>  		sprintf(buf, "ttyS%d", bp->gnss_port.line);
> -		ptp_ocp_link_child(bp, buf, "ttyGNSS");
> +		ptp_ocp_link_child(bp, port_dev, buf, "ttyGNSS");
>  	}
>  	if (bp->gnss2_port.line != -1) {
> +		port = serial8250_get_port(bp->gnss2_port.line);
> +		port_dev = (struct device *)port->port.port_dev;
>  		sprintf(buf, "ttyS%d", bp->gnss2_port.line);
> -		ptp_ocp_link_child(bp, buf, "ttyGNSS2");
> +		ptp_ocp_link_child(bp, port_dev, buf, "ttyGNSS2");
>  	}
>  	if (bp->mac_port.line != -1) {
> +		port = serial8250_get_port(bp->mac_port.line);
> +		port_dev = (struct device *)port->port.port_dev;
>  		sprintf(buf, "ttyS%d", bp->mac_port.line);
> -		ptp_ocp_link_child(bp, buf, "ttyMAC");
> +		ptp_ocp_link_child(bp, port_dev, buf, "ttyMAC");
>  	}
>  	if (bp->nmea_port.line != -1) {
> +		port = serial8250_get_port(bp->nmea_port.line);
> +		port_dev = (struct device *)port->port.port_dev;
>  		sprintf(buf, "ttyS%d", bp->nmea_port.line);
> -		ptp_ocp_link_child(bp, buf, "ttyNMEA");
> +		ptp_ocp_link_child(bp, port_dev, buf, "ttyNMEA");
>  	}
>  	sprintf(buf, "ptp%d", ptp_clock_index(bp->ptp));
> -	ptp_ocp_link_child(bp, buf, "ptp");
> +	ptp_ocp_link_child(bp, dev, buf, "ptp");
>  
>  	pps = pps_lookup_dev(bp->ptp);
>  	if (pps)
Greg Kroah-Hartman May 23, 2024, 4:26 p.m. UTC | #4
On Thu, May 23, 2024 at 08:39:43AM -0700, Jakub Kicinski wrote:
> On Fri, 10 May 2024 11:04:05 +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@linux.dev>
> > ---
> > v2:
> >  add serial/8250 maintainers
> > ---
> >  drivers/ptp/ptp_ocp.c | 30 +++++++++++++++++++++---------
> >  1 file changed, 21 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
> > index ee2ced88ab34..50b7cb9db3be 100644
> > --- a/drivers/ptp/ptp_ocp.c
> > +++ b/drivers/ptp/ptp_ocp.c
> > @@ -25,6 +25,8 @@
> >  #include <linux/crc16.h>
> >  #include <linux/dpll.h>
> >  
> > +#include "../tty/serial/8250/8250.h"
> 
> Hi Greg, Jiri, does this look reasonable to you?
> The cross tree include raises an obvious red flag.

Yeah, that looks wrong.

> Should serial / u8250 provide a more official API?

If it needs to, but why is this driver poking around in here at all?

> Can we use device_for_each_child() to deal with the extra
> layer in the hierarchy?

Or a real function where needed?

> 
> >  #define PCI_VENDOR_ID_FACEBOOK			0x1d9b
> >  #define PCI_DEVICE_ID_FACEBOOK_TIMECARD		0x0400
> >  
> > @@ -4330,11 +4332,9 @@ ptp_ocp_symlink(struct ptp_ocp *bp, struct device *child, const char *link)
> >  }
> >  
> >  static void
> > -ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
> > +ptp_ocp_link_child(struct ptp_ocp *bp, struct device *dev, const char *name, const char *link)
> >  {
> > -	struct device *dev, *child;
> > -
> > -	dev = &bp->pdev->dev;
> > +	struct device *child;
> >  
> >  	child = device_find_child_by_name(dev, name);
> >  	if (!child) {
> > @@ -4349,27 +4349,39 @@ ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
> >  static int
> >  ptp_ocp_complete(struct ptp_ocp *bp)
> >  {
> > +	struct device *dev, *port_dev;
> > +	struct uart_8250_port *port;
> >  	struct pps_device *pps;
> >  	char buf[32];
> >  
> > +	dev = &bp->pdev->dev;
> > +
> >  	if (bp->gnss_port.line != -1) {
> > +		port = serial8250_get_port(bp->gnss_port.line);
> > +		port_dev = (struct device *)port->port.port_dev;

That cast is not going to go well.  How do you know this is always
true?

What was the original code attempting to do?  It feels like that was
wrong to start with if merely moving things around the device tree
caused anything to break here.  That is not how the driver core is
supposed to be used at all.

thanks,

greg k-h
Vadim Fedorenko May 23, 2024, 9:06 p.m. UTC | #5
On 23/05/2024 17:26, Greg Kroah-Hartman wrote:
> On Thu, May 23, 2024 at 08:39:43AM -0700, Jakub Kicinski wrote:
>> On Fri, 10 May 2024 11:04:05 +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@linux.dev>
>>> ---
>>> v2:
>>>   add serial/8250 maintainers
>>> ---
>>>   drivers/ptp/ptp_ocp.c | 30 +++++++++++++++++++++---------
>>>   1 file changed, 21 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
>>> index ee2ced88ab34..50b7cb9db3be 100644
>>> --- a/drivers/ptp/ptp_ocp.c
>>> +++ b/drivers/ptp/ptp_ocp.c
>>> @@ -25,6 +25,8 @@
>>>   #include <linux/crc16.h>
>>>   #include <linux/dpll.h>
>>>   
>>> +#include "../tty/serial/8250/8250.h"
>>
>> Hi Greg, Jiri, does this look reasonable to you?
>> The cross tree include raises an obvious red flag.
> 
> Yeah, that looks wrong.
> 
>> Should serial / u8250 provide a more official API?
> 
> If it needs to, but why is this driver poking around in here at all?

Hi Greg!

Well, the original idea was to have symlinks with self-explanatory names
to real serial devices exposed by PCIe device.

> 
>> Can we use device_for_each_child() to deal with the extra
>> layer in the hierarchy?
> 
> Or a real function where needed?

yep.

> 
>>
>>>   #define PCI_VENDOR_ID_FACEBOOK			0x1d9b
>>>   #define PCI_DEVICE_ID_FACEBOOK_TIMECARD		0x0400
>>>   
>>> @@ -4330,11 +4332,9 @@ ptp_ocp_symlink(struct ptp_ocp *bp, struct device *child, const char *link)
>>>   }
>>>   
>>>   static void
>>> -ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
>>> +ptp_ocp_link_child(struct ptp_ocp *bp, struct device *dev, const char *name, const char *link)
>>>   {
>>> -	struct device *dev, *child;
>>> -
>>> -	dev = &bp->pdev->dev;
>>> +	struct device *child;
>>>   
>>>   	child = device_find_child_by_name(dev, name);
>>>   	if (!child) {
>>> @@ -4349,27 +4349,39 @@ ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
>>>   static int
>>>   ptp_ocp_complete(struct ptp_ocp *bp)
>>>   {
>>> +	struct device *dev, *port_dev;
>>> +	struct uart_8250_port *port;
>>>   	struct pps_device *pps;
>>>   	char buf[32];
>>>   
>>> +	dev = &bp->pdev->dev;
>>> +
>>>   	if (bp->gnss_port.line != -1) {
>>> +		port = serial8250_get_port(bp->gnss_port.line);
>>> +		port_dev = (struct device *)port->port.port_dev;
> 
> That cast is not going to go well.  How do you know this is always
> true?

AFAIU, port_dev starts with struct dev always. That's why it's safe.

> 
> What was the original code attempting to do?  It feels like that was
> wrong to start with if merely moving things around the device tree
> caused anything to break here.  That is not how the driver core is
> supposed to be used at all.
>

We just want to have a symlink with meaningful name to real tty device,
exposed by PCIe device. We provide up to 4 serial ports - GNSS, GNSS2,
MAC and NMEA, to user space and we don't want user space to guess which
one is which. We do have user space application which relies on symlinks
to discover features.

We don't use device tree because it's PCIe device with pre-defined
functions, so I don't see any other way to get this info and properly
create symlinks.

Thanks,
Vadim


> thanks,
> 
> greg k-h
Greg Kroah-Hartman May 24, 2024, 4:06 a.m. UTC | #6
On Thu, May 23, 2024 at 10:06:05PM +0100, Vadim Fedorenko wrote:
> On 23/05/2024 17:26, Greg Kroah-Hartman wrote:
> > On Thu, May 23, 2024 at 08:39:43AM -0700, Jakub Kicinski wrote:
> > > On Fri, 10 May 2024 11:04:05 +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@linux.dev>
> > > > ---
> > > > v2:
> > > >   add serial/8250 maintainers
> > > > ---
> > > >   drivers/ptp/ptp_ocp.c | 30 +++++++++++++++++++++---------
> > > >   1 file changed, 21 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
> > > > index ee2ced88ab34..50b7cb9db3be 100644
> > > > --- a/drivers/ptp/ptp_ocp.c
> > > > +++ b/drivers/ptp/ptp_ocp.c
> > > > @@ -25,6 +25,8 @@
> > > >   #include <linux/crc16.h>
> > > >   #include <linux/dpll.h>
> > > > +#include "../tty/serial/8250/8250.h"
> > > 
> > > Hi Greg, Jiri, does this look reasonable to you?
> > > The cross tree include raises an obvious red flag.
> > 
> > Yeah, that looks wrong.
> > 
> > > Should serial / u8250 provide a more official API?
> > 
> > If it needs to, but why is this driver poking around in here at all?
> 
> Hi Greg!
> 
> Well, the original idea was to have symlinks with self-explanatory names
> to real serial devices exposed by PCIe device.

Why is that needed?  What is wrong with the normal device topology in
/sys/devices/ that shows this already?

> > > Can we use device_for_each_child() to deal with the extra
> > > layer in the hierarchy?
> > 
> > Or a real function where needed?
> 
> yep.
> 
> > 
> > > 
> > > >   #define PCI_VENDOR_ID_FACEBOOK			0x1d9b
> > > >   #define PCI_DEVICE_ID_FACEBOOK_TIMECARD		0x0400
> > > > @@ -4330,11 +4332,9 @@ ptp_ocp_symlink(struct ptp_ocp *bp, struct device *child, const char *link)
> > > >   }
> > > >   static void
> > > > -ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
> > > > +ptp_ocp_link_child(struct ptp_ocp *bp, struct device *dev, const char *name, const char *link)
> > > >   {
> > > > -	struct device *dev, *child;
> > > > -
> > > > -	dev = &bp->pdev->dev;
> > > > +	struct device *child;
> > > >   	child = device_find_child_by_name(dev, name);
> > > >   	if (!child) {
> > > > @@ -4349,27 +4349,39 @@ ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
> > > >   static int
> > > >   ptp_ocp_complete(struct ptp_ocp *bp)
> > > >   {
> > > > +	struct device *dev, *port_dev;
> > > > +	struct uart_8250_port *port;
> > > >   	struct pps_device *pps;
> > > >   	char buf[32];
> > > > +	dev = &bp->pdev->dev;
> > > > +
> > > >   	if (bp->gnss_port.line != -1) {
> > > > +		port = serial8250_get_port(bp->gnss_port.line);
> > > > +		port_dev = (struct device *)port->port.port_dev;
> > 
> > That cast is not going to go well.  How do you know this is always
> > true?
> 
> AFAIU, port_dev starts with struct dev always. That's why it's safe.
> 
> > 
> > What was the original code attempting to do?  It feels like that was
> > wrong to start with if merely moving things around the device tree
> > caused anything to break here.  That is not how the driver core is
> > supposed to be used at all.
> > 
> 
> We just want to have a symlink with meaningful name to real tty device,
> exposed by PCIe device. We provide up to 4 serial ports - GNSS, GNSS2,
> MAC and NMEA, to user space and we don't want user space to guess which
> one is which. We do have user space application which relies on symlinks
> to discover features.

Just use the normal serial topology please.

And for your named devices, use the symlinks in /dev/serial/ that are
provided for you already.

> We don't use device tree because it's PCIe device with pre-defined
> functions, so I don't see any other way to get this info and properly
> create symlinks.

Sorry, I didn't mean "dt", I mean /sys/devices/, there should not be
anything "special" about this driver that requires custom symlinks in
sysfs.  That's for userspace to create in /dev/serial/ as it does today.
Please just remove all of this, as it's not a good idea at all.

thanks,

greg k-h
Greg Kroah-Hartman June 4, 2024, 11:50 a.m. UTC | #7
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@linux.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.

thanks,

greg k-h
Vadim Fedorenko June 4, 2024, 11:53 p.m. UTC | #8
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@linux.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.


> thanks,
> 
> greg k-h
Greg Kroah-Hartman June 5, 2024, 10:05 a.m. UTC | #9
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@linux.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.
Vadim Fedorenko June 5, 2024, 10:14 a.m. UTC | #10
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@linux.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.
Greg Kroah-Hartman June 5, 2024, 10:41 a.m. UTC | #11
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@linux.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?

thanks,

greg k-h
Vadim Fedorenko June 5, 2024, 10:59 a.m. UTC | #12
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@linux.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. 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.

Thanks,
Vadim
Greg Kroah-Hartman June 5, 2024, 11:07 a.m. UTC | #13
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@linux.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?

> 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.

thanks,

greg k-h
Vadim Fedorenko June 5, 2024, 11:25 a.m. UTC | #14
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@linux.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.

>> 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.

Thanks,
Vadim
Greg Kroah-Hartman June 5, 2024, 12:22 p.m. UTC | #15
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@linux.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
Andy Shevchenko June 8, 2024, 10:10 a.m. UTC | #16
Fri, May 10, 2024 at 11:04:05AM +0000, Vadim Fedorenko kirjoitti:
> 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.

I know that I'm a bit late to the party, but this patch looks like an ugly
hack. The PTP OCP code, in my opinion, needs a lot of love besides the UART
part.
diff mbox series

Patch

diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
index ee2ced88ab34..50b7cb9db3be 100644
--- a/drivers/ptp/ptp_ocp.c
+++ b/drivers/ptp/ptp_ocp.c
@@ -25,6 +25,8 @@ 
 #include <linux/crc16.h>
 #include <linux/dpll.h>
 
+#include "../tty/serial/8250/8250.h"
+
 #define PCI_VENDOR_ID_FACEBOOK			0x1d9b
 #define PCI_DEVICE_ID_FACEBOOK_TIMECARD		0x0400
 
@@ -4330,11 +4332,9 @@  ptp_ocp_symlink(struct ptp_ocp *bp, struct device *child, const char *link)
 }
 
 static void
-ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
+ptp_ocp_link_child(struct ptp_ocp *bp, struct device *dev, const char *name, const char *link)
 {
-	struct device *dev, *child;
-
-	dev = &bp->pdev->dev;
+	struct device *child;
 
 	child = device_find_child_by_name(dev, name);
 	if (!child) {
@@ -4349,27 +4349,39 @@  ptp_ocp_link_child(struct ptp_ocp *bp, const char *name, const char *link)
 static int
 ptp_ocp_complete(struct ptp_ocp *bp)
 {
+	struct device *dev, *port_dev;
+	struct uart_8250_port *port;
 	struct pps_device *pps;
 	char buf[32];
 
+	dev = &bp->pdev->dev;
+
 	if (bp->gnss_port.line != -1) {
+		port = serial8250_get_port(bp->gnss_port.line);
+		port_dev = (struct device *)port->port.port_dev;
 		sprintf(buf, "ttyS%d", bp->gnss_port.line);
-		ptp_ocp_link_child(bp, buf, "ttyGNSS");
+		ptp_ocp_link_child(bp, port_dev, buf, "ttyGNSS");
 	}
 	if (bp->gnss2_port.line != -1) {
+		port = serial8250_get_port(bp->gnss2_port.line);
+		port_dev = (struct device *)port->port.port_dev;
 		sprintf(buf, "ttyS%d", bp->gnss2_port.line);
-		ptp_ocp_link_child(bp, buf, "ttyGNSS2");
+		ptp_ocp_link_child(bp, port_dev, buf, "ttyGNSS2");
 	}
 	if (bp->mac_port.line != -1) {
+		port = serial8250_get_port(bp->mac_port.line);
+		port_dev = (struct device *)port->port.port_dev;
 		sprintf(buf, "ttyS%d", bp->mac_port.line);
-		ptp_ocp_link_child(bp, buf, "ttyMAC");
+		ptp_ocp_link_child(bp, port_dev, buf, "ttyMAC");
 	}
 	if (bp->nmea_port.line != -1) {
+		port = serial8250_get_port(bp->nmea_port.line);
+		port_dev = (struct device *)port->port.port_dev;
 		sprintf(buf, "ttyS%d", bp->nmea_port.line);
-		ptp_ocp_link_child(bp, buf, "ttyNMEA");
+		ptp_ocp_link_child(bp, port_dev, buf, "ttyNMEA");
 	}
 	sprintf(buf, "ptp%d", ptp_clock_index(bp->ptp));
-	ptp_ocp_link_child(bp, buf, "ptp");
+	ptp_ocp_link_child(bp, dev, buf, "ptp");
 
 	pps = pps_lookup_dev(bp->ptp);
 	if (pps)