mbox series

[00/52] USB: store owner from modules with usb_serial_register_drivers()

Message ID 20240328-module-owner-usb-serial-v1-0-bc46c9ffbf56@linaro.org (mailing list archive)
Headers show
Series USB: store owner from modules with usb_serial_register_drivers() | expand

Message

Krzysztof Kozlowski March 28, 2024, 10:05 p.m. UTC
Merging
=======
All further patches depend on the first patch.

Description
===========
This is going to be a bit of a patch-bomb, but with trivial patches, so
I think it is still acceptable. If it is too much, apologies and I will
solve it.

Modules registering driver with usb_serial_register_drivers() might
forget to set .owner field.

Solve the problem by moving this task away from the drivers to the core
amba bus code, just like we did for platform_driver in commit
9447057eaff8 ("platform_device: use a macro instead of
platform_driver_register").

Best regards,
Krzysztof

---
Krzysztof Kozlowski (52):
      USB: serial: store owner from modules with usb_serial_register_drivers()
      USB: serial: aircable: drop driver owner initialization
      USB: serial: ark3116: drop driver owner initialization
      USB: serial: belkin_sa: drop driver owner initialization
      USB: serial: ch341: drop driver owner initialization
      USB: serial: cp210x: drop driver owner initialization
      USB: serial: cyberjack: drop driver owner initialization
      USB: serial: cypress_m8: drop driver owner initialization
      USB: serial: digi_acceleport: drop driver owner initialization
      USB: serial: empeg: drop driver owner initialization
      USB: serial: f81232: drop driver owner initialization
      USB: serial: ftdi_sio: drop driver owner initialization
      USB: serial: garmin_gps: drop driver owner initialization
      USB: serial: generic: drop driver owner initialization
      USB: serial: io_edgeport: drop driver owner initialization
      USB: serial: io_ti: drop driver owner initialization
      USB: serial: ipaq: drop driver owner initialization
      USB: serial: ipw: drop driver owner initialization
      USB: serial: ir-usb: drop driver owner initialization
      USB: serial: iuu: drop driver owner initialization
      USB: serial: keyspan: drop driver owner initialization
      USB: serial: keyspan_pda: drop driver owner initialization
      USB: serial: kl5kusb105: drop driver owner initialization
      USB: serial: kobil_sct: drop driver owner initialization
      USB: serial: mct_u232: drop driver owner initialization
      USB: serial: metro_usb: drop driver owner initialization
      USB: serial: mos7720: drop driver owner initialization
      USB: serial: mos7840: drop driver owner initialization
      USB: serial: mxuport: drop driver owner initialization
      USB: serial: navman: drop driver owner initialization
      USB: serial: omninet: drop driver owner initialization
      USB: serial: opticon: drop driver owner initialization
      USB: serial: option: drop driver owner initialization
      USB: serial: oti6858: drop driver owner initialization
      USB: serial: pl2303: drop driver owner initialization
      USB: serial: qcaux: drop driver owner initialization
      USB: serial: qcserial: drop driver owner initialization
      USB: serial: quatech2: drop driver owner initialization
      USB: serial: safe_serial: drop driver owner initialization
      USB: serial: sierra: drop driver owner initialization
      USB: serial: spcp8x5: drop driver owner initialization
      USB: serial: ssu100: drop driver owner initialization
      USB: serial: symbol: drop driver owner initialization
      USB: serial: ti_usb_3410_5052: drop driver owner initialization
      USB: serial: upd78f0730: drop driver owner initialization
      USB: serial: simple: drop driver owner initialization
      USB: serial: debug: drop driver owner initialization
      USB: serial: visor: drop driver owner initialization
      USB: serial: whiteheat: drop driver owner initialization
      USB: serial: wishbone: drop driver owner initialization
      USB: serial: xr: drop driver owner initialization
      USB: serial: xsens_mt: drop driver owner initialization

 drivers/usb/serial/aircable.c          |  1 -
 drivers/usb/serial/ark3116.c           |  1 -
 drivers/usb/serial/belkin_sa.c         |  1 -
 drivers/usb/serial/ch341.c             |  1 -
 drivers/usb/serial/cp210x.c            |  1 -
 drivers/usb/serial/cyberjack.c         |  1 -
 drivers/usb/serial/cypress_m8.c        |  3 ---
 drivers/usb/serial/digi_acceleport.c   |  2 --
 drivers/usb/serial/empeg.c             |  1 -
 drivers/usb/serial/f81232.c            |  2 --
 drivers/usb/serial/ftdi_sio.c          |  1 -
 drivers/usb/serial/garmin_gps.c        |  1 -
 drivers/usb/serial/generic.c           |  1 -
 drivers/usb/serial/io_edgeport.c       |  4 ----
 drivers/usb/serial/io_ti.c             |  2 --
 drivers/usb/serial/ipaq.c              |  1 -
 drivers/usb/serial/ipw.c               |  1 -
 drivers/usb/serial/ir-usb.c            |  1 -
 drivers/usb/serial/iuu_phoenix.c       |  1 -
 drivers/usb/serial/keyspan.c           |  4 ----
 drivers/usb/serial/keyspan_pda.c       |  2 --
 drivers/usb/serial/kl5kusb105.c        |  1 -
 drivers/usb/serial/kobil_sct.c         |  1 -
 drivers/usb/serial/mct_u232.c          |  1 -
 drivers/usb/serial/metro-usb.c         |  1 -
 drivers/usb/serial/mos7720.c           |  1 -
 drivers/usb/serial/mos7840.c           |  1 -
 drivers/usb/serial/mxuport.c           |  1 -
 drivers/usb/serial/navman.c            |  1 -
 drivers/usb/serial/omninet.c           |  1 -
 drivers/usb/serial/opticon.c           |  1 -
 drivers/usb/serial/option.c            |  1 -
 drivers/usb/serial/oti6858.c           |  1 -
 drivers/usb/serial/pl2303.c            |  1 -
 drivers/usb/serial/qcaux.c             |  1 -
 drivers/usb/serial/qcserial.c          |  1 -
 drivers/usb/serial/quatech2.c          |  1 -
 drivers/usb/serial/safe_serial.c       |  1 -
 drivers/usb/serial/sierra.c            |  1 -
 drivers/usb/serial/spcp8x5.c           |  1 -
 drivers/usb/serial/ssu100.c            |  1 -
 drivers/usb/serial/symbolserial.c      |  1 -
 drivers/usb/serial/ti_usb_3410_5052.c  |  2 --
 drivers/usb/serial/upd78f0730.c        |  1 -
 drivers/usb/serial/usb-serial-simple.c |  1 -
 drivers/usb/serial/usb-serial.c        | 12 +++++++-----
 drivers/usb/serial/usb_debug.c         |  2 --
 drivers/usb/serial/visor.c             |  3 ---
 drivers/usb/serial/whiteheat.c         |  2 --
 drivers/usb/serial/wishbone-serial.c   |  1 -
 drivers/usb/serial/xr_serial.c         |  1 -
 drivers/usb/serial/xsens_mt.c          |  1 -
 include/linux/usb/serial.h             |  7 +++++--
 53 files changed, 12 insertions(+), 75 deletions(-)
---
base-commit: 7fdcff3312e16ba8d1419f8a18f465c5cc235ecf
change-id: 20240328-module-owner-usb-serial-8a067f622b70

Best regards,

Comments

Johan Hovold April 15, 2024, 8:54 a.m. UTC | #1
On Thu, Mar 28, 2024 at 11:05:38PM +0100, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first patch.
> 
> Description
> ===========
> This is going to be a bit of a patch-bomb, but with trivial patches, so
> I think it is still acceptable. If it is too much, apologies and I will
> solve it.

No, sending 51 trivial one-line cleanup patches like this is not
acceptable.

This is just one logical change so squash them all into one patch for
the entire subsystem (i.e. this series should contain two patches).

> Modules registering driver with usb_serial_register_drivers() might
> forget to set .owner field.
> 
> Solve the problem by moving this task away from the drivers to the core
> amba bus code, just like we did for platform_driver in commit

"amba" copy pasta.

> 9447057eaff8 ("platform_device: use a macro instead of
> platform_driver_register").

> Krzysztof Kozlowski (52):
>       USB: serial: store owner from modules with usb_serial_register_drivers()
>       USB: serial: aircable: drop driver owner initialization
...
>       USB: serial: xsens_mt: drop driver owner initialization

>  53 files changed, 12 insertions(+), 75 deletions(-)

Johan
Krzysztof Kozlowski May 3, 2024, 9:46 a.m. UTC | #2
On 28/03/2024 23:05, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first patch.
> 
> Description
> ===========
> This is going to be a bit of a patch-bomb, but with trivial patches, so
> I think it is still acceptable. If it is too much, apologies and I will
> solve it.
> 
> Modules registering driver with usb_serial_register_drivers() might
> forget to set .owner field.
> 
> Solve the problem by moving this task away from the drivers to the core
> amba bus code, just like we did for platform_driver in commit
> 9447057eaff8 ("platform_device: use a macro instead of
> platform_driver_register").

Hi Greg,

Any comments on this patchset? I know your patchqueue is usually busy,
that's why I did not ping for some time. I just want to know it did not
end up in some spam folder.

Best regards,
Krzysztof
Krzysztof Kozlowski May 3, 2024, 9:48 a.m. UTC | #3
On 03/05/2024 11:46, Krzysztof Kozlowski wrote:
> On 28/03/2024 23:05, Krzysztof Kozlowski wrote:
>> Merging
>> =======
>> All further patches depend on the first patch.
>>
>> Description
>> ===========
>> This is going to be a bit of a patch-bomb, but with trivial patches, so
>> I think it is still acceptable. If it is too much, apologies and I will
>> solve it.
>>
>> Modules registering driver with usb_serial_register_drivers() might
>> forget to set .owner field.
>>
>> Solve the problem by moving this task away from the drivers to the core
>> amba bus code, just like we did for platform_driver in commit
>> 9447057eaff8 ("platform_device: use a macro instead of
>> platform_driver_register").
> 
> Hi Greg,
> 
> Any comments on this patchset? I know your patchqueue is usually busy,
> that's why I did not ping for some time. I just want to know it did not
> end up in some spam folder.

Never mind, I missed Johan's response.

Best regards,
Krzysztof
Krzysztof Kozlowski May 3, 2024, 9:49 a.m. UTC | #4
On 15/04/2024 10:54, Johan Hovold wrote:
> On Thu, Mar 28, 2024 at 11:05:38PM +0100, Krzysztof Kozlowski wrote:
>> Merging
>> =======
>> All further patches depend on the first patch.
>>
>> Description
>> ===========
>> This is going to be a bit of a patch-bomb, but with trivial patches, so
>> I think it is still acceptable. If it is too much, apologies and I will
>> solve it.
> 
> No, sending 51 trivial one-line cleanup patches like this is not
> acceptable.
> 
> This is just one logical change so squash them all into one patch for
> the entire subsystem (i.e. this series should contain two patches).
> 

Sure. This is not exactly one logical change, but two, because the first
patch might fix some drivers which forgot to set the owner (even if I
did not identify them).

Best regards,
Krzysztof
Johan Hovold May 3, 2024, 10:57 a.m. UTC | #5
On Fri, May 03, 2024 at 11:49:53AM +0200, Krzysztof Kozlowski wrote:
> On 15/04/2024 10:54, Johan Hovold wrote:

> > No, sending 51 trivial one-line cleanup patches like this is not
> > acceptable.
> > 
> > This is just one logical change so squash them all into one patch for
> > the entire subsystem (i.e. this series should contain two patches).
> 
> Sure. This is not exactly one logical change, but two, because the first
> patch might fix some drivers which forgot to set the owner (even if I
> did not identify them).

Sorry if this wasn't clear enough, but I was referring to the last 51
one-line patches being one logical change (and hence the series should
contain two patches as I mentioned).

Johan