by Simon Horman

[permalink] [raw]

Subject: Re: [PATCH v8 1/3] serdev: Add method to assert break signal over tty UART port

On Mon, Mar 13, 2023 at 04:19:59AM +0000, Neeraj sanjay kale wrote:
> Hi Simon
>
> > > >
> > > > On Fri, Mar 10, 2023 at 11:49:19PM +0530, Neeraj Sanjay Kale wrote:
> > > > > Adds serdev_device_break_ctl() and an implementation for ttyport.
> > > > > This function simply calls the break_ctl in tty layer, which can
> > > > > assert a break signal over UART-TX line, if the tty and the
> > > > > underlying platform and UART peripheral supports this operation.
> > > > >
> > > > > Signed-off-by: Neeraj Sanjay Kale <[email protected]>
> > > > > ---
> > > > > v3: Add details to the commit message. (Greg KH)
> > > >
> > > > ...
> > > >
> > > > > diff --git a/include/linux/serdev.h b/include/linux/serdev.h index
> > > > > 66f624fc618c..c065ef1c82f1 100644
> > > > > --- a/include/linux/serdev.h
> > > > > +++ b/include/linux/serdev.h
> > > >
> > > > ...
> > > >
> > > > > @@ -255,6 +257,10 @@ static inline int
> > > > > serdev_device_set_tiocm(struct serdev_device *serdev, int set, {
> > > > > return -ENOTSUPP;
> > > > > }
> > > > > +static inline int serdev_device_break_ctl(struct serdev_device
> > > > > +*serdev, int break_state) {
> > > > > + return -EOPNOTSUPP;
> > > >
> > > > Is the use of -EOPNOTSUPP intentional here?
> > > > I see -ENOTSUPP is used elsewhere in this file.
> > > I was suggested to use - EOPNOTSUPP instead of - ENOTSUPP by the check
> > patch scripts and by Leon Romanovsky.
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.kernel.org%2Fproject%2Fbluetooth%2Fpatch%2F20230130180504.202
> > 944
> > > 0-2-
> > neeraj.sanjaykale%40nxp.com%2F&data=05%7C01%7Cneeraj.sanjaykale%40
> > >
> > nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f1%7C686ea1d3bc2b4c6fa92
> > cd99c5
> > >
> > c301635%7C0%7C0%7C638142451647332825%7CUnknown%7CTWFpbGZsb3
> > d8eyJWIjoiM
> > >
> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> > %7C%7C
> > > %7C&sdata=6cF0gipe4kkwYI6txo0vs8vnmF8azCO6gxQ%2F6Tdyd%2Fw%3D
> > &reserved=
> > > 0
> > >
> > > ENOTSUPP is not a standard error code and should be avoided in new
> > patches.
> > > See:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > > .kernel.org%2Fnetdev%2F20200510182252.GA411829%40lunn.ch%2F&data
> > =05%7C
> > >
> > 01%7Cneeraj.sanjaykale%40nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f
> > 1%7C
> > >
> > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638142451647332825%
> > 7CUnknow
> > >
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > WwiLC
> > >
> > JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wFgYY6VnZ8BBn6Wme8%2BYj
> > aJRy98qyPnUy
> > > XC8iCFCv5k%3D&reserved=0
> >
> > Thanks.
> >
> > I agree that EOPNOTSUPP is preferable.
> > But my question is if we chose to use it in this case, even if it is inconsistent
> > with similar code in the same file/API.
> > If so, then I have no objections.
>
> No, it was just to satisfy the check patch error and Leon's comment. The driver is happy to check if the serdev returned success or not, and simply print the error code during driver debug.
> Do you think this should be reverted to ENOTSUPP to maintain consistency?

My _opinion_, is that first prize would be converting existing instances
of ENOTSUPP in this file to EOPNOTSUPP. And then use EOPNOTSUPP going
forward. And that second prize would be for your patch to use ENOTSUPP.
Because I think there is a value consistency.

But I do see why you have done things the way you have.
And I don't necessarily think it is wrong.

2023-03-13 14:15:16

by Neeraj Sanjay Kale

[permalink] [raw]

Subject: Re: [PATCH v8 1/3] serdev: Add method to assert break signal over tty UART port

Hi Simon,

> > > > > > diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> > > > > > index
> > > > > > 66f624fc618c..c065ef1c82f1 100644
> > > > > > --- a/include/linux/serdev.h
> > > > > > +++ b/include/linux/serdev.h
> > > > >
> > > > > ...
> > > > >
> > > > > > @@ -255,6 +257,10 @@ static inline int
> > > > > > serdev_device_set_tiocm(struct serdev_device *serdev, int set, {
> > > > > > return -ENOTSUPP;
> > > > > > }
> > > > > > +static inline int serdev_device_break_ctl(struct
> > > > > > +serdev_device *serdev, int break_state) {
> > > > > > + return -EOPNOTSUPP;
> > > > >
> > > > > Is the use of -EOPNOTSUPP intentional here?
> > > > > I see -ENOTSUPP is used elsewhere in this file.
> > > > I was suggested to use - EOPNOTSUPP instead of - ENOTSUPP by the
> > > > check
> > > patch scripts and by Leon Romanovsky.
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > >
> patc%2F&data=05%7C01%7Cneeraj.sanjaykale%40nxp.com%7Cd6011072c88
> 94
> > > >
> b141a3008db23bb5bc0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C6
> > > >
> 38143059832335354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQ
> > > >
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> =k
> > > >
> gk6w%2Fn2d3rNx%2FXe1rLfN0U%2BeTBJTxztSRUEUW2Noqk%3D&reserved=
> 0
> > > >
> > >
> hwork.kernel.org%2Fproject%2Fbluetooth%2Fpatch%2F20230130180504.202
> > > 944
> > > > 0-2-
> > >
> neeraj.sanjaykale%40nxp.com%2F&data=05%7C01%7Cneeraj.sanjaykale%40
> > > >
> > >
> nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f1%7C686ea1d3bc2b4c6fa92
> > > cd99c5
> > > >
> > >
> c301635%7C0%7C0%7C638142451647332825%7CUnknown%7CTWFpbGZsb3
> > > d8eyJWIjoiM
> > > >
> > >
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> > > %7C%7C
> > > > %7C&sdata=6cF0gipe4kkwYI6txo0vs8vnmF8azCO6gxQ%2F6Tdyd%2Fw%
> 3D
> > > &reserved=
> > > > 0
> > > >
> > > > ENOTSUPP is not a standard error code and should be avoided in new
> > > patches.
> > > > See:
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > >
> lore%2F&data=05%7C01%7Cneeraj.sanjaykale%40nxp.com%7Cd6011072c88
> 94
> > > >
> b141a3008db23bb5bc0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C6
> > > >
> 38143059832335354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQ
> > > >
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> =9
> > > >
> wojVR7aEgzoeajvy%2FMAkSqAYGBkxrJZtyxlvIpeZ%2Bw%3D&reserved=0
> > > > .kernel.org%2Fnetdev%2F20200510182252.GA411829%40lunn.ch%2F&
> data
> > > =05%7C
> > > >
> > >
> 01%7Cneeraj.sanjaykale%40nxp.com%7Cf2ae2c9ad3c243df2c1a08db232dc0f
> > > 1%7C
> > > >
> > >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638142451647332825%
> > > 7CUnknow
> > > >
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > WwiLC
> > > >
> > >
> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wFgYY6VnZ8BBn6Wme8%2BYj
> > > aJRy98qyPnUy
> > > > XC8iCFCv5k%3D&reserved=0
> > >
> > > Thanks.
> > >
> > > I agree that EOPNOTSUPP is preferable.
> > > But my question is if we chose to use it in this case, even if it is
> > > inconsistent with similar code in the same file/API.
> > > If so, then I have no objections.
> >
> > No, it was just to satisfy the check patch error and Leon's comment. The
> driver is happy to check if the serdev returned success or not, and simply
> print the error code during driver debug.
> > Do you think this should be reverted to ENOTSUPP to maintain consistency?
>
> My _opinion_, is that first prize would be converting existing instances of
> ENOTSUPP in this file to EOPNOTSUPP. And then use EOPNOTSUPP going
> forward. And that second prize would be for your patch to use ENOTSUPP.
> Because I think there is a value consistency.
>
> But I do see why you have done things the way you have.
> And I don't necessarily think it is wrong.

When you put it that way, how can I say no to a first prize! :D
I have replaced all instances of ENOTSUPP with EOPNOTSUPP in these 2 files after making sure none of the functions returning it has a check for ENOTSUPP.
It seems most of the instances do not check for a return value anyways.
Please check v9 patch for the changes.

Thanks
Neeraj