linux-dev/drivers/parport/share.c, branch linus/master

parport: fix a kernel-doc markup

2021-01-21T21:06:00Z

The kernel-doc markup inside share.c is actually for __parport_register_driver. The actual goal seems to be to document parport_register_driver(). So, fix the existing markup and add a new one. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/dc0778af8c466cc667409ead05876a5cfd3cbece.1610610937.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet

parport: remove use of devmodel

2020-04-23T15:05:40Z

Now that all the drivers using parallel port has been converted to use device model, there is no driver left which has devmodel as false. Remove the part of the code which expects devmodel can be false. Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20200403134325.11523-11-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman

parport: remove unused parport_register_device()

2020-04-23T15:05:39Z

All the drivers that are using parallel port has been converted to use the new device model api, and parport_register_device() is no longer used. Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20200403134325.11523-10-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman

parport: Add comments for parport_register_dev_model()

2020-04-23T15:05:39Z

In preparation to remove parport_register_device(), copy the comments to parport_register_dev_model() and modify the parameters according to what parport_register_dev_model() has. Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20200403134325.11523-9-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman

parport: Use more comon logging styles

2020-04-23T15:05:37Z

Some of the logging can be poorly formatted because of unexpected line breaks given printks without KERN_CONT that should be pr_cont. Miscellanea: o Remove unnecessary spaces between function name and open parenthesis o Convert bare printks to pr_ where appropriate o Convert embedded function names to use %s, __func__ o Coalesce formats o Realign arguments o Use do {} while (0) in a macro and not a bare if Signed-off-by: Joe Perches Reviewed-by: Randy Dunlap Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20200403134325.11523-3-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman

parport: Convert printk(KERN_ to pr_(

2020-04-23T15:05:37Z

Use the more common kernel style. Miscellanea: o Coalesce formats o Realign arguments Signed-off-by: Joe Perches Reviewed-by: Randy Dunlap Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20200403134325.11523-2-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman

parport: load lowlevel driver if ports not found

2019-11-13T11:09:48Z

Usually all the distro will load the parport low level driver as part of their initialization. But we can get into a situation where all the parallel port drivers are built as module and we unload all the modules at a later time. Then if we just do "modprobe parport" it will only load the parport module and will not load the low level driver which will actually register the ports. So, check the bus if there is any parport registered, if not, load the low level driver. We can get into the above situation with all distro but only Suse has setup the alias for "parport_lowlevel" and so it only works in Suse. Users of Debian based distro will need to load the lowlevel module manually. Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20191016144540.18810-3-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman

parport: do not check portlist when using device-model

2019-11-13T11:09:48Z

We do not need to maintain a list of ports when we are using the device-model. The base layer is going to maintain the list for us and we can get the list of ports just using bus_for_each_dev(). Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20191016144540.18810-2-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman

parport: Fix mem leak in parport_register_dev_model

2019-05-24T18:39:23Z

BUG: memory leak unreferenced object 0xffff8881df48cda0 (size 16): comm "syz-executor.0", pid 5077, jiffies 4295994670 (age 22.280s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d2d0d5fe>] parport_register_dev_model+0x141/0x6e0 [parport] [<00000000782f6dab>] 0xffffffffc15d1196 [<00000000d2ca6ae4>] platform_drv_probe+0x7e/0x100 [<00000000628c2a94>] really_probe+0x342/0x4d0 [<000000006874f5da>] driver_probe_device+0x8c/0x170 [<00000000424de37a>] __device_attach_driver+0xda/0x100 [<000000002acab09a>] bus_for_each_drv+0xfe/0x170 [<000000003d9e5f31>] __device_attach+0x190/0x230 [<0000000035d32f80>] bus_probe_device+0x123/0x140 [<00000000a05ba627>] device_add+0x7cc/0xce0 [<000000003f7560bf>] platform_device_add+0x230/0x3c0 [<000000002a0be07d>] 0xffffffffc15d0949 [<000000007361d8d2>] port_check+0x3b/0x50 [parport] [<000000004d67200f>] bus_for_each_dev+0x115/0x180 [<000000003ccfd11c>] __parport_register_driver+0x1f0/0x210 [parport] [<00000000987f06fc>] 0xffffffffc15d803e After commit 4e5a74f1db8d ("parport: Revert "parport: fix memory leak""), free_pardevice do not free par_dev->state, we should free it in error path of parport_register_dev_model before return. Reported-by: Hulk Robot Fixes: 4e5a74f1db8d ("parport: Revert "parport: fix memory leak"") Signed-off-by: YueHaibing Signed-off-by: Greg Kroah-Hartman

Revert "parport: daisy: use new parport device model"

2019-03-25T21:49:00Z

This reverts commit 1aec4211204d9463d1fd209eb50453de16254599. Steven Rostedt reports that it causes a hang at bootup and bisected it to this commit. The troigger is apparently a module alias for "parport_lowlevel" that points to "parport_pc", which causes a hang with modprobe -q -- parport_lowlevel blocking forever with a backtrace like this: wait_for_completion_killable+0x1c/0x28 call_usermodehelper_exec+0xa7/0x108 __request_module+0x351/0x3d8 get_lowlevel_driver+0x28/0x41 [parport] __parport_register_driver+0x39/0x1f4 [parport] daisy_drv_init+0x31/0x4f [parport] parport_bus_init+0x5d/0x7b [parport] parport_default_proc_register+0x26/0x1000 [parport] do_one_initcall+0xc2/0x1e0 do_init_module+0x50/0x1d4 load_module+0x1c2e/0x21b3 sys_init_module+0xef/0x117 Supid says: "Due to the new device model daisy driver will now try to find the parallel ports while trying to register its driver so that it can bind with them. Now, since daisy driver is loaded while parport bus is initialising the list of parport is still empty and it tries to load the lowlevel driver, which has an alias set to parport_pc, now causes a deadlock" But I don't think the daisy driver should be loaded by the parport initialization in the first place, so let's revert the whole change. If the daisy driver can just initialize separately on its own (like a driver should), instead of hooking into the parport init sequence directly, this issue probably would go away. Reported-and-bisected-by: Steven Rostedt (VMware) Reported-by: Michal Kubecek Acked-by: Greg Kroah-Hartman Cc: Sudip Mukherjee Signed-off-by: Linus Torvalds