[PATCH 1/4] ALSA: Replace timespec with timespec64

From: Baolin Wang Since timespec is not year 2038 safe on 32bit system, and we need to convert all timespec variables to timespec64 type for sound subsystem. This patch is used to do preparation for following patches, that will convert all structures defined in

[PATCH 4/4] ALSA: Deprecate CLOCK_REALTIME timestamps

The kernel has supported monotonic timestamps since linux-2.6.25, but it still defaults to CLOCK_REALTIME, which has multiple problems: It skips backwards for every leap second, it may skip at any time from settimeofday() or NTP updates, and it overflows in year 2038. alsa-lib already tries to

[PATCH 1/4] ALSA: Replace timespec with timespec64

From: Baolin Wang Since timespec is not year 2038 safe on 32bit system, and we need to convert all timespec variables to timespec64 type for sound subsystem. This patch is used to do preparation for following patches, that will convert all structures defined in uapi/sound/asound.h to use 64-bit

[PATCH 4/4] ALSA: Deprecate CLOCK_REALTIME timestamps

The kernel has supported monotonic timestamps since linux-2.6.25, but it still defaults to CLOCK_REALTIME, which has multiple problems: It skips backwards for every leap second, it may skip at any time from settimeofday() or NTP updates, and it overflows in year 2038. alsa-lib already tries to

[PATCH 0/4] ALSA: Fix year 2038 issue for sound subsystem, alternative

I've tried the suggestion from Jaroslaw, doing a minimal change to the UAPI headers to keep the existing binary interface. As he predicted, this is a much simpler set of kernel changes, but we will pay for that with added complexity in alsa-lib. The first two patches in this series are taken from

[PATCH 0/4] ALSA: Fix year 2038 issue for sound subsystem, alternative

I've tried the suggestion from Jaroslaw, doing a minimal change to the UAPI headers to keep the existing binary interface. As he predicted, this is a much simpler set of kernel changes, but we will pay for that with added complexity in alsa-lib. The first two patches in this series are taken from

Re: 4.17-rc2: Could not determine valid watermarks for inherited state

Cc: Maarten, Ville On Mon, 23 Apr 2018, Dave Jones wrote: > This warning just started appearing during boot on a machine I upgraded > to 4.17-rc2. The warning seems to have been there since 2015, but it > has never triggered before today. > > Dave > > [

Re: 4.17-rc2: Could not determine valid watermarks for inherited state

Cc: Maarten, Ville On Mon, 23 Apr 2018, Dave Jones wrote: > This warning just started appearing during boot on a machine I upgraded > to 4.17-rc2. The warning seems to have been there since 2015, but it > has never triggered before today. > > Dave > > [1.158500] fb: switching to

Re: issues with suspend on Dell XPS 13 2-in-1

Hi Srinivas, El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas escribió: > Hi Dennis, > > On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote: > > Hi Srinivas, > > > > Yes I have latest bios, I have version 1.3.1 that was released on > > 18th > > of Feb. > > Can you try these

Re: issues with suspend on Dell XPS 13 2-in-1

Hi Srinivas, El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas escribió: > Hi Dennis, > > On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote: > > Hi Srinivas, > > > > Yes I have latest bios, I have version 1.3.1 that was released on > > 18th > > of Feb. > > Can you try these

Re: [PATCH] net: phy: marvell: clear wol event before setting it

> hmm, so you want a "stick" WOL feature, I dunno whether Linux kernel > requires WOL should be "stick". I see two different cases: Suspend/resume: The WoL state in the kernel is probably kept across such a cycle. If so, you would expect another suspend/resume to also work, without needs to

Re: [PATCH] net: phy: marvell: clear wol event before setting it

> hmm, so you want a "stick" WOL feature, I dunno whether Linux kernel > requires WOL should be "stick". I see two different cases: Suspend/resume: The WoL state in the kernel is probably kept across such a cycle. If so, you would expect another suspend/resume to also work, without needs to

Re: [PATCH v4 2/2] media: Add a driver for the ov7251 camera sensor

On 26.04.2018 15:04, Sakari Ailus wrote: > On Thu, Apr 26, 2018 at 10:16:56AM +0300, Sakari Ailus wrote: >> On Thu, Apr 26, 2018 at 10:04:25AM +0300, Todor Tomov wrote: >>> Hi Sakari, >>> >>> On 26.04.2018 09:50, Sakari Ailus wrote: Hi Todor, On Wed, Apr 25, 2018 at 07:20:46PM

Re: [PATCH v4 2/2] media: Add a driver for the ov7251 camera sensor

On 26.04.2018 15:04, Sakari Ailus wrote: > On Thu, Apr 26, 2018 at 10:16:56AM +0300, Sakari Ailus wrote: >> On Thu, Apr 26, 2018 at 10:04:25AM +0300, Todor Tomov wrote: >>> Hi Sakari, >>> >>> On 26.04.2018 09:50, Sakari Ailus wrote: Hi Todor, On Wed, Apr 25, 2018 at 07:20:46PM

Re: make TAGS broken with commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources()...")

On Thu, 26 Apr 2018, Sebastian Ott wrote: > on my s390 test system make TAGS is broken since commit 99443f811c452c6 > ("scripts/tags.sh: change find_other_sources() for include directories") > > # make TAGS > GEN TAGS > xargs: etags: terminated by signal 11 > > This is a rather old etags

Re: make TAGS broken with commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources()...")

On Thu, 26 Apr 2018, Sebastian Ott wrote: > on my s390 test system make TAGS is broken since commit 99443f811c452c6 > ("scripts/tags.sh: change find_other_sources() for include directories") > > # make TAGS > GEN TAGS > xargs: etags: terminated by signal 11 > > This is a rather old etags

Re: [PATCH] hid: intel-ish-hid: use put_device() instead of kfree()

On Fri, 30 Mar 2018, Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error. Always use put_device() to give up the > reference initialized. > > Signed-off-by: Arvind Yadav Applied, thank you. -- Jiri Kosina

Re: [PATCH] hid: intel-ish-hid: use put_device() instead of kfree()

On Fri, 30 Mar 2018, Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error. Always use put_device() to give up the > reference initialized. > > Signed-off-by: Arvind Yadav Applied, thank you. -- Jiri Kosina SUSE Labs

[PATCH] ath10k: sdio: jump to correct label in error handling path

Jump to the correct label in error handling path. At this point of execution create_singlethread_workqueue() has succeeded, so it should be properly destroyed. Jump label was renamed in commit ec2c64e20257 ("ath10k: sdio: fix memory leak for probe allocations"). However, the bug was originally

[PATCH] ath10k: sdio: jump to correct label in error handling path

Jump to the correct label in error handling path. At this point of execution create_singlethread_workqueue() has succeeded, so it should be properly destroyed. Jump label was renamed in commit ec2c64e20257 ("ath10k: sdio: fix memory leak for probe allocations"). However, the bug was originally

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote: > It's been a while since we introduced drm_dev{get/put} functions > to replace reference/unreference in drm subsystem for the > consistency purpose. So, with this patch, let's just replace > all current use cases of drm_dev_unref()

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote: > It's been a while since we introduced drm_dev{get/put} functions > to replace reference/unreference in drm subsystem for the > consistency purpose. So, with this patch, let's just replace > all current use cases of drm_dev_unref()

Re: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next_owner()

Hi Kirill, On Thu, Apr 26, 2018 at 02:01:07PM +0300, Kirill Tkhai wrote: > The patch finalizes the series and makes mm_update_next_owner() > to iterate over task list using RCU instead of tasklist_lock. > This is possible because of rules of inheritance of mm: it may be > propagated to a child

Re: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next_owner()

Hi Kirill, On Thu, Apr 26, 2018 at 02:01:07PM +0300, Kirill Tkhai wrote: > The patch finalizes the series and makes mm_update_next_owner() > to iterate over task list using RCU instead of tasklist_lock. > This is possible because of rules of inheritance of mm: it may be > propagated to a child

Re: [PATCH 0/4] HID: alps: Fix some bugs and improve code around 't4_read_write_register()'

On Mon, 19 Mar 2018, Christophe JAILLET wrote: > All is said in the subject and below. > > These patches are untested. Especially, patch 1 slightly changes the behavior > of 't4_read_write_register()'. > This looks logical to me, but please, review it carefully. > > Christophe JAILLET (4): >

Re: [PATCH 0/4] HID: alps: Fix some bugs and improve code around 't4_read_write_register()'

On Mon, 19 Mar 2018, Christophe JAILLET wrote: > All is said in the subject and below. > > These patches are untested. Especially, patch 1 slightly changes the behavior > of 't4_read_write_register()'. > This looks logical to me, but please, review it carefully. > > Christophe JAILLET (4): >

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25/2018 08:01 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: On 04/25/2018 01:17 PM, Oleg Nesterov wrote: On 04/25, Andrey Grodzovsky wrote: here (drm_sched_entity_fini) is also a bad idea, but we still want to be able to exit immediately and not

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25/2018 08:01 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: On 04/25/2018 01:17 PM, Oleg Nesterov wrote: On 04/25, Andrey Grodzovsky wrote: here (drm_sched_entity_fini) is also a bad idea, but we still want to be able to exit immediately and not wait for GPU jobs completion

Re: [PATCH v2] i2c: at91: Read all available bytes at once

On Thu, Apr 26, 2018 at 11:53:14AM +0200, David Engraf wrote: > With FIFO enabled it is possible to read multiple bytes > at once in the interrupt handler as long as RXRDY is > set. This may also reduce the number of interrupts. > > This patch polls RXRDY and reads all available bytes at > once.

Re: [PATCH v2] i2c: at91: Read all available bytes at once

On Thu, Apr 26, 2018 at 11:53:14AM +0200, David Engraf wrote: > With FIFO enabled it is possible to read multiple bytes > at once in the interrupt handler as long as RXRDY is > set. This may also reduce the number of interrupts. > > This patch polls RXRDY and reads all available bytes at > once.

Re: [PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

On 04/25/2018 04:55 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: On 04/24/2018 12:30 PM, Eric W. Biederman wrote: "Panariti, David" writes: Andrey Grodzovsky writes: Kind of

Re: [PATCH 3/3] drm/amdgpu: Switch to interrupted wait to recover from ring hang.

On 04/25/2018 04:55 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: On 04/24/2018 12:30 PM, Eric W. Biederman wrote: "Panariti, David" writes: Andrey Grodzovsky writes: Kind of dma_fence_wait_killable, except that we don't have such API (maybe worth adding ?) Depends on how

Re: [RFC v2 1/2] virtio: add pmem driver

Dan Williams writes: > [ adding Jeff directly since he has also been looking at > infrastructure to track when MAP_SYNC should be disabled ] > > On Wed, Apr 25, 2018 at 7:21 AM, Dan Williams > wrote: >> On Wed, Apr 25, 2018 at 4:24 AM, Pankaj

Re: [RFC v2 1/2] virtio: add pmem driver

Dan Williams writes: > [ adding Jeff directly since he has also been looking at > infrastructure to track when MAP_SYNC should be disabled ] > > On Wed, Apr 25, 2018 at 7:21 AM, Dan Williams > wrote: >> On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote: >>> This patch adds virtio-pmem

Re: [PATCH v5 3/3] pinctrl: bcm2835: Add support for output-low output-high properties

On Wed, Apr 11, 2018 at 6:58 AM, Matheus Castello wrote: > Properties to set initial value of pin output buffer. > This can be useful for configure hardware in overlay files, and in early boot > for checking it states in QA sanity tests. > > Signed-off-by: Matheus

Re: [PATCH v5 3/3] pinctrl: bcm2835: Add support for output-low output-high properties

On Wed, Apr 11, 2018 at 6:58 AM, Matheus Castello wrote: > Properties to set initial value of pin output buffer. > This can be useful for configure hardware in overlay files, and in early boot > for checking it states in QA sanity tests. > > Signed-off-by: Matheus Castello Will apply this when

Re: [PATCH v5 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding

On Wed, Apr 11, 2018 at 6:58 AM, Matheus Castello wrote: > To keep driver up to date we add generic pinctrl binding support, which covers > the features used in this driver and has additional node properties that this > SoC has compatibility, so enabling future

Re: [PATCH v5 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding

On Wed, Apr 11, 2018 at 6:58 AM, Matheus Castello wrote: > To keep driver up to date we add generic pinctrl binding support, which covers > the features used in this driver and has additional node properties that this > SoC has compatibility, so enabling future implementations of these

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

- Original Message - > From: "Michal Hocko" > To: "Chunyu Hu" > Cc: "Chunyu Hu" , "Dmitry Vyukov" > , "Catalin Marinas" > , "LKML" , "Linux-MM" >

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

- Original Message - > From: "Michal Hocko" > To: "Chunyu Hu" > Cc: "Chunyu Hu" , "Dmitry Vyukov" > , "Catalin Marinas" > , "LKML" , "Linux-MM" > > Sent: Wednesday, April 25, 2018 1:02:39 AM > Subject: Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in >

Re: [PATCH v5 1/3] dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support

On Wed, Apr 11, 2018 at 6:58 AM, Matheus Castello wrote: > Added generic pin configuration and multiplexing support, > and should be preferred than brcm legacy one. > > Signed-off-by: Matheus Castello Patch applied with Eric's and Rob's ACKs.

Re: [PATCH v5 1/3] dt-bindings: pinctrl: bcm2835-gpio: Add generic pinctrl support

On Wed, Apr 11, 2018 at 6:58 AM, Matheus Castello wrote: > Added generic pin configuration and multiplexing support, > and should be preferred than brcm legacy one. > > Signed-off-by: Matheus Castello Patch applied with Eric's and Rob's ACKs. Yours, Linus Walleij

Re: [PATCH v2 0/6] HID: input cleanups and mt additions

On Tue, 24 Apr 2018, Benjamin Tissoires wrote: > following the thread about the 'not incrementing ABS_MISC', here is the > actual submission of the series. Thanks Benjamin, this looks nice. I've queued it for 4.18. -- Jiri Kosina SUSE Labs

Re: [PATCH v2 0/6] HID: input cleanups and mt additions

On Tue, 24 Apr 2018, Benjamin Tissoires wrote: > following the thread about the 'not incrementing ABS_MISC', here is the > actual submission of the series. Thanks Benjamin, this looks nice. I've queued it for 4.18. -- Jiri Kosina SUSE Labs

Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs

On Mon, 16 Apr 2018, Kirill A. Shutemov wrote: > > > > Commits 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time") and > > > > a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time") lost > > > > the > > > > type information for __VMALLOC_BASE_L4, __VMALLOC_BASE_L5, > > > >

Re: [PATCH] drm/core: Remove drm_dev_unref() and it's uses

On Thu, 26 Apr 2018 15:58:19 +0530 Vaishali Thakkar wrote: > It's been a while since we introduced drm_dev{get/put} functions > to replace reference/unreference in drm subsystem for the > consistency purpose. So, with this patch, let's just replace > all current use cases

Re: [PATCH] x86/mm: vmemmap and vmalloc base addressess are usngined longs

On Mon, 16 Apr 2018, Kirill A. Shutemov wrote: > > > > Commits 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time") and > > > > a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time") lost > > > > the > > > > type information for __VMALLOC_BASE_L4, __VMALLOC_BASE_L5, > > > >

Re: [PATCH] drm/core: Remove drm_dev_unref() and it's uses

On Thu, 26 Apr 2018 15:58:19 +0530 Vaishali Thakkar wrote: > It's been a while since we introduced drm_dev{get/put} functions > to replace reference/unreference in drm subsystem for the > consistency purpose. So, with this patch, let's just replace > all current use cases of drm_dev_unref() with

drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

Hi Mario, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 69bfd470f4623d2d57ad62cb33791cded0c662f4 commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: Link all dell-smbios-* modules together

drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

Hi Mario, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 69bfd470f4623d2d57ad62cb33791cded0c662f4 commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: Link all dell-smbios-* modules together

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Thu, Apr 12, 2018 at 10:00 PM, Christian Lamparter wrote: > The problem is that unlike native gpio-controllers, pinctrls need > to have a "pin/gpio range" defined before any gpio-hogs can be added. Indeed. But the primary use case (correct me if I am wrong Bartosz) is to

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Thu, Apr 12, 2018 at 10:00 PM, Christian Lamparter wrote: > The problem is that unlike native gpio-controllers, pinctrls need > to have a "pin/gpio range" defined before any gpio-hogs can be added. Indeed. But the primary use case (correct me if I am wrong Bartosz) is to clean up old

Re: [PATCH 8/8] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control

] > > [cannot apply to sound/for-next asoc/for-next arm-soc/for-next > > next-20180426] > > [if your patch is applied to the wrong git tree, please drop us a note to > > help improve the system] > > > > url: > > https://github.com/0day-ci/linux/commi

Re: [PATCH 8/8] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control

ly to sound/for-next asoc/for-next arm-soc/for-next > > next-20180426] > > [if your patch is applied to the wrong git tree, please drop us a note to > > help improve the system] > > > > url: > > https://github.com/0day-ci/linux/commits/Baolin-Wang/Fix-year-2

[PATCH v4 2/5] efi: Add embedded peripheral firmware support

Just like with PCI options ROMs, which we save in the setup_efi_pci* functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself sometimes may contain data which is useful/necessary for peripheral drivers to have access to. Specifically the EFI code may contain an embedded copy of

[PATCH v4 2/5] efi: Add embedded peripheral firmware support

Just like with PCI options ROMs, which we save in the setup_efi_pci* functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself sometimes may contain data which is useful/necessary for peripheral drivers to have access to. Specifically the EFI code may contain an embedded copy of

[PATCH v4 4/5] platform/x86: touchscreen_dmi: Add EFI embedded firmware info support

Sofar we have been unable to get permission from the vendors to put the firmware for touchscreens listed in touchscreen_dmi in linux-firmware. Some of the tablets with such a touchscreen have a touchscreen driver, and thus a copy of the firmware, as part of their EFI code. This commit adds the

[PATCH v4 4/5] platform/x86: touchscreen_dmi: Add EFI embedded firmware info support

Sofar we have been unable to get permission from the vendors to put the firmware for touchscreens listed in touchscreen_dmi in linux-firmware. Some of the tablets with such a touchscreen have a touchscreen driver, and thus a copy of the firmware, as part of their EFI code. This commit adds the

[PATCH v4 5/5] platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tablet

Add touchscreen info for the Chuwi Vi8 Plus tablet. This tablet uses a Chipone ICN8505 touchscreen controller, with the firmware used by the touchscreen embedded in the EFI firmware. Acked-by: Andy Shevchenko Signed-off-by: Hans de Goede ---

[PATCH v4 5/5] platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tablet

Add touchscreen info for the Chuwi Vi8 Plus tablet. This tablet uses a Chipone ICN8505 touchscreen controller, with the firmware used by the touchscreen embedded in the EFI firmware. Acked-by: Andy Shevchenko Signed-off-by: Hans de Goede --- drivers/platform/x86/touchscreen_dmi.c | 25

[PATCH v4 1/5] efi: Export boot-services code and data as debugfs-blobs

Sometimes it is useful to be able to dump the efi boot-services code and data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, but only if efi=debug is passed on the kernel-commandline as this requires not freeing those memory-regions, which costs 20+ MB of RAM. Reviewed-by:

[PATCH v4 1/5] efi: Export boot-services code and data as debugfs-blobs

Sometimes it is useful to be able to dump the efi boot-services code and data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, but only if efi=debug is passed on the kernel-commandline as this requires not freeing those memory-regions, which costs 20+ MB of RAM. Reviewed-by:

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but there's no

[PATCH v4 3/5] platform/x86: Rename silead_dmi to touchscreen_dmi

Not only silead touchscreens need some extra info not available in the ACPI tables to work properly. X86 devices with a Chipone ICN8505 chip also need some DMI based extra configuration. There is no reason to have separate dmi config code per touchscreen controller vendor. This commit renames

[PATCH v4 3/5] platform/x86: Rename silead_dmi to touchscreen_dmi

Not only silead touchscreens need some extra info not available in the ACPI tables to work properly. X86 devices with a Chipone ICN8505 chip also need some DMI based extra configuration. There is no reason to have separate dmi config code per touchscreen controller vendor. This commit renames

Re: [PATCH] drm/core: Remove drm_dev_unref() and it's uses

On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote: > It's been a while since we introduced drm_dev{get/put} functions > to replace reference/unreference in drm subsystem for the > consistency purpose. So, with this patch, let's just replace > all current use cases of drm_dev_unref()

Re: [PATCH] drm/core: Remove drm_dev_unref() and it's uses

On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote: > It's been a while since we introduced drm_dev{get/put} functions > to replace reference/unreference in drm subsystem for the > consistency purpose. So, with this patch, let's just replace > all current use cases of drm_dev_unref()

[PATCH v4 0/5] efi/firmware/platform-x86: Add EFI embedded fw support

Hi All, Here is v4 of my patch-set to add support for EFI embedded fw to the kernel. Changes since v3: -Drop note in docs about EFI_FIRMWARE_VOLUME_PROTOCOL, it is not part of UEFI proper, so the EFI maintainers don't want us referring people to it -Use new EFI_BOOT_SERVICES flag -Put the new

[PATCH v4 0/5] efi/firmware/platform-x86: Add EFI embedded fw support

Hi All, Here is v4 of my patch-set to add support for EFI embedded fw to the kernel. Changes since v3: -Drop note in docs about EFI_FIRMWARE_VOLUME_PROTOCOL, it is not part of UEFI proper, so the EFI maintainers don't want us referring people to it -Use new EFI_BOOT_SERVICES flag -Put the new

Re: [PATCH v6 02/24] soc: qcom: Add APR bus driver

On 26/04/18 12:39, Mark Brown wrote: On Thu, Apr 26, 2018 at 10:45:44AM +0100, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This patch adds support toi APR bus (Asynchronous Packet Router) driver. ARP driver is made as a bus driver so that

net/core/dev.c:1588:2-3: Unneeded semicolon

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 69bfd470f4623d2d57ad62cb33791cded0c662f4 commit: ede2762d93ff16e0974f7446516b46b1022db213 net: Make NETDEV_XXX commands enum { } date: 4 weeks ago coccinelle warnings: (new ones prefixed by >>) >>

Re: [PATCH v6 02/24] soc: qcom: Add APR bus driver

On 26/04/18 12:39, Mark Brown wrote: On Thu, Apr 26, 2018 at 10:45:44AM +0100, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This patch adds support toi APR bus (Asynchronous Packet Router) driver. ARP driver is made as a bus driver so that the apr devices can added

net/core/dev.c:1588:2-3: Unneeded semicolon

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 69bfd470f4623d2d57ad62cb33791cded0c662f4 commit: ede2762d93ff16e0974f7446516b46b1022db213 net: Make NETDEV_XXX commands enum { } date: 4 weeks ago coccinelle warnings: (new ones prefixed by >>) >>

Re: [PATCH] connector: add parent pid and tgid to coredump and exit events

Hi David, Evgeniy, Sorry to bother you, but could you please comment about the UAPI change and the patch? Thanks, Jesper. -- Stefan On 05/04/18 12:07, Jesper Derehag wrote: > Unless David comes back with something I have (also) missed regarding uapi > breakage, this looks good to me. > >

Re: [PATCH] connector: add parent pid and tgid to coredump and exit events

Hi David, Evgeniy, Sorry to bother you, but could you please comment about the UAPI change and the patch? Thanks, Jesper. -- Stefan On 05/04/18 12:07, Jesper Derehag wrote: > Unless David comes back with something I have (also) missed regarding uapi > breakage, this looks good to me. > >

Re: [PATCH v4 2/2] media: Add a driver for the ov7251 camera sensor

On Thu, Apr 26, 2018 at 10:16:56AM +0300, Sakari Ailus wrote: > On Thu, Apr 26, 2018 at 10:04:25AM +0300, Todor Tomov wrote: > > Hi Sakari, > > > > On 26.04.2018 09:50, Sakari Ailus wrote: > > > Hi Todor, > > > > > > On Wed, Apr 25, 2018 at 07:20:46PM +0300, Todor Tomov wrote: > > > ... > > >>

Re: [PATCH v4 2/2] media: Add a driver for the ov7251 camera sensor

On Thu, Apr 26, 2018 at 10:16:56AM +0300, Sakari Ailus wrote: > On Thu, Apr 26, 2018 at 10:04:25AM +0300, Todor Tomov wrote: > > Hi Sakari, > > > > On 26.04.2018 09:50, Sakari Ailus wrote: > > > Hi Todor, > > > > > > On Wed, Apr 25, 2018 at 07:20:46PM +0300, Todor Tomov wrote: > > > ... > > >>

[PATCH 02/18] thermal: exynos: always check for trips points existence

* Check for trip points existence in exynos_tmu_initialize() so it is checked on all SoCs. * Use dev_err() instead of pr_err(). * Fix dev_err() to reference "device tree" not "of-thermal.c". * Remove no longer needed checks from exynos4210_tmu_initialize() and get_th_reg(). Signed-off-by:

[PATCH 02/18] thermal: exynos: always check for trips points existence

* Check for trip points existence in exynos_tmu_initialize() so it is checked on all SoCs. * Use dev_err() instead of pr_err(). * Fix dev_err() to reference "device tree" not "of-thermal.c". * Remove no longer needed checks from exynos4210_tmu_initialize() and get_th_reg(). Signed-off-by:

Re: [PATCH v3 5/5] pinctrl: sunxi: Use of_clk_get_parent_count() instead of open coding

On Wed, Apr 18, 2018 at 4:50 PM, Geert Uytterhoeven wrote: > A new open coder has crept in since 470b73a38470e8ba ("pinctrl: sunxi: > Use of_clk_get_parent_count() instead of open coding"), replace it. > > of_clk_get_parent_count() was moved to , so include that >

Re: [PATCH v3 5/5] pinctrl: sunxi: Use of_clk_get_parent_count() instead of open coding

On Wed, Apr 18, 2018 at 4:50 PM, Geert Uytterhoeven wrote: > A new open coder has crept in since 470b73a38470e8ba ("pinctrl: sunxi: > Use of_clk_get_parent_count() instead of open coding"), replace it. > > of_clk_get_parent_count() was moved to , so include that > instead of . > > Signed-off-by:

[PATCH 05/18] thermal: exynos: use sanitize_temp_error() in exynos7_tmu_initialize()

Fix sanitize_temp_error() to handle Exynos7 SoCs and then use it in exynos7_tmu_initialize(). There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/thermal/samsung/exynos_tmu.c | 13 ++--- 1 file

[PATCH 05/18] thermal: exynos: use sanitize_temp_error() in exynos7_tmu_initialize()

Fix sanitize_temp_error() to handle Exynos7 SoCs and then use it in exynos7_tmu_initialize(). There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/thermal/samsung/exynos_tmu.c | 13 ++--- 1 file changed, 6 insertions(+), 7

[PATCH 06/18] thermal: exynos: fix trips limit checking in get_th_reg()

of_thermal_get_ntrips() may return value bigger than supported by a given SoC (i.e. on Exynos5422/5800) so fix the code to not iterate the loop for i values >= data->ntrip. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz

[PATCH 01/18] thermal: exynos: fix setting rising_threshold for Exynos5433

Add missing clearing of the previous value when setting rising temperature threshold. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/thermal/samsung/exynos_tmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/samsung/exynos_tmu.c

[PATCH 01/18] thermal: exynos: fix setting rising_threshold for Exynos5433

Add missing clearing of the previous value when setting rising temperature threshold. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/thermal/samsung/exynos_tmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/samsung/exynos_tmu.c

[PATCH 06/18] thermal: exynos: fix trips limit checking in get_th_reg()

of_thermal_get_ntrips() may return value bigger than supported by a given SoC (i.e. on Exynos5422/5800) so fix the code to not iterate the loop for i values >= data->ntrip. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz ---

[PATCH 07/18] thermal: exynos: remove threshold_code checking from exynos4210_tmu_initialize()

On Exynos4210 one-point trimming is always used and data->temp_error1 is equal to 75. Therefore temp_to_code() will never return negative value for the reference temperature conversion. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz

Re: [PATCH v3] report correct CPU/cache topology

On Thu, 26 Apr 2018, David Wang wrote: > Centaur CPUs enumerate the cache topology in the same way as Intel CPUs, > but the function is unused so far. > The Centaur init code also misses to initialize x86_info::max_cores, so > the CPU topology can't be described correctly. > > Initialize

[PATCH 07/18] thermal: exynos: remove threshold_code checking from exynos4210_tmu_initialize()

On Exynos4210 one-point trimming is always used and data->temp_error1 is equal to 75. Therefore temp_to_code() will never return negative value for the reference temperature conversion. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz ---

Re: [PATCH v3] report correct CPU/cache topology

On Thu, 26 Apr 2018, David Wang wrote: > Centaur CPUs enumerate the cache topology in the same way as Intel CPUs, > but the function is unused so far. > The Centaur init code also misses to initialize x86_info::max_cores, so > the CPU topology can't be described correctly. > > Initialize

Re: [PATCH v2 2/5] ARM: timer-sp: Use of_clk_get_parent_count() instead of open coding

On Tue, Apr 10, 2018 at 2:51 PM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > This depends on "[PATCH v2 1/5] clk: Extract OF clock helpers in > ". > > v2: > - of_clk_get_parent_count() was moved to , > - Dropped

Re: [PATCH v2 2/5] ARM: timer-sp: Use of_clk_get_parent_count() instead of open coding

On Tue, Apr 10, 2018 at 2:51 PM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > This depends on "[PATCH v2 1/5] clk: Extract OF clock helpers in > ". > > v2: > - of_clk_get_parent_count() was moved to , > - Dropped RFC, as a dummy is now available in the

[PATCH RESEND] firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()

qcom_scm_call_atomic1() can crash with a NULL pointer dereference at qcom_scm_call_atomic1+0x30/0x48. disassembly of qcom_scm_call_atomic1(): ... <0xc08d73b0 <+12>: ldr r3, [r12] ... (no instruction explicitly modifies r12) 0xc08d73cc <+40>: smc 0 ... (no instruction explicitly modifies r12)

[PATCH RESEND] firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()

qcom_scm_call_atomic1() can crash with a NULL pointer dereference at qcom_scm_call_atomic1+0x30/0x48. disassembly of qcom_scm_call_atomic1(): ... <0xc08d73b0 <+12>: ldr r3, [r12] ... (no instruction explicitly modifies r12) 0xc08d73cc <+40>: smc 0 ... (no instruction explicitly modifies r12)

[PATCH 08/18] thermal: exynos: make ->tmu_initialize method void

All implementations of ->tmu_initialize always return 0 so make the method void and convert all implementations accordingly. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/thermal/samsung/exynos_tmu.c |

[PATCH 08/18] thermal: exynos: make ->tmu_initialize method void

All implementations of ->tmu_initialize always return 0 so make the method void and convert all implementations accordingly. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/thermal/samsung/exynos_tmu.c | 28

[PATCH 14/18] thermal: exynos: move trips setting to exynos_tmu_initialize()

* Add dummy exynos4210_tmu_set_trip_hyst() helper. * Add ->tmu_set_trip_temp and ->tmu_set_trip_hyst methods to struct exynos_tmu_data and set them in exynos_map_dt_data(). * Move trips setting to exynos_tmu_initialize(). There should be no functional changes caused by this patch.

[PATCH 14/18] thermal: exynos: move trips setting to exynos_tmu_initialize()

* Add dummy exynos4210_tmu_set_trip_hyst() helper. * Add ->tmu_set_trip_temp and ->tmu_set_trip_hyst methods to struct exynos_tmu_data and set them in exynos_map_dt_data(). * Move trips setting to exynos_tmu_initialize(). There should be no functional changes caused by this patch.

<    11   12   13   14   15   16   17   18   19   20   >