netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Jiri Slaby <jirislaby@kernel.org>,
	Vadim Fedorenko <vadfed@meta.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Jonathan Lemon <jonathan.lemon@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net v3 1/2] ptp: ocp: adjust sysfs entries to expose tty information
Date: Fri, 16 Aug 2024 19:48:02 +0100	[thread overview]
Message-ID: <7c87e50e-771c-4cf4-bb28-38e13b0542fd@linux.dev> (raw)
In-Reply-To: <ea38ce1d-0b6c-4a49-82f1-4c3d823525b4@kernel.org>

On 16/08/2024 06:26, Jiri Slaby wrote:
> On 15. 08. 24, 14:59, Vadim Fedorenko wrote:
>> Starting v6.8 the serial port subsystem changed the hierarchy of devices
>> and symlinks are not working anymore. Previous discussion made it clear
>> that the idea of symlinks for tty devices was wrong by design.
> 
> Care to link it here?

Sure, with the next version.

> 
>> Implement
>> additional attributes to expose the information. Fixes tag points to the
>> commit which introduced the change.
> ...
>> --- a/drivers/ptp/ptp_ocp.c
>> +++ b/drivers/ptp/ptp_ocp.c
>> @@ -316,6 +316,15 @@ struct ptp_ocp_serial_port {
>>   #define OCP_SERIAL_LEN            6
>>   #define OCP_SMA_NUM            4
>> +enum {
>> +    PORT_GNSS,
>> +    PORT_GNSS2,
>> +    PORT_MAC, /* miniature atomic clock */
>> +    PORT_NMEA,
>> +
>> +    PORT_NUM_MAX
>> +};
>> +
> 
> The conversion to the array needs to go to a separate patch, apparently.

I'm not sure here. I'm trying to fix the regression introduced back in
6.8. The conversion to the array itself doesn't solve the issue, it's
pure net-next material. But the simple fix was NACKed previously, that's
why I had to introduce such a big change. I would like to keep these
changes all together in one patch.

> 
>> +static ssize_t
>> +ptp_ocp_tty_show(struct device *dev, struct device_attribute *attr, 
>> char *buf)
>> +{
>> +    struct dev_ext_attribute *ea = to_ext_attr(attr);
>> +    struct ptp_ocp *bp = dev_get_drvdata(dev);
>> +    struct ptp_ocp_serial_port *port;
>> +
>> +    return sysfs_emit(buf, "ttyS%d", bp->port[(uintptr_t)ea->var].line);
> 
> uintptr_t is unusual as Greg points out. It is a correct type per C99 to 
> cast from/to pointers, but we usually do "unsigned long". (int wouldn't 
> work as it has a different size (on 64bit).)
> 
> But looking at the code, uintptr_t is used all over. So perhaps use that 
> to be consistent?

so, now I'm lost. I'm ok with both options, just let me know which one
will have no objections to be merged...

> 
>> @@ -3960,16 +4017,16 @@ ptp_ocp_summary_show(struct seq_file *s, void 
>> *data)
>>       bp = dev_get_drvdata(dev);
>>       seq_printf(s, "%7s: /dev/ptp%d\n", "PTP", ptp_clock_index(bp- 
>> >ptp));
>> -    if (bp->gnss_port.line != -1)
>> +    if (bp->port[PORT_GNSS].line != -1)
>>           seq_printf(s, "%7s: /dev/ttyS%d\n", "GNSS1",
>> -               bp->gnss_port.line);
>> -    if (bp->gnss2_port.line != -1)
>> +               bp->port[PORT_GNSS].line);
>> +    if (bp->port[PORT_GNSS2].line != -1)
>>           seq_printf(s, "%7s: /dev/ttyS%d\n", "GNSS2",
>> -               bp->gnss2_port.line);
>> -    if (bp->mac_port.line != -1)
>> -        seq_printf(s, "%7s: /dev/ttyS%d\n", "MAC", bp->mac_port.line);
>> -    if (bp->nmea_port.line != -1)
>> -        seq_printf(s, "%7s: /dev/ttyS%d\n", "NMEA", bp->nmea_port.line);
>> +               bp->port[PORT_GNSS2].line);
>> +    if (bp->port[PORT_MAC].line != -1)
>> +        seq_printf(s, "%7s: /dev/ttyS%d\n", "MAC", bp- 
>> >port[PORT_MAC].line);
>> +    if (bp->port[PORT_NMEA].line != -1)
>> +        seq_printf(s, "%7s: /dev/ttyS%d\n", "NMEA", bp- 
>> >port[PORT_NMEA].line);
> 
> Perhaps you can introduce some to_name() function (mapping enum -> const 
> char *)? Can this code be then a three-line for loop?

yeah, I can do it, for sure.

> 
>> @@ -4419,20 +4460,21 @@ ptp_ocp_info(struct ptp_ocp *bp)
>>       ptp_ocp_phc_info(bp);
>> -    ptp_ocp_serial_info(dev, "GNSS", bp->gnss_port.line,
>> -                bp->gnss_port.baud);
>> -    ptp_ocp_serial_info(dev, "GNSS2", bp->gnss2_port.line,
>> -                bp->gnss2_port.baud);
>> -    ptp_ocp_serial_info(dev, "MAC", bp->mac_port.line, bp- 
>> >mac_port.baud);
>> -    if (bp->nmea_out && bp->nmea_port.line != -1) {
>> -        bp->nmea_port.baud = -1;
>> +    ptp_ocp_serial_info(dev, "GNSS", bp->port[PORT_GNSS].line,
>> +                bp->port[PORT_GNSS].baud);
>> +    ptp_ocp_serial_info(dev, "GNSS2", bp->port[PORT_GNSS2].line,
>> +                bp->port[PORT_GNSS2].baud);
>> +    ptp_ocp_serial_info(dev, "MAC", bp->port[PORT_MAC].line,
>> +                bp->port[PORT_MAC].baud);
>> +    if (bp->nmea_out && bp->port[PORT_NMEA].line != -1) {
>> +        bp->port[PORT_NMEA].baud = -1;
>>           reg = ioread32(&bp->nmea_out->uart_baud);
>>           if (reg < ARRAY_SIZE(nmea_baud))
>> -            bp->nmea_port.baud = nmea_baud[reg];
>> +            bp->port[PORT_NMEA].baud = nmea_baud[reg];
>> -        ptp_ocp_serial_info(dev, "NMEA", bp->nmea_port.line,
>> -                    bp->nmea_port.baud);
>> +        ptp_ocp_serial_info(dev, "NMEA", bp->port[PORT_NMEA].line,
>> +                    bp->port[PORT_NMEA].baud);
> 
> Maybe even here with if (iterator == PORT_NMEA)?
> 
Should be ok, will make it in the next revision.

Thanks,
Vadim

  reply	other threads:[~2024-08-16 18:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-15 12:59 [PATCH net v3 1/2] ptp: ocp: adjust sysfs entries to expose tty information Vadim Fedorenko
2024-08-15 12:59 ` [PATCH net v3 2/2] docs: ABI: update OCP TimeCard sysfs entries Vadim Fedorenko
2024-08-15 13:41 ` [PATCH net v3 1/2] ptp: ocp: adjust sysfs entries to expose tty information Greg Kroah-Hartman
2024-08-15 15:06   ` Vadim Fedorenko
2024-08-15 13:54 ` Simon Horman
2024-08-15 14:05   ` Vadim Fedorenko
2024-08-16  5:26 ` Jiri Slaby
2024-08-16 18:48   ` Vadim Fedorenko [this message]
2024-08-16 12:03 ` kernel test robot

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=7c87e50e-771c-4cf4-bb28-38e13b0542fd@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=netdev@vger.kernel.org \
    --cc=vadfed@meta.com \
    /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).