From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
Jiri Slaby <jirislaby@kernel.org>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
linux-serial@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 net] ptp: ocp: adjust serial port symlink creation
Date: Wed, 5 Jun 2024 12:25:26 +0100 [thread overview]
Message-ID: <f226b16c-e603-409b-a9a7-f1a201da10a0@linux.dev> (raw)
In-Reply-To: <2024060503-subsonic-pupil-bbee@gregkh>
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
next prev parent reply other threads:[~2024-06-05 11:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 11:04 [PATCH v2 net] ptp: ocp: adjust serial port symlink creation Vadim Fedorenko
2024-05-10 11:13 ` Greg Kroah-Hartman
2024-05-22 12:39 ` Vadim Fedorenko
2024-06-04 11:50 ` Greg Kroah-Hartman
2024-06-04 23:53 ` Vadim Fedorenko
2024-06-05 10:05 ` Greg Kroah-Hartman
2024-06-05 10:14 ` Vadim Fedorenko
2024-06-05 10:41 ` Greg Kroah-Hartman
2024-06-05 10:59 ` Vadim Fedorenko
2024-06-05 11:07 ` Greg Kroah-Hartman
2024-06-05 11:25 ` Vadim Fedorenko [this message]
2024-06-05 12:22 ` Greg Kroah-Hartman
2024-05-23 15:39 ` Jakub Kicinski
2024-05-23 16:26 ` Greg Kroah-Hartman
2024-05-23 21:06 ` Vadim Fedorenko
2024-05-24 4:06 ` Greg Kroah-Hartman
2024-06-08 10:10 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f226b16c-e603-409b-a9a7-f1a201da10a0@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).