Re: [PATCH v1 1/1] pps: clients: parport: Switch to use module_parport_driver()

[Rodolfo Giometti]

On 11/05/21 09:50, Andy Shevchenko wrote:
> On Tue, May 11, 2021 at 09:26:36AM +0200, Rodolfo Giometti wrote:
>> On 11/05/21 09:18, Andy Shevchenko wrote:
>>> On Tue, May 11, 2021 at 09:05:00AM +0200, Rodolfo Giometti wrote:
>>>> On 10/05/21 16:13, Andy Shevchenko wrote:
>>>>> Switch to use module_parport_driver() to reduce boilerplate code.
>>>>>
>>>>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
>>>>> ---
>>>>>  drivers/pps/clients/pps_parport.c | 42 ++++++-------------------------
>>>>>  1 file changed, 8 insertions(+), 34 deletions(-)
>>>>>
>>>>> diff --git a/drivers/pps/clients/pps_parport.c b/drivers/pps/clients/pps_parport.c
>>>>> index 7a41fb7b0dec..42f93d4c6ee3 100644
>>>>> --- a/drivers/pps/clients/pps_parport.c
>>>>> +++ b/drivers/pps/clients/pps_parport.c
>>>>> @@ -22,8 +22,6 @@
>>>>>  #include <linux/parport.h>
>>>>>  #include <linux/pps_kernel.h>
>>>>>  
>>>>> -#define DRVDESC "parallel port PPS client"
>>>>> -
>>>>>  /* module parameters */
>>>>>  
>>>>>  #define CLEAR_WAIT_MAX		100
>>>>> @@ -138,6 +136,12 @@ static void parport_attach(struct parport *port)
>>>>>  		.dev		= NULL
>>>>>  	};
>>>>>  
>>>>> +	if (clear_wait > CLEAR_WAIT_MAX) {
>>>>> +		pr_err("clear_wait value should be not greater then %d\n",
>>>>> +		       CLEAR_WAIT_MAX);
>>>>> +		return;
>>>>> +	}
>>>>> +
>>>>
>>>> Why do you need to do so? Maybe a comment would be welcomed.
>>>
>>> It's in original code, I just moved it to ->probe().
>>>
>>> What comment do you want to have here, because original code has no comment (I
>>> think in any case it's out of scope of this change, but may be prepended or
>>> appended to the series)?
>>
>> Mmm... these functions can be called at different times, so I don't know if we
>> can just move the code safely.
> 
> I do not see any issue here. TL;DR: it won't be worse, but might even give an
> improvement.
> 
> Before it prevented to module to be initialized,
> now one may amend this at run time. the downside is that now it will require
> module removal and inserting versus just two attempts of inserting in a row.
> 
> For the built-in case it shouldn't change much (but if
> /sys/module/.../parameters/... is writable for this, then it will allow to do
> the similar trick as above, so extending functionality with the flexibility,
> means direct improvement).
> 
> Okay, permissions are 0 there, I don't remember what it means, maybe the
> parameter won't be available under /sysfs at all, but again, it won't change
> the functional behaviour, the downside is the memory consumed by the 'built-in'
> code at run time.

OK, I see. If so it's OK for me:

Acked-by: Rodolfo Giometti <giometti@xxxxxxxxxxxx>

-- 
GNU/Linux Solutions                  e-mail: giometti@xxxxxxxxxxxx
Linux Device Driver                          giometti@xxxxxxxx
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti