Date: Wed, 5 Jun 2024 12:25:26 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 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.

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

Powered by blists - more mailing lists