Revision tags: v5.10.14 |
|
#
29f7c54b |
| 21-Dec-2020 |
John Garry <john.garry@huawei.com> |
Driver core: platform: Add extra error check in devm_platform_get_irqs_affinity()
The current check of nvec < minvec for nvec returned from platform_irq_count() will not detect a negative error code
Driver core: platform: Add extra error check in devm_platform_get_irqs_affinity()
The current check of nvec < minvec for nvec returned from platform_irq_count() will not detect a negative error code in nvec.
This is because minvec is unsigned, and, as such, nvec is promoted to unsigned in that check, which will make it a huge number (if it contained -EPROBE_DEFER).
In practice, an error should not occur in nvec for the only in-tree user, but add a check anyway.
Fixes: e15f2fa959f2 ("driver core: platform: Add devm_platform_get_irqs_affinity()") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1608561055-231244-1-git-send-email-john.garry@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e1dc2099 |
| 21-Dec-2020 |
John Garry <john.garry@huawei.com> |
driver core: platform: Add extra error check in devm_platform_get_irqs_affinity()
The current check of nvec < minvec for nvec returned from platform_irq_count() will not detect a negative error code
driver core: platform: Add extra error check in devm_platform_get_irqs_affinity()
The current check of nvec < minvec for nvec returned from platform_irq_count() will not detect a negative error code in nvec.
This is because minvec is unsigned, and, as such, nvec is promoted to unsigned in that check, which will make it a huge number (if it contained -EPROBE_DEFER).
In practice, an error should not occur in nvec for the only in-tree user, but add a check anyway.
Fixes: e15f2fa959f2 ("driver core: platform: Add devm_platform_get_irqs_affinity()") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1608561055-231244-1-git-send-email-john.garry@huawei.com
show more ...
|
Revision tags: v5.10 |
|
#
46e85af0 |
| 12-Dec-2020 |
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> |
driver core: platform: don't oops in platform_shutdown() on unbound devices
On shutdown the driver core calls the bus' shutdown callback also for unbound devices. A driver's shutdown callback howeve
driver core: platform: don't oops in platform_shutdown() on unbound devices
On shutdown the driver core calls the bus' shutdown callback also for unbound devices. A driver's shutdown callback however is only called for devices bound to this driver. Commit 9c30921fe799 ("driver core: platform: use bus_type functions") changed the platform bus from driver callbacks to bus callbacks, so the shutdown function must be prepared to be called without a driver. Add the corresponding check in the shutdown function.
Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions") Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201212235533.247537-1-dmitry.baryshkov@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e15f2fa9 |
| 02-Dec-2020 |
John Garry <john.garry@huawei.com> |
driver core: platform: Add devm_platform_get_irqs_affinity()
Drivers for multi-queue platform devices may also want managed interrupts for handling HW queue completion interrupts, so add support.
T
driver core: platform: Add devm_platform_get_irqs_affinity()
Drivers for multi-queue platform devices may also want managed interrupts for handling HW queue completion interrupts, so add support.
The function accepts an affinity descriptor pointer, which covers all IRQs expected for the device.
The function is devm class as the only current in-tree user will also use devm method for requesting the interrupts; as such, the function is made as devm as it can ensure ordering of freeing the irq and disposing of the mapping.
Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1606905417-183214-5-git-send-email-john.garry@huawei.com
show more ...
|
#
0aec2da4 |
| 09-Dec-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
driver core: platform: Introduce platform_get_mem_or_io()
There are at least few existing users of the proposed API which retrieves either MEM or IO resource from platform device.
Make it common to
driver core: platform: Introduce platform_get_mem_or_io()
There are at least few existing users of the proposed API which retrieves either MEM or IO resource from platform device.
Make it common to utilize in the existing and new users.
Cc: Eric Auger <eric.auger@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: kvm@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: Peng Hao <peng.hao2@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
9c30921f |
| 19-Nov-2020 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
driver core: platform: use bus_type functions
This works towards the goal mentioned in 2006 in commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown methods.").
The functions are moved
driver core: platform: use bus_type functions
This works towards the goal mentioned in 2006 in commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown methods.").
The functions are moved to where the other bus_type functions are defined and renamed to match the already established naming scheme.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201119124611.2573057-3-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
16085668 |
| 19-Nov-2020 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
driver core: platform: change logic implementing platform_driver_probe
Instead of overwriting the core driver's probe function handle probing devices for drivers loaded by platform_driver_probe() in
driver core: platform: change logic implementing platform_driver_probe
Instead of overwriting the core driver's probe function handle probing devices for drivers loaded by platform_driver_probe() in the platform driver probe function.
The intended goal is to not have to change the probe function to simplify converting the platform bus to use bus functions.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201119124611.2573057-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e21d740a |
| 19-Nov-2020 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
driver core: platform: reorder functions
This way all callbacks and structures used to initialize platform_bus_type are defined just before platform_bus_type and in the same order. Also move platfor
driver core: platform: reorder functions
This way all callbacks and structures used to initialize platform_bus_type are defined just before platform_bus_type and in the same order. Also move platform_drv_probe_fail just before it's only user.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201119124611.2573057-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10 |
|
#
948b3edb |
| 16-Sep-2020 |
Joe Perches <joe@perches.com> |
drivers core: Miscellaneous changes for sysfs_emit
Change additional instances that could use sysfs_emit and sysfs_emit_at that the coccinelle script could not convert.
o macros creating show funct
drivers core: Miscellaneous changes for sysfs_emit
Change additional instances that could use sysfs_emit and sysfs_emit_at that the coccinelle script could not convert.
o macros creating show functions with ## concatenation o unbound sprintf uses with buf+len for start of output to sysfs_emit_at o returns with ?: tests and sprintf to sysfs_emit o sysfs output with struct class * not struct device * arguments
Miscellanea:
o remove unnecessary initializations around these changes o consistently use int len for return length of show functions o use octal permissions and not S_<FOO> o rename a few show function names so DEVICE_ATTR_<FOO> can be used o use DEVICE_ATTR_ADMIN_RO where appropriate o consistently use const char *output for strings o checkpatch/style neatening
Signed-off-by: Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/8bc24444fe2049a9b2de6127389b57edfdfe324d.1600285923.git.joe@perches.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
aa838896 |
| 16-Sep-2020 |
Joe Perches <joe@perches.com> |
drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions
Convert the various sprintf fmaily calls in sysfs device show functions to sysfs_emit and sysfs_emit_at for PAGE_SIZE b
drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions
Convert the various sprintf fmaily calls in sysfs device show functions to sysfs_emit and sysfs_emit_at for PAGE_SIZE buffer safety.
Done with:
$ spatch -sp-file sysfs_emit_dev.cocci --in-place --max-width=80 .
And cocci script:
$ cat sysfs_emit_dev.cocci @@ identifier d_show; identifier dev, attr, buf; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - sprintf(buf, + sysfs_emit(buf, ...); ...> }
@@ identifier d_show; identifier dev, attr, buf; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - snprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> }
@@ identifier d_show; identifier dev, attr, buf; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - scnprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> }
@@ identifier d_show; identifier dev, attr, buf; expression chr; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - strcpy(buf, chr); + sysfs_emit(buf, chr); ...> }
@@ identifier d_show; identifier dev, attr, buf; identifier len; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - sprintf(buf, + sysfs_emit(buf, ...); ...> return len; }
@@ identifier d_show; identifier dev, attr, buf; identifier len; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - snprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> return len; }
@@ identifier d_show; identifier dev, attr, buf; identifier len; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... len = - scnprintf(buf, PAGE_SIZE, + sysfs_emit(buf, ...); ...> return len; }
@@ identifier d_show; identifier dev, attr, buf; identifier len; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { <... - len += scnprintf(buf + len, PAGE_SIZE - len, + len += sysfs_emit_at(buf, len, ...); ...> return len; }
@@ identifier d_show; identifier dev, attr, buf; expression chr; @@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf) { ... - strcpy(buf, chr); - return strlen(buf); + return sysfs_emit(buf, chr); }
Signed-off-by: Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/3d033c33056d88bbe34d4ddb62afd05ee166ab9a.1600285923.git.joe@perches.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.9 |
|
#
0de75116 |
| 09-Sep-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
platform_device: switch to simpler IDA interface
We don't need to specify any ranges when allocating IDs so we can switch to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.
ida_
platform_device: switch to simpler IDA interface
We don't need to specify any ranges when allocating IDs so we can switch to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.
ida_simple_get(ida, 0, 0, gfp) is equivalent to ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID larger than INT_MAX.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200909180248.10093-1-brgl@bgdev.pl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
0c7a6b91 |
| 10-Sep-2020 |
Stephen Boyd <swboyd@chromium.org> |
driver core: platform: Document return type of more functions
I can't always remember the return values of these functions, and so I usually jump to the function to read the kernel-doc and see that
driver core: platform: Document return type of more functions
I can't always remember the return values of these functions, and so I usually jump to the function to read the kernel-doc and see that it doesn't tell me. Then I have to spend more time reading the code to jump to the function that actually tells me the return values. Let's document it here so that we don't all have to spend time digging through the code to understand the return values.
Cc: <linux-doc@vger.kernel.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200910060440.2302925-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48 |
|
#
4a60406d |
| 18-Jun-2020 |
Barry Song <song.bao.hua@hisilicon.com> |
driver core: platform: expose numa_node to users in sysfs
Some platform devices like ARM SMMU are memory-mapped and populated by ACPI/IORT. In this case, NUMA topology of those platform devices are
driver core: platform: expose numa_node to users in sysfs
Some platform devices like ARM SMMU are memory-mapped and populated by ACPI/IORT. In this case, NUMA topology of those platform devices are exported by firmware as well. Software might care about the numa_node of those devices in order to achieve NUMA locality. This patch will show the numa_node for this kind of devices in sysfs. For those platform devices without numa, numa_node won't be visible.
Cc: Prime Zeng <prime.zeng@hisilicon.com> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Barry Song <song.bao.hua@hisilicon.com> Link: https://lore.kernel.org/r/20200619030045.81956-1-song.bao.hua@hisilicon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44 |
|
#
e5711945 |
| 01-Jun-2020 |
Barry Song <song.bao.hua@hisilicon.com> |
driver core: platform: need consistent spacing around '-'
Fix the below checkpatch issue:
ERROR: need consistent spacing around '-' (ctx:WxV) FILE: drivers/base/platform.c:1008: + len = acpi_
driver core: platform: need consistent spacing around '-'
Fix the below checkpatch issue:
ERROR: need consistent spacing around '-' (ctx:WxV) FILE: drivers/base/platform.c:1008: + len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); ^
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com> Link: https://lore.kernel.org/r/20200602045556.66948-1-song.bao.hua@hisilicon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.7, v5.4.43 |
|
#
c82c83c3 |
| 20-May-2020 |
Tang Bin <tangbin@cmss.chinamobile.com> |
driver core: platform: Fix spelling errors in platform.c
There is a word spelling mistake of 'Unegisters', thus it should be fixed.
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Link: http
driver core: platform: Fix spelling errors in platform.c
There is a word spelling mistake of 'Unegisters', thus it should be fixed.
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20200520141202.19568-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26 |
|
#
a85a6c86 |
| 16-Mar-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
driver core: platform: Clarify that IRQ 0 is invalid
These interfaces return a negative error number or an IRQ:
platform_get_irq() platform_get_irq_optional() platform_get_irq_byname() plat
driver core: platform: Clarify that IRQ 0 is invalid
These interfaces return a negative error number or an IRQ:
platform_get_irq() platform_get_irq_optional() platform_get_irq_byname() platform_get_irq_byname_optional()
The function comments suggest checking for error like this:
irq = platform_get_irq(...); if (irq < 0) return irq;
which is what most callers (~900 of 1400) do, so it's implicit that IRQ 0 is invalid. But some callers check for "irq <= 0", and it's not obvious from the source that we never return an IRQ 0.
Make this more explicit by updating the comments to say that an IRQ number is always non-zero and adding a WARN() if we ever do return zero. If we do return IRQ 0, it likely indicates a bug in the arch-specific parts of platform_get_irq().
Relevant prior discussion at [1, 2].
[1] https://lore.kernel.org/r/Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org/ [2] https://lore.kernel.org/r/Pine.LNX.4.64.0701252029570.25027@woody.linux-foundation.org/ Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
show more ...
|
#
388bcc6e |
| 08-Apr-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish
If platform bus driver registration is failed then, accessing platform bus spin lock (&drv->dr
drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish
If platform bus driver registration is failed then, accessing platform bus spin lock (&drv->driver.bus->p->klist_drivers.k_lock) in __platform_driver_probe() without verifying the return value __platform_driver_register() can lead to NULL pointer exception.
So check the return value before attempting the spin lock.
One such example is below:
For a custom usecase, I have intentionally failed the platform bus registration and I expected all the platform device/driver registrations to fail gracefully. But I came across this panic issue.
[ 1.331067] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 1.331118] #PF: supervisor write access in kernel mode [ 1.331163] #PF: error_code(0x0002) - not-present page [ 1.331208] PGD 0 P4D 0 [ 1.331233] Oops: 0002 [#1] PREEMPT SMP [ 1.331268] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-00049-g670d35fb0144 #165 [ 1.331341] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 1.331406] RIP: 0010:_raw_spin_lock+0x15/0x30 [ 1.331588] RSP: 0000:ffffc9000001be70 EFLAGS: 00010246 [ 1.331632] RAX: 0000000000000000 RBX: 00000000000000c8 RCX: 0000000000000001 [ 1.331696] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000000 [ 1.331754] RBP: 00000000ffffffed R08: 0000000000000501 R09: 0000000000000001 [ 1.331817] R10: ffff88817abcc520 R11: 0000000000000670 R12: 00000000ffffffed [ 1.331881] R13: ffffffff82dbc268 R14: ffffffff832f070a R15: 0000000000000000 [ 1.331945] FS: 0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000 [ 1.332008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.332062] CR2: 00000000000000c8 CR3: 000000000681e001 CR4: 00000000003606e0 [ 1.332126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.332189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.332252] Call Trace: [ 1.332281] __platform_driver_probe+0x92/0xee [ 1.332323] ? rtc_dev_init+0x2b/0x2b [ 1.332358] cmos_init+0x37/0x67 [ 1.332396] do_one_initcall+0x7d/0x168 [ 1.332428] kernel_init_freeable+0x16c/0x1c9 [ 1.332473] ? rest_init+0xc0/0xc0 [ 1.332508] kernel_init+0x5/0x100 [ 1.332543] ret_from_fork+0x1f/0x30 [ 1.332579] CR2: 00000000000000c8 [ 1.332616] ---[ end trace 3bd87f12e9010b87 ]--- [ 1.333549] note: swapper/0[1] exited with preempt_count 1 [ 1.333592] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 1.333736] Kernel Offset: disabled
Note, this can only be triggered if a driver errors out from this call, which should never happen. If it does, the driver needs to be fixed.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20200408214003.3356-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
9495b7e9 |
| 22-Apr-2020 |
Ulf Hansson <ulf.hansson@linaro.org> |
driver core: platform: Initialize dma_parms for platform devices
It's currently the platform driver's responsibility to initialize the pointer, dma_parms, for its corresponding struct device. The be
driver core: platform: Initialize dma_parms for platform devices
It's currently the platform driver's responsibility to initialize the pointer, dma_parms, for its corresponding struct device. The benefit with this approach allows us to avoid the initialization and to not waste memory for the struct device_dma_parameters, as this can be decided on a case by case basis.
However, it has turned out that this approach is not very practical. Not only does it lead to open coding, but also to real errors. In principle callers of dma_set_max_seg_size() doesn't check the error code, but just assumes it succeeds.
For these reasons, let's do the initialization from the common platform bus at the device registration point. This also follows the way the PCI devices are being managed, see pci_device_add().
Suggested-by: Christoph Hellwig <hch@lst.de> Cc: <stable@vger.kernel.org> Tested-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20200422100954.31211-1-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
45bb08de |
| 02-Apr-2020 |
Colin Ian King <colin.king@canonical.com> |
driver core: platform: remove redundant assignment to variable ret
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initializ
driver core: platform: remove redundant assignment to variable ret
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200402111341.511801-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
f0825246 |
| 14-Apr-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
docs: drivers: fix some warnings at base/platform.c when building docs
Currrently, two warnings are generated when building docs:
./drivers/base/platform.c:136: WARNING: Unexpected indentation. .
docs: drivers: fix some warnings at base/platform.c when building docs
Currrently, two warnings are generated when building docs:
./drivers/base/platform.c:136: WARNING: Unexpected indentation. ./drivers/base/platform.c:214: WARNING: Unexpected indentation.
As examples are code blocks, they should use "::" markup. However,
Example::
Is currently interpreted as a new section.
While we could fix kernel-doc to accept such new syntax, it is easier to just replace it with:
For Example::
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/564273815a76136fb5e453969b1012a786d99e28.1586881715.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
#
885a6471 |
| 01-Apr-2020 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "driver core: platform: Initialize dma_parms for platform devices"
This reverts commit 7c8978c0837d40c302f5e90d24c298d9ca9fc097, a new version will come in the next release cycle.
Cc: <stabl
Revert "driver core: platform: Initialize dma_parms for platform devices"
This reverts commit 7c8978c0837d40c302f5e90d24c298d9ca9fc097, a new version will come in the next release cycle.
Cc: <stable@vger.kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Ludovic Barre <ludovic.barre@st.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
7c8978c0 |
| 25-Mar-2020 |
Ulf Hansson <ulf.hansson@linaro.org> |
driver core: platform: Initialize dma_parms for platform devices
It's currently the platform driver's responsibility to initialize the pointer, dma_parms, for its corresponding struct device. The be
driver core: platform: Initialize dma_parms for platform devices
It's currently the platform driver's responsibility to initialize the pointer, dma_parms, for its corresponding struct device. The benefit with this approach allows us to avoid the initialization and to not waste memory for the struct device_dma_parameters, as this can be decided on a case by case basis.
However, it has turned out that this approach is not very practical. Not only does it lead to open coding, but also to real errors. In principle callers of dma_set_max_seg_size() doesn't check the error code, but just assumes it succeeds.
For these reasons, let's do the initialization from the common platform bus at the device registration point. This also follows the way the PCI devices are being managed, see pci_device_add().
Cc: <stable@vger.kernel.org> Suggested-by: Christoph Hellwig <hch@lst.de> Tested-by: Ludovic Barre <ludovic.barre@st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200325113407.26996-2-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
fd78901c |
| 23-Mar-2020 |
Dejin Zheng <zhengdejin5@gmail.com> |
driver core: platform: Reimplement devm_platform_ioremap_resource
Reimplement devm_platform_ioremap_resource() by calling devm_platform_ioremap_and_get_resource() with res = NULL to simplify the cod
driver core: platform: Reimplement devm_platform_ioremap_resource
Reimplement devm_platform_ioremap_resource() by calling devm_platform_ioremap_and_get_resource() with res = NULL to simplify the code.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Link: https://lore.kernel.org/r/20200323160612.17277-6-zhengdejin5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
890cc39a |
| 23-Mar-2020 |
Dejin Zheng <zhengdejin5@gmail.com> |
drivers: provide devm_platform_get_and_ioremap_resource()
Since commit "drivers: provide devm_platform_ioremap_resource()", it was wrap platform_get_resource() and devm_ioremap_resource() as single
drivers: provide devm_platform_get_and_ioremap_resource()
Since commit "drivers: provide devm_platform_ioremap_resource()", it was wrap platform_get_resource() and devm_ioremap_resource() as single helper devm_platform_ioremap_resource(). but now, many drivers still used platform_get_resource() and devm_ioremap_resource() together in the kernel tree. The reason can not be replaced is they still need use the resource variables obtained by platform_get_resource(). so provide this helper.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Suggested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Link: https://lore.kernel.org/r/20200323160612.17277-2-zhengdejin5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.25 |
|
#
e3a36eb6 |
| 11-Mar-2020 |
Christoph Hellwig <hch@lst.de> |
driver code: clarify and fix platform device DMA mask allocation
This does three inter-related things to clarify the usage of the platform device dma_mask field. In the process, fix the bug introduc
driver code: clarify and fix platform device DMA mask allocation
This does three inter-related things to clarify the usage of the platform device dma_mask field. In the process, fix the bug introduced by cdfee5623290 ("driver core: initialize a default DMA mask for platform device") that caused Artem Tashkinov's laptop to not boot with newer Fedora kernels.
This does:
- First off, rename the field to "platform_dma_mask" to make it greppable.
We have way too many different random fields called "dma_mask" in various data structures, where some of them are actual masks, and some of them are just pointers to the mask. And the structures all have pointers to each other, or embed each other inside themselves, and "pdev" sometimes means "platform device" and sometimes it means "PCI device".
So to make it clear in the code when you actually use this new field, give it a unique name (it really should be something even more unique like "platform_device_dma_mask", since it's per platform device, not per platform, but that gets old really fast, and this is unique enough in context).
To further clarify when the field gets used, initialize it when we actually start using it with the default value.
- Then, use this field instead of the random one-off allocation in platform_device_register_full() that is now unnecessary since we now already have a perfectly fine allocation for it in the platform device structure.
- The above then allows us to fix the actual bug, where the error path of platform_device_register_full() would unconditionally free the platform device DMA allocation with 'kfree()'.
That kfree() was dont regardless of whether the allocation had been done earlier with the (now removed) kmalloc, or whether setup_pdev_dma_masks() had already been used and the dma_mask pointer pointed to the mask that was part of the platform device.
It seems most people never triggered the error path, or only triggered it from a call chain that set an explicit pdevinfo->dma_mask value (and thus caused the unnecessary allocation that was "cleaned up" in the error path) before calling platform_device_register_full().
Robin Murphy points out that in Artem's case the wdat_wdt driver failed in platform_device_add(), and that was the one that had called platform_device_register_full() with pdevinfo.dma_mask = 0, and would have caused that kfree() of pdev.dma_mask corrupting the heap.
A later unrelated kmalloc() then oopsed due to the heap corruption.
Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device") Reported-bisected-and-tested-by: Artem S. Tashkinov <aros@gmx.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|