Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Wed, Oct 04, 2017 at 10:34:30AM +0200, Peter Zijlstra wrote: > Right, and print_circular_bug() uses @trace before it ever can be set, > although I suspect the intention is that that only ever gets called from > commit_xhlock() where we pass in an initialized @trace. A comment > would've been

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Wed, Oct 04, 2017 at 10:34:30AM +0200, Peter Zijlstra wrote: > Right, and print_circular_bug() uses @trace before it ever can be set, > although I suspect the intention is that that only ever gets called from > commit_xhlock() where we pass in an initialized @trace. A comment > would've been

Re: [PATCH v3] mm, sysctl: make NUMA stats configurable

On 2017年10月10日 13:49, Michal Hocko wrote: > On Mon 09-10-17 09:55:49, Michal Hocko wrote: >> I haven't checked closely but what happens (or should happen) when you >> do a partial read? Should you get an inconsistent results? Or is this >> impossible? > > Well, after thinking about it little

Re: [PATCH v3] mm, sysctl: make NUMA stats configurable

On 2017年10月10日 13:49, Michal Hocko wrote: > On Mon 09-10-17 09:55:49, Michal Hocko wrote: >> I haven't checked closely but what happens (or should happen) when you >> do a partial read? Should you get an inconsistent results? Or is this >> impossible? > > Well, after thinking about it little

Re: [PATCH v2 15/18] powerpc: Emulate paste instruction

Michael Neuling writes: > @ -1924,6 +1987,7 @@ struct ppc_emulated ppc_emulated = { >>  WARN_EMULATED_SETUP(mfdscr), >>  WARN_EMULATED_SETUP(mtdscr), >>  WARN_EMULATED_SETUP(lq_stq), >> +WARN_EMULATED_SETUP(paste), > > You'll need to rebase this on powerpc/next

Re: [PATCH v2 15/18] powerpc: Emulate paste instruction

Michael Neuling writes: > @ -1924,6 +1987,7 @@ struct ppc_emulated ppc_emulated = { >>  WARN_EMULATED_SETUP(mfdscr), >>  WARN_EMULATED_SETUP(mtdscr), >>  WARN_EMULATED_SETUP(lq_stq), >> +WARN_EMULATED_SETUP(paste), > > You'll need to rebase this on powerpc/next as this has

Re: [RFC] a question about mlockall() and mprotect()

On Tue 10-10-17 09:22:20, Xishi Qiu wrote: > On 2017/10/10 2:26, Michal Hocko wrote: > > > On Wed 27-09-17 13:51:09, Xishi Qiu wrote: > >> On 2017/9/26 19:00, Michal Hocko wrote: > >> > >>> On Tue 26-09-17 11:45:16, Vlastimil Babka wrote: > On 09/26/2017 11:22 AM, Xishi Qiu wrote: > > On

Re: [RFC] a question about mlockall() and mprotect()

On Tue 10-10-17 09:22:20, Xishi Qiu wrote: > On 2017/10/10 2:26, Michal Hocko wrote: > > > On Wed 27-09-17 13:51:09, Xishi Qiu wrote: > >> On 2017/9/26 19:00, Michal Hocko wrote: > >> > >>> On Tue 26-09-17 11:45:16, Vlastimil Babka wrote: > On 09/26/2017 11:22 AM, Xishi Qiu wrote: > > On

Re: [PATCH v3] mm, sysctl: make NUMA stats configurable

On Mon 09-10-17 09:55:49, Michal Hocko wrote: > I haven't checked closely but what happens (or should happen) when you > do a partial read? Should you get an inconsistent results? Or is this > impossible? Well, after thinking about it little bit more, partial reads are always inconsistent so this

Re: [PATCH v3] mm, sysctl: make NUMA stats configurable

On Mon 09-10-17 09:55:49, Michal Hocko wrote: > I haven't checked closely but what happens (or should happen) when you > do a partial read? Should you get an inconsistent results? Or is this > impossible? Well, after thinking about it little bit more, partial reads are always inconsistent so this

[PATCH v2 2/2] ARM: cpuidle: Refactor rollback operations if init fails

If init fails, we need execute two levels rollback operations: the first level is for the failed CPU rollback operations, the second level is to iterate all succeeded CPUs to cancel their registration; currently the code uses one function to finish these two levels rollback operations. This

[PATCH v2 2/2] ARM: cpuidle: Refactor rollback operations if init fails

If init fails, we need execute two levels rollback operations: the first level is for the failed CPU rollback operations, the second level is to iterate all succeeded CPUs to cancel their registration; currently the code uses one function to finish these two levels rollback operations. This

[PATCH v2 1/2] ARM: cpuidle: Correct driver unregistration if init fails

If cpuidle init fails, the code misses to unregister the driver for current CPU. Furthermore, we also need to rollback to cancel all previous CPUs registration; but the code retrieves driver handler by using function cpuidle_get_driver(), this function returns back current CPU driver handler but

[PATCH v2 1/2] ARM: cpuidle: Correct driver unregistration if init fails

If cpuidle init fails, the code misses to unregister the driver for current CPU. Furthermore, we also need to rollback to cancel all previous CPUs registration; but the code retrieves driver handler by using function cpuidle_get_driver(), this function returns back current CPU driver handler but

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Tue, Oct 03, 2017 at 09:57:02AM -0700, Linus Torvalds wrote: > On Tue, Oct 3, 2017 at 9:54 AM, Linus Torvalds > wrote: > > > > Can we consider just reverting the crossrelease thing? > > > > The apparent stack corruption really worries me [...] > > Side note: I

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Tue, Oct 03, 2017 at 09:57:02AM -0700, Linus Torvalds wrote: > On Tue, Oct 3, 2017 at 9:54 AM, Linus Torvalds > wrote: > > > > Can we consider just reverting the crossrelease thing? > > > > The apparent stack corruption really worries me [...] > > Side note: I also think the thing is just

Re: Which came first, hard kernel lockup or SATA errors?

On Fri, Oct 6, 2017 at 6:25 PM, Ed Swierk wrote: > I'm trying to untangle a series of problems that suddenly occurred on > a dual-socket Xeon server system that had been running a bunch of KVM > workloads just fine for over 6 weeks (4.4.52-grsec kernel, >

Re: Which came first, hard kernel lockup or SATA errors?

On Fri, Oct 6, 2017 at 6:25 PM, Ed Swierk wrote: > I'm trying to untangle a series of problems that suddenly occurred on > a dual-socket Xeon server system that had been running a bunch of KVM > workloads just fine for over 6 weeks (4.4.52-grsec kernel, > Debian-derived userspace). I think I've

Re: [PATCH v2] mm/page_alloc.c: inline __rmqueue()

On Mon, Oct 09, 2017 at 10:19:52PM -0700, Dave Hansen wrote: > On 10/09/2017 07:56 PM, Aaron Lu wrote: > > This patch adds inline to __rmqueue() and vmlinux' size doesn't have any > > change after this patch according to size(1). > > > > without this patch: > >textdata bss dec

Re: [PATCH v2] mm/page_alloc.c: inline __rmqueue()

On Mon, Oct 09, 2017 at 10:19:52PM -0700, Dave Hansen wrote: > On 10/09/2017 07:56 PM, Aaron Lu wrote: > > This patch adds inline to __rmqueue() and vmlinux' size doesn't have any > > change after this patch according to size(1). > > > > without this patch: > >textdata bss dec

[RFC][PATCH 2/3] of: overlay_mgr: Add ability to apply through sysfs entry

From: Dmitry Shmidt Allow pre-defined overlay_mgr DT fragments to be enabled on the fly by writing to: /sys/devices/platform/overlay_mgr/current_overlay Cc: Rob Herring Cc: Mark Rutland Cc: Frank Rowand

[RFC][PATCH 2/3] of: overlay_mgr: Add ability to apply through sysfs entry

From: Dmitry Shmidt Allow pre-defined overlay_mgr DT fragments to be enabled on the fly by writing to: /sys/devices/platform/overlay_mgr/current_overlay Cc: Rob Herring Cc: Mark Rutland Cc: Frank Rowand Cc: Dmitry Shmidt Cc: devicet...@vger.kernel.org Signed-off-by: Dmitry Shmidt

[RFC][PATCH 1/3] of: overlay_mgr: Add overlay manager driver

From: Dmitry Shmidt This patch adds a driver to manage applying pre-defined DT overlay fragments at bootup. The pre-defined DT fragments are specified via the main overlay_mng entry which includes all the possible HW config setups. Then kernel command line option is used

[RFC][PATCH 3/3] of: overlay_mgr: Add ability to apply several hardware configurations

From: Dmitry Shmidt This adds the ability to specify multiple DT overlay configurations, which are predefined in the overlay_mgr entry, at once via the boot arguments. Example: overlay_mgr.overlay_dt_entry=hardware_cfg_0,hardware_cfg_1,... Cc: Rob Herring

[RFC][PATCH 1/3] of: overlay_mgr: Add overlay manager driver

From: Dmitry Shmidt This patch adds a driver to manage applying pre-defined DT overlay fragments at bootup. The pre-defined DT fragments are specified via the main overlay_mng entry which includes all the possible HW config setups. Then kernel command line option is used to choose between

[RFC][PATCH 3/3] of: overlay_mgr: Add ability to apply several hardware configurations

From: Dmitry Shmidt This adds the ability to specify multiple DT overlay configurations, which are predefined in the overlay_mgr entry, at once via the boot arguments. Example: overlay_mgr.overlay_dt_entry=hardware_cfg_0,hardware_cfg_1,... Cc: Rob Herring Cc: Mark Rutland Cc: Frank Rowand

Re: [PATCH v7 1/6] lib/dlock-list: Distributed and lock-protected lists

On Thu, Oct 05, 2017 at 06:43:23PM +, Waiman Long wrote: [...] > +/* > + * As all the locks in the dlock list are dynamically allocated, they need > + * to belong to their own special lock class to avoid warning and stack > + * trace in kernel log when lockdep is enabled. Statically allocated

[RFC][PATCH 0/3] Overlay manager for predefined DT overlay fragments

In working with the HiKey and HiKey960 as targets for AOSP, Dmitry developed the following overlay manager driver, which allows a number of pre-determined DT overlay configurations to be defined, and the configurations to be enabled at boot time via a kernel boot argument. This has been submitted

Re: [PATCH v7 1/6] lib/dlock-list: Distributed and lock-protected lists

On Thu, Oct 05, 2017 at 06:43:23PM +, Waiman Long wrote: [...] > +/* > + * As all the locks in the dlock list are dynamically allocated, they need > + * to belong to their own special lock class to avoid warning and stack > + * trace in kernel log when lockdep is enabled. Statically allocated

[RFC][PATCH 0/3] Overlay manager for predefined DT overlay fragments

In working with the HiKey and HiKey960 as targets for AOSP, Dmitry developed the following overlay manager driver, which allows a number of pre-determined DT overlay configurations to be defined, and the configurations to be enabled at boot time via a kernel boot argument. This has been submitted

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Tue, Oct 03, 2017 at 07:18:24PM +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Tue, Oct 3, 2017 at 7:06 AM, Fengguang Wu wrote: > > > > > > This patch triggers a NULL-dereference bug at update_stack_state(). > > >

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Tue, Oct 03, 2017 at 07:18:24PM +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Tue, Oct 3, 2017 at 7:06 AM, Fengguang Wu wrote: > > > > > > This patch triggers a NULL-dereference bug at update_stack_state(). > > > Although its parent commit also has a NULL-dereference bug,

[PATCH v4 2/2] dma: sprd: Add Spreadtrum DMA driver

This patch adds the DMA controller driver for Spreadtrum SC9860 platform. Signed-off-by: Baolin Wang --- Changes since v3: - Remove redundant local 'mask' and 'val' variables. - Simplify sprd_dma_get_req_type() function. - Change pm_runtime_put_sync() to

[PATCH v4 2/2] dma: sprd: Add Spreadtrum DMA driver

This patch adds the DMA controller driver for Spreadtrum SC9860 platform. Signed-off-by: Baolin Wang --- Changes since v3: - Remove redundant local 'mask' and 'val' variables. - Simplify sprd_dma_get_req_type() function. - Change pm_runtime_put_sync() to pm_runtime_put() in probe function. -

[PATCH v4 1/2] dt-bindings: dma: Add Spreadtrum SC9860 DMA controller

This patch adds the binding documentation for Spreadtrum SC9860 DMA controller device. Signed-off-by: Baolin Wang Acked-by: Rob Herring --- Changes since v3: - No update. Changes since v2: - No update. Changes since v1: - Fix typos. ---

[PATCH v4 1/2] dt-bindings: dma: Add Spreadtrum SC9860 DMA controller

This patch adds the binding documentation for Spreadtrum SC9860 DMA controller device. Signed-off-by: Baolin Wang Acked-by: Rob Herring --- Changes since v3: - No update. Changes since v2: - No update. Changes since v1: - Fix typos. --- Documentation/devicetree/bindings/dma/sprd-dma.txt |

Re: [PATCH v2] mm/page_alloc.c: inline __rmqueue()

On 10/09/2017 07:56 PM, Aaron Lu wrote: > This patch adds inline to __rmqueue() and vmlinux' size doesn't have any > change after this patch according to size(1). > > without this patch: >textdata bss dec hex filename > 9968576 5793372 17715200 33477148 1fed21c vmlinux >

Re: [PATCH v2] mm/page_alloc.c: inline __rmqueue()

On 10/09/2017 07:56 PM, Aaron Lu wrote: > This patch adds inline to __rmqueue() and vmlinux' size doesn't have any > change after this patch according to size(1). > > without this patch: >textdata bss dec hex filename > 9968576 5793372 17715200 33477148 1fed21c vmlinux >

Re: [PATCH] net: ftgmac100: Request clock and set speed

On Tue, Oct 10, 2017 at 2:34 PM, Florian Fainelli wrote: > > > On 10/09/2017 09:49 PM, Joel Stanley wrote: >> According to the ASPEED datasheet, gigabit speeds require a clock of >> 100MHz or higher. Other speeds require 25MHz or higher. >> >> Signed-off-by: Joel Stanley

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Tue, Oct 03, 2017 at 09:54:31AM -0700, Linus Torvalds wrote: > On Tue, Oct 3, 2017 at 7:06 AM, Fengguang Wu wrote: > > > > This patch triggers a NULL-dereference bug at update_stack_state(). > > Although its parent commit also has a NULL-dereference bug, however > > the

Re: [PATCH] net: ftgmac100: Request clock and set speed

On Tue, Oct 10, 2017 at 2:34 PM, Florian Fainelli wrote: > > > On 10/09/2017 09:49 PM, Joel Stanley wrote: >> According to the ASPEED datasheet, gigabit speeds require a clock of >> 100MHz or higher. Other speeds require 25MHz or higher. >> >> Signed-off-by: Joel Stanley >> --- > >> @@ -161,6

Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2

On Tue, Oct 03, 2017 at 09:54:31AM -0700, Linus Torvalds wrote: > On Tue, Oct 3, 2017 at 7:06 AM, Fengguang Wu wrote: > > > > This patch triggers a NULL-dereference bug at update_stack_state(). > > Although its parent commit also has a NULL-dereference bug, however > > the call stack looks rather

Re: [PATCH] net: ftgmac100: Request clock and set speed

On 10/09/2017 09:49 PM, Joel Stanley wrote: > According to the ASPEED datasheet, gigabit speeds require a clock of > 100MHz or higher. Other speeds require 25MHz or higher. > > Signed-off-by: Joel Stanley > --- > @@ -161,6 +170,9 @@ static int

Re: [PATCH] net: ftgmac100: Request clock and set speed

On 10/09/2017 09:49 PM, Joel Stanley wrote: > According to the ASPEED datasheet, gigabit speeds require a clock of > 100MHz or higher. Other speeds require 25MHz or higher. > > Signed-off-by: Joel Stanley > --- > @@ -161,6 +170,9 @@ static int ftgmac100_reset_and_config_mac(struct >

Re: [PATCH v5 16/16] perf util: use correct IP mapping to find srcline for hist entry

Hi Milian, On Mon, Oct 09, 2017 at 10:33:10PM +0200, Milian Wolff wrote: > When inline frame resolution is disabled, a bogus srcline is obtained > for hist entries: > > ~ > $ perf report -s sym,srcline --no-inline --stdio -g none > 95.21% 0.00% [.] __libc_start_main

Re: [PATCH v5 16/16] perf util: use correct IP mapping to find srcline for hist entry

Hi Milian, On Mon, Oct 09, 2017 at 10:33:10PM +0200, Milian Wolff wrote: > When inline frame resolution is disabled, a bogus srcline is obtained > for hist entries: > > ~ > $ perf report -s sym,srcline --no-inline --stdio -g none > 95.21% 0.00% [.] __libc_start_main

[PATCH] net: ftgmac100: Request clock and set speed

According to the ASPEED datasheet, gigabit speeds require a clock of 100MHz or higher. Other speeds require 25MHz or higher. Signed-off-by: Joel Stanley --- drivers/net/ethernet/faraday/ftgmac100.c | 22 ++ 1 file changed, 22 insertions(+) diff --git

[PATCH] net: ftgmac100: Request clock and set speed

According to the ASPEED datasheet, gigabit speeds require a clock of 100MHz or higher. Other speeds require 25MHz or higher. Signed-off-by: Joel Stanley --- drivers/net/ethernet/faraday/ftgmac100.c | 22 ++ 1 file changed, 22 insertions(+) diff --git

[PATCH] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

Without the patch, vmbus_hvsock_device_unregister() can destroy the device prematurely when close() is called, and can cause NULl dereferencing or potential data loss (the last portion of the data stream may be dropped prematurely). Signed-off-by: Dexuan Cui Cc: K. Y.

[PATCH] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

Without the patch, vmbus_hvsock_device_unregister() can destroy the device prematurely when close() is called, and can cause NULl dereferencing or potential data loss (the last portion of the data stream may be dropped prematurely). Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang

[PATCH] i2c: aspeed: Deassert reset in probe

In order to use i2c from a cold boot, the i2c peripheral must be taken out of reset. We request a shared reset controller each time a bus driver is loaded, as the reset is shared between the 14 i2c buses. On remove the reset is asserted, which only touches the hardware once the last i2c bus is

[PATCH] i2c: aspeed: Deassert reset in probe

In order to use i2c from a cold boot, the i2c peripheral must be taken out of reset. We request a shared reset controller each time a bus driver is loaded, as the reset is shared between the 14 i2c buses. On remove the reset is asserted, which only touches the hardware once the last i2c bus is

Re: ce07a9415f ("locking/lockdep: Make check_prev_add() able to .."): BUG: unable to handle kernel NULL pointer dereference at 00000020

On Tue, Oct 03, 2017 at 11:32:37AM +0200, Ingo Molnar wrote: > > Any progress with fixing this crash? > > I'll have to revert this commit otherwise. I am sorry for late. It was the biggest traditional holiday until yesterday. I will reply it in another thread. Thank you. > Thanks, > >

Re: ce07a9415f ("locking/lockdep: Make check_prev_add() able to .."): BUG: unable to handle kernel NULL pointer dereference at 00000020

On Tue, Oct 03, 2017 at 11:32:37AM +0200, Ingo Molnar wrote: > > Any progress with fixing this crash? > > I'll have to revert this commit otherwise. I am sorry for late. It was the biggest traditional holiday until yesterday. I will reply it in another thread. Thank you. > Thanks, > >

Re: [PATCH] thermal/intel_powerclamp: pr_err()/pr_info() strings should end with newlines

On Mon, 2017-10-09 at 14:33 +0200, Daniel Lezcano wrote: > On 09/10/2017 13:51, Arvind Yadav wrote: > > pr_err()/pr_info() messages should end with a new-line to avoid > > other messages being concatenated. [] > > diff --git a/drivers/thermal/intel_powerclamp.c > >

Re: [PATCH] thermal/intel_powerclamp: pr_err()/pr_info() strings should end with newlines

On Mon, 2017-10-09 at 14:33 +0200, Daniel Lezcano wrote: > On 09/10/2017 13:51, Arvind Yadav wrote: > > pr_err()/pr_info() messages should end with a new-line to avoid > > other messages being concatenated. [] > > diff --git a/drivers/thermal/intel_powerclamp.c > >

Re: [PATCH v2] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

On Mon, Oct 09, 2017 at 03:45:51PM -0700, Prakash Sangappa wrote: > Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should > be available in Linux 4.14 release. This patch is for the manpage > changes documenting this API. > > Documents the following commit: > > commit

Re: [PATCH v2] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

On Mon, Oct 09, 2017 at 03:45:51PM -0700, Prakash Sangappa wrote: > Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should > be available in Linux 4.14 release. This patch is for the manpage > changes documenting this API. > > Documents the following commit: > > commit

Re: [PATCH v3] HID: hid-multitouch: support fine-grain orientation reporting

Hi Benjamin, Thanks for the review. I've fixed according to your comments and sent the v4 patch: https://patchwork.kernel.org/patch/9995003/ Wei-Ning On Fri, Oct 6, 2017 at 4:13 PM, Benjamin Tissoires wrote: > Hi, > > On Oct 05 2017 or thereabouts, Jiri Kosina

Re: [PATCH v3] HID: hid-multitouch: support fine-grain orientation reporting

Hi Benjamin, Thanks for the review. I've fixed according to your comments and sent the v4 patch: https://patchwork.kernel.org/patch/9995003/ Wei-Ning On Fri, Oct 6, 2017 at 4:13 PM, Benjamin Tissoires wrote: > Hi, > > On Oct 05 2017 or thereabouts, Jiri Kosina wrote: >> >> [ adding Benjamin to

Re: [PATCH 1/3] net/atm: Delete an error message for a failed memory allocation in five functions

On Mon, 2017-10-09 at 22:49 +0200, SF Markus Elfring wrote: > Omit extra messages for a memory allocation failure in these functions. [] > diff --git a/net/atm/mpc.c b/net/atm/mpc.c > @@ -184,10 +184,8 @@ struct atm_mpoa_qos *atm_mpoa_add_qos(__be32 dst_ip, > struct atm_qos *qos) > } > >

Re: [PATCH 1/3] net/atm: Delete an error message for a failed memory allocation in five functions

On Mon, 2017-10-09 at 22:49 +0200, SF Markus Elfring wrote: > Omit extra messages for a memory allocation failure in these functions. [] > diff --git a/net/atm/mpc.c b/net/atm/mpc.c > @@ -184,10 +184,8 @@ struct atm_mpoa_qos *atm_mpoa_add_qos(__be32 dst_ip, > struct atm_qos *qos) > } > >

[PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

From: Wei-Ning Huang The current hid-multitouch driver only allow the report of two orientations, vertical and horizontal. We use the Azimuth orientation usage 0x3F under the Digitizer usage page to report orientation if the device supports it. Changelog: v1 -> v2: -

[PATCH v4] HID: hid-multitouch: support fine-grain orientation reporting

From: Wei-Ning Huang The current hid-multitouch driver only allow the report of two orientations, vertical and horizontal. We use the Azimuth orientation usage 0x3F under the Digitizer usage page to report orientation if the device supports it. Changelog: v1 -> v2: - Fix commit message.

Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support

On Tue, Oct 3, 2017 at 11:23 PM, sakari.ai...@iki.fi wrote: > On Wed, Sep 20, 2017 at 11:45:20AM +0300, sakari.ai...@iki.fi wrote: >> > >> @@ -743,11 +770,17 @@ static int at24_probe(struct i2c_client *client, >> > >> const >> > >> struct i2c_device_id *id) >> > >> >> > >>

Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support

On Mon, Oct 9, 2017 at 12:14 PM, Mohandass, Divagar wrote: > Hi Tomasz, > >>-Original Message- >>From: sakari.ai...@iki.fi [mailto:sakari.ai...@iki.fi] >>Sent: Tuesday, October 03, 2017 7:21 PM >>To: Tomasz Figa >>Cc: Mani, Rajmohan

Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support

On Tue, Oct 3, 2017 at 11:23 PM, sakari.ai...@iki.fi wrote: > On Wed, Sep 20, 2017 at 11:45:20AM +0300, sakari.ai...@iki.fi wrote: >> > >> @@ -743,11 +770,17 @@ static int at24_probe(struct i2c_client *client, >> > >> const >> > >> struct i2c_device_id *id) >> > >> >> > >>

Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support

On Mon, Oct 9, 2017 at 12:14 PM, Mohandass, Divagar wrote: > Hi Tomasz, > >>-Original Message- >>From: sakari.ai...@iki.fi [mailto:sakari.ai...@iki.fi] >>Sent: Tuesday, October 03, 2017 7:21 PM >>To: Tomasz Figa >>Cc: Mani, Rajmohan ; Mohandass, Divagar >>; robh...@kernel.org;

Re: [PATCH] Input: synaptics - Disable kernel tracking on SMBus devices

On Fri, Sep 29, 2017 at 10:08:44AM +0200, Benjamin Tissoires wrote: > On Sep 28 2017 or thereabouts, Andrew Duggan wrote: > > In certain situations kernel tracking seems to be getting confused > > and incorrectly reporting the slot of a contact. On example is when > > the user does a three finger

Re: [PATCH] Input: synaptics - Disable kernel tracking on SMBus devices

On Fri, Sep 29, 2017 at 10:08:44AM +0200, Benjamin Tissoires wrote: > On Sep 28 2017 or thereabouts, Andrew Duggan wrote: > > In certain situations kernel tracking seems to be getting confused > > and incorrectly reporting the slot of a contact. On example is when > > the user does a three finger

Re: [PATCH v2 0/5] Simplify panel bridge cleanup

On 10/02/2017 03:02 PM, Benjamin Gaignard wrote: The goal of this series is to simplify driver code when they need to clean up a previously allocated panel bridge. Few drivers have "is_panel_bridge" flag to be able to distinguish a drm_panel_bridge from "simple" drm_bridge. To remove this flag

Re: [PATCH v2 0/5] Simplify panel bridge cleanup

On 10/02/2017 03:02 PM, Benjamin Gaignard wrote: The goal of this series is to simplify driver code when they need to clean up a previously allocated panel bridge. Few drivers have "is_panel_bridge" flag to be able to distinguish a drm_panel_bridge from "simple" drm_bridge. To remove this flag

Re: [musl] Re: [PATCHv3] uapi libc compat: add fallback for unsupported libcs

Le 10/01/17 à 03:37, Hauke Mehrtens a écrit : > On 07/29/2017 04:02 PM, Felix Janda wrote: >> libc-compat.h aims to prevent symbol collisions between uapi and libc >> headers for each supported libc. This requires continuous coordination >> between them. >> >> The goal of this commit is to improve

Re: [musl] Re: [PATCHv3] uapi libc compat: add fallback for unsupported libcs

Le 10/01/17 à 03:37, Hauke Mehrtens a écrit : > On 07/29/2017 04:02 PM, Felix Janda wrote: >> libc-compat.h aims to prevent symbol collisions between uapi and libc >> headers for each supported libc. This requires continuous coordination >> between them. >> >> The goal of this commit is to improve

Re: [PATCH net-next] once: switch to new jump label API

From: Eric Biggers Date: Mon, 9 Oct 2017 14:30:52 -0700 > From: Eric Biggers > > Switch the DO_ONCE() macro from the deprecated jump label API to the new > one. The new one is more readable, and for DO_ONCE() it also makes the > generated code more

Re: [PATCH net-next] once: switch to new jump label API

From: Eric Biggers Date: Mon, 9 Oct 2017 14:30:52 -0700 > From: Eric Biggers > > Switch the DO_ONCE() macro from the deprecated jump label API to the new > one. The new one is more readable, and for DO_ONCE() it also makes the > generated code more icache-friendly: now the one-time

Re: [PATCH] cpufreq: dt-platdev: drop socionext,uniphier-ld6b from whitelist

On 14-09-17, 14:26, Viresh Kumar wrote: > On 30-08-17, 00:37, Masahiro Yamada wrote: > > As you see arch/arm/boot/dts/uniphier-ld6b.dtsi, it includes > > uniphier-pxs2.dtsi, which uses "operating-points-v2" property > > and whose cpufreq device is automatically created. > > > > Signed-off-by:

Re: [PATCH] cpufreq: dt-platdev: drop socionext,uniphier-ld6b from whitelist

On 14-09-17, 14:26, Viresh Kumar wrote: > On 30-08-17, 00:37, Masahiro Yamada wrote: > > As you see arch/arm/boot/dts/uniphier-ld6b.dtsi, it includes > > uniphier-pxs2.dtsi, which uses "operating-points-v2" property > > and whose cpufreq device is automatically created. > > > > Signed-off-by:

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote: > This fixes a kernel oops when unloading the driver due to usb_put_phy > being called after usb_phy_generic_unregister when the device is > detached. Calling usb_phy_generic_unregister causes x->dev->driver to > be NULL in usb_put_phy

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote: > This fixes a kernel oops when unloading the driver due to usb_put_phy > being called after usb_phy_generic_unregister when the device is > detached. Calling usb_phy_generic_unregister causes x->dev->driver to > be NULL in usb_put_phy

[PATCH v4 00/11] drm/sun4i: hdmi: Support HDMI controller on A31

Hi everyone, This is v4 of my A31 HDMI support series. The DTS patches depend on the patch "clk: sunxi-ng: sun6i: Export video PLLs" alreay merged. The DRM patches depend on "regmap: add iopoll-like polling macro for regmap_field" already merged on a topic branch in the regmap repository.

[PATCH v4 00/11] drm/sun4i: hdmi: Support HDMI controller on A31

Hi everyone, This is v4 of my A31 HDMI support series. The DTS patches depend on the patch "clk: sunxi-ng: sun6i: Export video PLLs" alreay merged. The DRM patches depend on "regmap: add iopoll-like polling macro for regmap_field" already merged on a topic branch in the regmap repository.

[PATCH v4 01/11] drm/sun4i: tcon: Add variant callback for TCON output muxing

Different SoCs have different muxing options and values for the TCON outputs. Instead of stuffing every possibility in sun4i_tcon_set_mux(), add a callback pointer to sun4i_tcon_quirks that each TCON variant can use to provide muxing support. The current muxing options in sun4i_tcon_set_mux() for

[PATCH v4 03/11] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function

The HDMI driver enables the bus and mod clocks in the bind function, but does not disable them if it then bails our due to any errors. Neither does it disable the clocks in the unbind function. Fix this by adding a proper error path to the bind function, and clk_disable_unprepare calls to the

[PATCH v4 01/11] drm/sun4i: tcon: Add variant callback for TCON output muxing

Different SoCs have different muxing options and values for the TCON outputs. Instead of stuffing every possibility in sun4i_tcon_set_mux(), add a callback pointer to sun4i_tcon_quirks that each TCON variant can use to provide muxing support. The current muxing options in sun4i_tcon_set_mux() for

[PATCH v4 03/11] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function

The HDMI driver enables the bus and mod clocks in the bind function, but does not disable them if it then bails our due to any errors. Neither does it disable the clocks in the unbind function. Fix this by adding a proper error path to the bind function, and clk_disable_unprepare calls to the

[PATCH v4 06/11] dt-bindings: display: sun4i: Add binding for A31 HDMI controller

The HDMI controller in the A31 SoC is slightly different from the earlier version. In addition to the TMDS clock and DDC controls, this version now takes a second DDC clock input. Add a compatible string for it, and add the DDC clock input to the list of clocks required. Signed-off-by: Chen-Yu

[PATCH v4 06/11] dt-bindings: display: sun4i: Add binding for A31 HDMI controller

The HDMI controller in the A31 SoC is slightly different from the earlier version. In addition to the TMDS clock and DDC controls, this version now takes a second DDC clock input. Add a compatible string for it, and add the DDC clock input to the list of clocks required. Signed-off-by: Chen-Yu

[PATCH v4 10/11] ARM: dts: sun6i: Add device node for HDMI controller

Now that we support the HDMI controller on the A31 SoC, we can add it to the device tree. This adds a device node for the HDMI controller, and the of_graph nodes connecting it to the 2 TCONs. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31.dtsi | 55

[PATCH v4 05/11] drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent

On SoCs with two display pipelines, it is possible that the two pipelines are active at the same time, with potentially incompatible dot clocks. Let the HDMI encoder's TMDS clock go through all of its parents when calculating possible clock rates. This allows usage of the second video PLL as its

[PATCH v4 10/11] ARM: dts: sun6i: Add device node for HDMI controller

Now that we support the HDMI controller on the A31 SoC, we can add it to the device tree. This adds a device node for the HDMI controller, and the of_graph nodes connecting it to the 2 TCONs. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun6i-a31.dtsi | 55

[PATCH v4 05/11] drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent

On SoCs with two display pipelines, it is possible that the two pipelines are active at the same time, with potentially incompatible dot clocks. Let the HDMI encoder's TMDS clock go through all of its parents when calculating possible clock rates. This allows usage of the second video PLL as its

[PATCH v4 11/11] ARM: dts: sun6i: Enable HDMI support on some A31/A31s devices

All the A31/A31s devices I own have some kind of HDMI connector wired to the dedicated HDMI pins on the SoC: - A31 Hummingbird (standard HDMI connector, display already enabled) - Sinlinx SinA31s (standard HDMI connector) - MSI Primo81 tablet (micro HDMI connector) Enable the display

[PATCH v4 11/11] ARM: dts: sun6i: Enable HDMI support on some A31/A31s devices

All the A31/A31s devices I own have some kind of HDMI connector wired to the dedicated HDMI pins on the SoC: - A31 Hummingbird (standard HDMI connector, display already enabled) - Sinlinx SinA31s (standard HDMI connector) - MSI Primo81 tablet (micro HDMI connector) Enable the display

[PATCH v4 08/11] drm/sun4i: hdmi: Add A31 specific DDC register definitions

The DDC block for the HDMI controller is different on the A31. This patch adds the register definitions. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 31 +++ 1 file

[PATCH v4 08/11] drm/sun4i: hdmi: Add A31 specific DDC register definitions

The DDC block for the HDMI controller is different on the A31. This patch adds the register definitions. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 31 +++ 1 file changed, 31 insertions(+) diff --git

[PATCH v4 04/11] drm/sun4i: hdmi: create a regmap for later use

The HDMI driver is written with readl/writel I/O to the registers. However, to support the A31 variant, which has a different layout for the DDC registers, it was recommended to use regfields to have a cleaner implementation. To use regfields, we need to create an underlying regmap. This patch

[PATCH v4 04/11] drm/sun4i: hdmi: create a regmap for later use

The HDMI driver is written with readl/writel I/O to the registers. However, to support the A31 variant, which has a different layout for the DDC registers, it was recommended to use regfields to have a cleaner implementation. To use regfields, we need to create an underlying regmap. This patch

[PATCH v4 07/11] drm/sun4i: hdmi: Add support for controller hardware variants

The HDMI controller found in earlier Allwinner SoCs have slight differences between the A10, A10s, and the A31: - Need different initial values for the PLL related registers - Different behavior of the DDC and TMDS clocks - Different register layout for the DDC portion - Separate DDC

[PATCH v4 02/11] drm/sun4i: tcon: Add support for demuxing TCON output on A31

On systems with 2 TCONs such as the A31, it is possible to demux the output of the TCONs to one encoder. Add support for this for the A31. Signed-off-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 47 ++ 1 file changed, 47

  1   2   3   4   5   6   7   8   9   10   >