[PATCH 1/4] staging: atomisp: fix unsigned int comparison with less than zero

Fix warnings from the smatch tool atomisp_cmd.c:2649 atomisp_set_array_res() warn: unsigned 'config->width' is never less than zero. atomisp_cmd.c:2650 atomisp_set_array_res() warn: unsigned 'config->height' is never less than zero. Signed-off-by: Daeseok Youn

[PATCH 1/4] staging: atomisp: fix unsigned int comparison with less than zero

Fix warnings from the smatch tool atomisp_cmd.c:2649 atomisp_set_array_res() warn: unsigned 'config->width' is never less than zero. atomisp_cmd.c:2650 atomisp_set_array_res() warn: unsigned 'config->height' is never less than zero. Signed-off-by: Daeseok Youn ---

[PATCH v3] tpm_crb: request and relinquish locality 0

From: Jarkko Sakkinen This commit adds support for requesting and relinquishing locality 0 in tpm_crb for the course of command transmission. In order to achieve this, two new callbacks are added to struct tpm_class_ops: - request_locality - relinquish_locality

[PATCH v3] tpm_crb: request and relinquish locality 0

From: Jarkko Sakkinen This commit adds support for requesting and relinquishing locality 0 in tpm_crb for the course of command transmission. In order to achieve this, two new callbacks are added to struct tpm_class_ops: - request_locality - relinquish_locality These are called before sending

[PATCH] irqchip: gic-v3-its: Don't assume GICv3 hardware supports 16bit INTID

The current ITS driver is assuming every ITS hardware implementation supports minimum of 16bit INTID. But this is not true, as per GICv3 specification, INTID field is IMPLEMENTATION DEFINED in the range of 14-24 bits. We might see an unpredictable system behavior on systems where hardware support

[PATCH] irqchip: gic-v3-its: Don't assume GICv3 hardware supports 16bit INTID

The current ITS driver is assuming every ITS hardware implementation supports minimum of 16bit INTID. But this is not true, as per GICv3 specification, INTID field is IMPLEMENTATION DEFINED in the range of 14-24 bits. We might see an unpredictable system behavior on systems where hardware support

ATENCIÓN;

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

ATENCIÓN;

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

man-pages-4.10 is released

The Linux man-pages maintainer proudly announces: man-pages-4.10 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from over 40 contributors. The release sees a large number of changes: over 600 commits changing around 160 pages. The changes include

man-pages-4.10 is released

The Linux man-pages maintainer proudly announces: man-pages-4.10 - man pages for Linux This release resulted from patches, bug reports, reviews, and comments from over 40 contributors. The release sees a large number of changes: over 600 commits changing around 160 pages. The changes include

Re: [PATCH] drivers/pcmcia: NO_IRQ removal for electra_cf.c

Arnd Bergmann writes: > On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman > wrote: >> Michael Ellerman writes: >> >>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it >>> from electra_cf.c which is a

Re: [PATCH] drivers/pcmcia: NO_IRQ removal for electra_cf.c

Arnd Bergmann writes: > On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman > wrote: >> Michael Ellerman writes: >> >>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it >>> from electra_cf.c which is a powerpc-only driver. >>> >>> Signed-off-by: Michael Ellerman >>>

Re: [PATCH] iio: 104-quad-8: Fix off-by-one error when addressing flag register

On Tue, Mar 14, 2017 at 11:00:43AM -0400, William Breathitt Gray wrote: > On Mon, Mar 13, 2017 at 09:33:45PM +, Jonathan Cameron wrote: > >On 13/03/17 13:33, William Breathitt Gray wrote: > >> On Sat, Feb 11, 2017 at 09:37:35AM +, Jonathan Cameron wrote: > >>> On 09/02/17 15:03, William

Re: [PATCH] iio: 104-quad-8: Fix off-by-one error when addressing flag register

On Tue, Mar 14, 2017 at 11:00:43AM -0400, William Breathitt Gray wrote: > On Mon, Mar 13, 2017 at 09:33:45PM +, Jonathan Cameron wrote: > >On 13/03/17 13:33, William Breathitt Gray wrote: > >> On Sat, Feb 11, 2017 at 09:37:35AM +, Jonathan Cameron wrote: > >>> On 09/02/17 15:03, William

[PATCH v2] vTPM: Fix missing NULL check

The current code passes the address of tpm_chip as the argument to dev_get_drvdata() without prior NULL check in tpm_ibmvtpm_get_desired_dma. This resulted an oops during kernel boot when vTPM is enabled in Power partition configured in active memory sharing mode. The vio_driver's

[PATCH v2] vTPM: Fix missing NULL check

The current code passes the address of tpm_chip as the argument to dev_get_drvdata() without prior NULL check in tpm_ibmvtpm_get_desired_dma. This resulted an oops during kernel boot when vTPM is enabled in Power partition configured in active memory sharing mode. The vio_driver's

[PATCH v2 06/10] mm: remove SWAP_AGAIN in ttu

In 2002, [1] introduced SWAP_AGAIN. At that time, try_to_unmap_one used spin_trylock(>page_table_lock) so it's really easy to contend and fail to hold a lock so SWAP_AGAIN to keep LRU status makes sense. However, now we changed it to mutex-based lock and be able to block without skip pte so there

[PATCH v2 06/10] mm: remove SWAP_AGAIN in ttu

In 2002, [1] introduced SWAP_AGAIN. At that time, try_to_unmap_one used spin_trylock(>page_table_lock) so it's really easy to contend and fail to hold a lock so SWAP_AGAIN to keep LRU status makes sense. However, now we changed it to mutex-based lock and be able to block without skip pte so there

[PATCH v2 04/10] mm: make the try_to_munlock void function

try_to_munlock returns SWAP_MLOCK if the one of VMAs mapped the page has VM_LOCKED flag. In that time, VM set PG_mlocked to the page if the page is not pte-mapped THP which cannot be mlocked, either. With that, __munlock_isolated_page can use PageMlocked to check whether try_to_munlock is

[PATCH v2 04/10] mm: make the try_to_munlock void function

try_to_munlock returns SWAP_MLOCK if the one of VMAs mapped the page has VM_LOCKED flag. In that time, VM set PG_mlocked to the page if the page is not pte-mapped THP which cannot be mlocked, either. With that, __munlock_isolated_page can use PageMlocked to check whether try_to_munlock is

[PATCH v2 07/10] mm: make ttu's return boolean

try_to_unmap returns SWAP_SUCCESS or SWAP_FAIL so it's suitable for boolean return. This patch changes it. Cc: "Kirill A. Shutemov" Cc: Naoya Horiguchi Signed-off-by: Minchan Kim --- include/linux/rmap.h | 4 ++--

[PATCH v2 08/10] mm: make rmap_walk void function

There is no user of return value from rmap_walk friend so this patch makes them void function. Signed-off-by: Minchan Kim --- include/linux/ksm.h | 5 ++--- include/linux/rmap.h | 4 ++-- mm/ksm.c | 16 ++-- mm/rmap.c| 32

[PATCH v2 07/10] mm: make ttu's return boolean

try_to_unmap returns SWAP_SUCCESS or SWAP_FAIL so it's suitable for boolean return. This patch changes it. Cc: "Kirill A. Shutemov" Cc: Naoya Horiguchi Signed-off-by: Minchan Kim --- include/linux/rmap.h | 4 ++-- mm/huge_memory.c | 6 +++--- mm/memory-failure.c | 26

[PATCH v2 08/10] mm: make rmap_walk void function

There is no user of return value from rmap_walk friend so this patch makes them void function. Signed-off-by: Minchan Kim --- include/linux/ksm.h | 5 ++--- include/linux/rmap.h | 4 ++-- mm/ksm.c | 16 ++-- mm/rmap.c| 32 +---

[PATCH v2 01/10] mm: remove unncessary ret in page_referenced

Anyone doesn't use ret variable. Remove it. Acked-by: Hillf Danton Acked-by: Kirill A. Shutemov Signed-off-by: Minchan Kim --- mm/rmap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v2 10/10] mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

There is no user for it. Remove it. Signed-off-by: Minchan Kim --- include/linux/rmap.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/include/linux/rmap.h b/include/linux/rmap.h index 13ed232..43ef2c3 100644 --- a/include/linux/rmap.h +++ b/include/linux/rmap.h

[PATCH v2 10/10] mm: remove SWAP_[SUCCESS|AGAIN|FAIL]

There is no user for it. Remove it. Signed-off-by: Minchan Kim --- include/linux/rmap.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/include/linux/rmap.h b/include/linux/rmap.h index 13ed232..43ef2c3 100644 --- a/include/linux/rmap.h +++ b/include/linux/rmap.h @@ -295,11 +295,4 @@

[PATCH v2 01/10] mm: remove unncessary ret in page_referenced

Anyone doesn't use ret variable. Remove it. Acked-by: Hillf Danton Acked-by: Kirill A. Shutemov Signed-off-by: Minchan Kim --- mm/rmap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index 7d24bb9..9dbfa6f 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@

[PATCH v2 02/10] mm: remove SWAP_DIRTY in ttu

If we found lazyfree page is dirty, try_to_unmap_one can just SetPageSwapBakced in there like PG_mlocked page and just return with SWAP_FAIL which is very natural because the page is not swappable right now so that vmscan can activate it. There is no point to introduce new return value SWAP_DIRTY

[PATCH v2 02/10] mm: remove SWAP_DIRTY in ttu

If we found lazyfree page is dirty, try_to_unmap_one can just SetPageSwapBakced in there like PG_mlocked page and just return with SWAP_FAIL which is very natural because the page is not swappable right now so that vmscan can activate it. There is no point to introduce new return value SWAP_DIRTY

[PATCH v2 05/10] mm: remove SWAP_MLOCK in ttu

ttu don't need to return SWAP_MLOCK. Instead, just return SWAP_FAIL because it means the page is not-swappable so it should move to another LRU list(active or unevictable). putback friends will move it to right list depending on the page's LRU flag. Signed-off-by: Minchan Kim

[PATCH v2 05/10] mm: remove SWAP_MLOCK in ttu

ttu don't need to return SWAP_MLOCK. Instead, just return SWAP_FAIL because it means the page is not-swappable so it should move to another LRU list(active or unevictable). putback friends will move it to right list depending on the page's LRU flag. Signed-off-by: Minchan Kim ---

[PATCH v2 00/10] make try_to_unmap simple

Currently, try_to_unmap returns various return value(SWAP_SUCCESS, SWAP_FAIL, SWAP_AGAIN, SWAP_DIRTY and SWAP_MLOCK). When I look into that, it's unncessary complicated so this patch aims for cleaning it up. Change ttu to boolean function so we can remove SWAP_AGAIN, SWAP_DIRTY, SWAP_MLOCK. *

[PATCH v2 09/10] mm: make rmap_one boolean function

rmap_one's return value controls whether rmap_work should contine to scan other ptes or not so it's target for changing to boolean. Return true if the scan should be continued. Otherwise, return false to stop the scanning. This patch makes rmap_one's return value to boolean. Signed-off-by:

[PATCH v2 03/10] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

If the page is mapped and rescue in try_to_unmap_one, page_mapcount(page) == 0 cannot be true so page_mapcount check in try_to_unmap is enough to return SWAP_SUCCESS. IOW, SWAP_MLOCK check is redundant so remove it. Signed-off-by: Minchan Kim --- mm/rmap.c | 2 +- 1 file

[PATCH v2 00/10] make try_to_unmap simple

Currently, try_to_unmap returns various return value(SWAP_SUCCESS, SWAP_FAIL, SWAP_AGAIN, SWAP_DIRTY and SWAP_MLOCK). When I look into that, it's unncessary complicated so this patch aims for cleaning it up. Change ttu to boolean function so we can remove SWAP_AGAIN, SWAP_DIRTY, SWAP_MLOCK. *

[PATCH v2 09/10] mm: make rmap_one boolean function

rmap_one's return value controls whether rmap_work should contine to scan other ptes or not so it's target for changing to boolean. Return true if the scan should be continued. Otherwise, return false to stop the scanning. This patch makes rmap_one's return value to boolean. Signed-off-by:

[PATCH v2 03/10] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

If the page is mapped and rescue in try_to_unmap_one, page_mapcount(page) == 0 cannot be true so page_mapcount check in try_to_unmap is enough to return SWAP_SUCCESS. IOW, SWAP_MLOCK check is redundant so remove it. Signed-off-by: Minchan Kim --- mm/rmap.c | 2 +- 1 file changed, 1

Re: [PATCH] doc: ABI: vdso: update parse_vdso.c reference

Hi Jonathan, On Mon, Mar 13, 2017 at 05:13:38PM -0600, Jonathan Corbet wrote: > On Wed, 8 Mar 2017 21:50:31 +0200 > Baruch Siach wrote: > > Since commit f9b6b0ef603 ("selftests: move vDSO tests from > > Documentation/vDSO") > > parse_vdso.c moved under selftests. Update the

Re: [PATCH] doc: ABI: vdso: update parse_vdso.c reference

Hi Jonathan, On Mon, Mar 13, 2017 at 05:13:38PM -0600, Jonathan Corbet wrote: > On Wed, 8 Mar 2017 21:50:31 +0200 > Baruch Siach wrote: > > Since commit f9b6b0ef603 ("selftests: move vDSO tests from > > Documentation/vDSO") > > parse_vdso.c moved under selftests. Update the reference to

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

On 14/03/17 22:22, Stefano Stabellini wrote: > Hi Juergen, > > thank you for the review! > > On Tue, 14 Mar 2017, Juergen Gross wrote: >> On 14/03/17 00:50, Stefano Stabellini wrote: >>> Implement functions to handle the xenbus handshake. Upon connection, >>> allocate the rings according to the

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

On 14/03/17 22:22, Stefano Stabellini wrote: > Hi Juergen, > > thank you for the review! > > On Tue, 14 Mar 2017, Juergen Gross wrote: >> On 14/03/17 00:50, Stefano Stabellini wrote: >>> Implement functions to handle the xenbus handshake. Upon connection, >>> allocate the rings according to the

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

Thanks. I will rewrite patch according to the suggestions. On Tue, Mar 14, 2017 at 9:52 PM, Greg Kroah-Hartman wrote: > On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote: >> Description: > > No need for that line. > >> in file

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

Thanks. I will rewrite patch according to the suggestions. On Tue, Mar 14, 2017 at 9:52 PM, Greg Kroah-Hartman wrote: > On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote: >> Description: > > No need for that line. > >> in file

Re: net/sctp: recursive locking in sctp_do_peeloff

On Fri, Mar 10, 2017 at 12:04 PM, Dmitry Vyukov wrote: > On Fri, Mar 10, 2017 at 8:46 PM, Marcelo Ricardo Leitner > wrote: >> On Fri, Mar 10, 2017 at 4:11 PM, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following

Re: net/sctp: recursive locking in sctp_do_peeloff

On Fri, Mar 10, 2017 at 12:04 PM, Dmitry Vyukov wrote: > On Fri, Mar 10, 2017 at 8:46 PM, Marcelo Ricardo Leitner > wrote: >> On Fri, Mar 10, 2017 at 4:11 PM, Dmitry Vyukov wrote: >>> Hello, >>> >>> I've got the following recursive locking report while running >>> syzkaller fuzzer on

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote: > Description: No need for that line. > in file 'vc04_services/interface/vchiq_arm/vchiq_shim.c', making changes > to make code according to 'checkpath.pl'. Why indent? Also, you need to be specific as to what type of

Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR

[CC += linux-...@vger.kernel.org] Filip, Since this is a kernel-user-space API change, please CC linux-api@ (and on future iterations of this patch). The kernel source file Documentation/SubmitChecklist notes that all Linux kernel patches that change userspace interfaces should be CCed to

Re: [PATCH] vc04_services: Fixing coding and logical guidelines

On Tue, Mar 14, 2017 at 06:39:04PM +0530, Pushkar Jambhlekar wrote: > Description: No need for that line. > in file 'vc04_services/interface/vchiq_arm/vchiq_shim.c', making changes > to make code according to 'checkpath.pl'. Why indent? Also, you need to be specific as to what type of

Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR

[CC += linux-...@vger.kernel.org] Filip, Since this is a kernel-user-space API change, please CC linux-api@ (and on future iterations of this patch). The kernel source file Documentation/SubmitChecklist notes that all Linux kernel patches that change userspace interfaces should be CCed to

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Merged. Thanks, Inki Dae 2017년 03월 15일 03:38에 Krzysztof Kozlowski 이(가) 쓴 글: > Printing raw kernel pointers might reveal information which sometimes we > try to hide (e.g. with Kernel Address Space Layout Randomization). Use > the "%pK" format so these pointers will be hidden for unprivileged >

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

Merged. Thanks, Inki Dae 2017년 03월 15일 03:38에 Krzysztof Kozlowski 이(가) 쓴 글: > Printing raw kernel pointers might reveal information which sometimes we > try to hide (e.g. with Kernel Address Space Layout Randomization). Use > the "%pK" format so these pointers will be hidden for unprivileged >

[PATCH v2 02/17] iio: mlx96014: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 02/17] iio: mlx96014: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 06/17] iio: light: tsl2563: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 03/17] iio: magnetometer: bmc150_magn_i2c: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 06/17] iio: light: tsl2563: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 03/17] iio: magnetometer: bmc150_magn_i2c: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 08/17] iio: imu: inv_mpu6050: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 08/17] iio: imu: inv_mpu6050: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 07/17] iio: pressure: hp03: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 07/17] iio: pressure: hp03: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 14/17] iio: accel: mma7455_i2c: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 17/17] iio: gyro: itg3200: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 16/17] iio: accel: mma7660: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 14/17] iio: accel: mma7455_i2c: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 17/17] iio: gyro: itg3200: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 16/17] iio: accel: mma7660: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 10/17] iio: light: apds9960: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 10/17] iio: light: apds9960: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 13/17] iio: magnetometer: mag3110: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 11/17] iio: dac: max5821: Set .of_match_table to OF device ID table

The driver has a OF device ID table but the struct i2c_driver .of_match_table field is not set. Signed-off-by: Javier Martinez Canillas --- drivers/iio/dac/max5821.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/dac/max5821.c

[PATCH v2 12/17] iio: adc: ti-ads1015: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 09/17] iio: accel: bma180: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 15/17] iio: pressure: mpl3115: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 13/17] iio: magnetometer: mag3110: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 11/17] iio: dac: max5821: Set .of_match_table to OF device ID table

The driver has a OF device ID table but the struct i2c_driver .of_match_table field is not set. Signed-off-by: Javier Martinez Canillas --- drivers/iio/dac/max5821.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/dac/max5821.c b/drivers/iio/dac/max5821.c index

[PATCH v2 12/17] iio: adc: ti-ads1015: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 09/17] iio: accel: bma180: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 15/17] iio: pressure: mpl3115: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 00/17] iio: Add OF device table to I2C drivers that are missing it

Hello, This series add OF device ID tables to IIO I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a

[PATCH v2 00/17] iio: Add OF device table to I2C drivers that are missing it

Hello, This series add OF device ID tables to IIO I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a

[PATCH v2 04/17] iio: dac: mcp4725: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 05/17] iio: light: us5182d: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 05/17] iio: light: us5182d: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 04/17] iio: dac: mcp4725: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 01/17] iio: adc: ina2xx: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v2 01/17] iio: adc: ina2xx: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

Hi Wolfgang, On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger wrote: ...snip >> /disconnect cable >> can0 2088 [8] 00 00 00 19 00 00 28 00 ERRORFRAME >> protocol-violation{{}{acknowledge-slot}} >> bus-error >>

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

Hi Wolfgang, On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger wrote: ...snip >> /disconnect cable >> can0 2088 [8] 00 00 00 19 00 00 28 00 ERRORFRAME >> protocol-violation{{}{acknowledge-slot}} >> bus-error >> error-counter-tx-rx{{40}{0}} >>

Re: [PATCH v3 2/5] thermal: add trace events to the power allocator governor

Hi Javi, Sorry for picking up an old thread, but i had a question for you. On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino wrote: > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > @@ -588,12 +590,20 @@ static int cpufreq_get_requested_power(struct

Re: [PATCH v3 2/5] thermal: add trace events to the power allocator governor

Hi Javi, Sorry for picking up an old thread, but i had a question for you. On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino wrote: > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > @@ -588,12 +590,20 @@ static int cpufreq_get_requested_power(struct >

Re: [PATCH 1/2] mm: Change generic FALLBACK zonelist creation process

On 03/14/2017 06:33 AM, Anshuman Khandual wrote: On 03/08/2017 04:37 PM, John Hubbard wrote: [...] There was a discussion, on an earlier version of this patchset, in which someone pointed out that a slight over-allocation on a device that has much more memory than the CPU has, could use up

Re: [PATCH 1/2] mm: Change generic FALLBACK zonelist creation process

On 03/14/2017 06:33 AM, Anshuman Khandual wrote: On 03/08/2017 04:37 PM, John Hubbard wrote: [...] There was a discussion, on an earlier version of this patchset, in which someone pointed out that a slight over-allocation on a device that has much more memory than the CPU has, could use up

Re: [PATCH V7 0/7] LPC: legacy ISA I/O support

Hi, Arnd, Many thanks for your review! On 2017/3/14 16:39, Arnd Bergmann wrote: > On Mon, Mar 13, 2017 at 3:42 AM, zhichang.yuan > wrote: >> This patchset supports the IPMI-bt device attached to the Low-Pin-Count >> interface implemented on Hisilicon Hip06/Hip07 SoC.

Re: [PATCH V7 0/7] LPC: legacy ISA I/O support

Hi, Arnd, Many thanks for your review! On 2017/3/14 16:39, Arnd Bergmann wrote: > On Mon, Mar 13, 2017 at 3:42 AM, zhichang.yuan > wrote: >> This patchset supports the IPMI-bt device attached to the Low-Pin-Count >> interface implemented on Hisilicon Hip06/Hip07 SoC. >>

Re: [PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

Hi mshan, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] Fixed a minor coding style warning. Arguments in the macros should be coverd in brackets to aviod any precedence issues.

Hi mshan, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] drivers/staging/goldfish/goldfish_nand.c: Fixed Coding style Warnings.

Embedded function names are less appropriate to use when refactoring, can cause function renaming. Prefer the use of "%s", __func__ to embedded function names Signed-off-by: mshan --- drivers/staging/goldfish/goldfish_nand.c | 16 1 file changed, 8

[PATCH] drivers/staging/goldfish/goldfish_nand.c: Fixed Coding style Warnings.

Embedded function names are less appropriate to use when refactoring, can cause function renaming. Prefer the use of "%s", __func__ to embedded function names Signed-off-by: mshan --- drivers/staging/goldfish/goldfish_nand.c | 16 1 file changed, 8 insertions(+), 8

  1   2   3   4   5   6   7   8   9   10   >