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 |
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
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
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
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
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