[PATCH v3 5/5] ARM: davinci: remove clock debugfs

This removed the debugfs entry for mach-davinci clocks. The clocks now use the common clock framework, which provides debugfs already, so this code is redundant. Signed-off-by: David Lechner --- arch/arm/mach-davinci/clock.c | 79 ---

[PATCH v3 5/5] ARM: davinci: remove clock debugfs

This removed the debugfs entry for mach-davinci clocks. The clocks now use the common clock framework, which provides debugfs already, so this code is redundant. Signed-off-by: David Lechner --- arch/arm/mach-davinci/clock.c | 79 --- 1 file changed, 79

[PATCH v3 2/5] ARM: davinci: don't use static clk_lookup

In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. davinci_clk_init() is changed to init a single clock instead of a table.

[PATCH v3 0/5] ARM: davinci: convert to common clock framework

This series takes the first steps towards moving mach-davinci to the common clock framework. Basically, this series does some cleanup and rearranging to get things ready for the conversion. Then in "ARM: davinci: convert to common clock framework" we actually make the conversion. This is done by

[PATCH v3 2/5] ARM: davinci: don't use static clk_lookup

In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. davinci_clk_init() is changed to init a single clock instead of a table.

[PATCH v3 0/5] ARM: davinci: convert to common clock framework

This series takes the first steps towards moving mach-davinci to the common clock framework. Basically, this series does some cleanup and rearranging to get things ready for the conversion. Then in "ARM: davinci: convert to common clock framework" we actually make the conversion. This is done by

Re: [PATCH V3] ACPI / GED: unregister interrupts during shutdown

On 12/8/2017 8:54 AM, Rafael J. Wysocki wrote: >> static int ged_remove(struct platform_device *pdev) >> +{ >> + struct acpi_ged_device *geddev = platform_get_drvdata(pdev); >> >> + ged_cleanup_irq(geddev); > Do you really need this duplication? You may as well call > ged_shutdown()

Re: [PATCH V3] ACPI / GED: unregister interrupts during shutdown

On 12/8/2017 8:54 AM, Rafael J. Wysocki wrote: >> static int ged_remove(struct platform_device *pdev) >> +{ >> + struct acpi_ged_device *geddev = platform_get_drvdata(pdev); >> >> + ged_cleanup_irq(geddev); > Do you really need this duplication? You may as well call > ged_shutdown()

Re: [PATCH v2 2/5] ARM: davinci: don't use static clk_lookup

On 12/08/2017 07:43 PM, David Lechner wrote: In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. davinci_clk_init() is changed

Re: [PATCH v2 2/5] ARM: davinci: don't use static clk_lookup

On 12/08/2017 07:43 PM, David Lechner wrote: In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. davinci_clk_init() is changed

[PATCH v2 1/5] ARM: davinci: move davinci_clk_init() to init_time

This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. Signed-off-by: David Lechner --- v2 changes: * Introduce new init_time

[PATCH v2 1/5] ARM: davinci: move davinci_clk_init() to init_time

This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. Signed-off-by: David Lechner --- v2 changes: * Introduce new init_time function for each SoC

[PATCH v2 0/5] ARM: davinci: convert to common clock framework

This series takes the first steps towards moving mach-davinci to the common clock framework. Basically, this series does some cleanup and rearranging to get things ready for the conversion. Then in "ARM: davinci: convert to common clock framework" we actually make the conversion. This is done by

[PATCH v2 5/5] ARM: davinci: remove clock debugfs

This removed the debugfs entry for mach-davinci clocks. The clocks now use the common clock framework, which provides debugfs already, so this code is redundant. Signed-off-by: David Lechner --- v2 changes: None arch/arm/mach-davinci/clock.c | 79

[PATCH v2 4/5] ARM: davinci: convert to common clock framework

This converts the clocks in mach-davinci to the common clock framework. Most of the patch just involves renaming struct clk to struct davinci_clk. There is also a struct clk_hw added to provide the bridge between the existing clock implementation and the common clock framework. The

[PATCH v2 3/5] ARM: davinci: make davinci_clk_reset() static

This makes davinci_clk_reset() static. It is not used anywhere else. Signed-off-by: David Lechner --- v2 changes: None arch/arm/mach-davinci/clock.c | 3 +-- arch/arm/mach-davinci/clock.h | 1 - 2 files changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH v2 0/5] ARM: davinci: convert to common clock framework

This series takes the first steps towards moving mach-davinci to the common clock framework. Basically, this series does some cleanup and rearranging to get things ready for the conversion. Then in "ARM: davinci: convert to common clock framework" we actually make the conversion. This is done by

[PATCH v2 5/5] ARM: davinci: remove clock debugfs

This removed the debugfs entry for mach-davinci clocks. The clocks now use the common clock framework, which provides debugfs already, so this code is redundant. Signed-off-by: David Lechner --- v2 changes: None arch/arm/mach-davinci/clock.c | 79 --- 1

[PATCH v2 4/5] ARM: davinci: convert to common clock framework

This converts the clocks in mach-davinci to the common clock framework. Most of the patch just involves renaming struct clk to struct davinci_clk. There is also a struct clk_hw added to provide the bridge between the existing clock implementation and the common clock framework. The

[PATCH v2 3/5] ARM: davinci: make davinci_clk_reset() static

This makes davinci_clk_reset() static. It is not used anywhere else. Signed-off-by: David Lechner --- v2 changes: None arch/arm/mach-davinci/clock.c | 3 +-- arch/arm/mach-davinci/clock.h | 1 - 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/clock.c

[PATCH v2 2/5] ARM: davinci: don't use static clk_lookup

In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. davinci_clk_init() is changed to init a single clock instead of a table.

[PATCH v2 2/5] ARM: davinci: don't use static clk_lookup

In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. davinci_clk_init() is changed to init a single clock instead of a table.

Re: [PATCH] doc: convert printk-formats.txt to rst

On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote: > On Fri, 2017-12-08 at 13:06 -0800, Kees Cook wrote: > > Well ... my sense is that lib/vsprintf.c should remain the canonical > > documentation. > > I agree. > > > Anyone working on the code has the docs all together in > > one file.

Re: [PATCH] doc: convert printk-formats.txt to rst

On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote: > On Fri, 2017-12-08 at 13:06 -0800, Kees Cook wrote: > > Well ... my sense is that lib/vsprintf.c should remain the canonical > > documentation. > > I agree. > > > Anyone working on the code has the docs all together in > > one file.

Re: [PATCH 4/5] Input: edt-ft5x06 - Add support for regulator

On Fri, Dec 08, 2017 at 05:16:29PM -0800, Dmitry Torokhov wrote: > Hi Mylène, > > On Fri, Dec 08, 2017 at 10:54:18PM +0100, Mylène Josserand wrote: > > Add the support of regulator to use them as VCC source. > > > > Signed-off-by: Mylène Josserand > > --- >

Re: [PATCH 4/5] Input: edt-ft5x06 - Add support for regulator

On Fri, Dec 08, 2017 at 05:16:29PM -0800, Dmitry Torokhov wrote: > Hi Mylène, > > On Fri, Dec 08, 2017 at 10:54:18PM +0100, Mylène Josserand wrote: > > Add the support of regulator to use them as VCC source. > > > > Signed-off-by: Mylène Josserand > > --- > >

Re: [PATCH 4/4] checkpatch: add check for tag Co-Developed-by

On Fri, Dec 08, 2017 at 08:42:52AM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 08, 2017 at 10:27:51AM +1100, Tobin C. Harding wrote: > > From: Joe Perches > > > > Recently signature tag Co-Developed-by was added to the > > kernel (Documentation/process/5.Posting.rst).

Re: [PATCH 4/4] checkpatch: add check for tag Co-Developed-by

On Fri, Dec 08, 2017 at 08:42:52AM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 08, 2017 at 10:27:51AM +1100, Tobin C. Harding wrote: > > From: Joe Perches > > > > Recently signature tag Co-Developed-by was added to the > > kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't

Re: [PATCH 4/5] Input: edt-ft5x06 - Add support for regulator

Hi Mylène, On Fri, Dec 08, 2017 at 10:54:18PM +0100, Mylène Josserand wrote: > Add the support of regulator to use them as VCC source. > > Signed-off-by: Mylène Josserand > --- > drivers/input/touchscreen/edt-ft5x06.c | 33 +

Re: [PATCH 4/5] Input: edt-ft5x06 - Add support for regulator

Hi Mylène, On Fri, Dec 08, 2017 at 10:54:18PM +0100, Mylène Josserand wrote: > Add the support of regulator to use them as VCC source. > > Signed-off-by: Mylène Josserand > --- > drivers/input/touchscreen/edt-ft5x06.c | 33 + > 1 file changed, 33 insertions(+) >

[PATCH V2] arm64: fault: avoid send SIGBUS two times

do_sea() calls arm64_notify_die() which will always signal user-space. It also returns whether APEI claimed the external abort as a RAS notification. If it returns failure do_mem_abort() will signal user-space too. do_mem_abort() wants to know if we handled the error, we always call

[PATCH V2] arm64: fault: avoid send SIGBUS two times

do_sea() calls arm64_notify_die() which will always signal user-space. It also returns whether APEI claimed the external abort as a RAS notification. If it returns failure do_mem_abort() will signal user-space too. do_mem_abort() wants to know if we handled the error, we always call

[PATCH] staging: ion: Fix ion_cma_heap allocations

In trying to add support for drm_hwcomposer to HiKey, I've needed to utilize the ION CMA heap, and I've noticed problems with allocations on newer kernels failing. It seems back with 204f672255c2 ("ion: Use CMA APIs directly"), the ion_cma_heap code was modified to use the CMA API, but kept the

[PATCH] staging: ion: Fix ion_cma_heap allocations

In trying to add support for drm_hwcomposer to HiKey, I've needed to utilize the ION CMA heap, and I've noticed problems with allocations on newer kernels failing. It seems back with 204f672255c2 ("ion: Use CMA APIs directly"), the ion_cma_heap code was modified to use the CMA API, but kept the

[PATCH] futex: Check for uaddr alignment as early as possible

From: "Darren Hart (VMware)" uaddr alignment is currently tested by get_futex_key(). We can catch misalignment earlier in sys_futex and return -EINVAL sooner. This simplifies get_futex_key() a little, but more importantly exits the kernel as soon as an invalid parameter is

[PATCH] futex: Check for uaddr alignment as early as possible

From: "Darren Hart (VMware)" uaddr alignment is currently tested by get_futex_key(). We can catch misalignment earlier in sys_futex and return -EINVAL sooner. This simplifies get_futex_key() a little, but more importantly exits the kernel as soon as an invalid parameter is detected. Passes all

Re: [PATCH v5 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint

2017-12-09 0:28 GMT+08:00 David Miller : > From: Yafang Shao > Date: Fri, 8 Dec 2017 23:50:44 +0800 > >> 2017-12-08 23:42 GMT+08:00 David Miller : >>> From: Yafang Shao >>> Date: Fri, 8 Dec 2017 11:40:23 +0800

Re: [PATCH v5 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint

2017-12-09 0:28 GMT+08:00 David Miller : > From: Yafang Shao > Date: Fri, 8 Dec 2017 23:50:44 +0800 > >> 2017-12-08 23:42 GMT+08:00 David Miller : >>> From: Yafang Shao >>> Date: Fri, 8 Dec 2017 11:40:23 +0800 >>> It will looks like these, if (sk->sk_protocol == IPPROTO_TCP)

[PATCH] wcn36xx: Reduce spinlock in indication handler

The purpose of pushing indication on a list and handle these in a separate worker is to allow the handlers to sleep. It does therefor not make much sense to hold the queue spinlock through the entire indication worker function. By removing items from the queue early we don't need to hold the lock

[PATCH] wcn36xx: Reduce spinlock in indication handler

The purpose of pushing indication on a list and handle these in a separate worker is to allow the handlers to sleep. It does therefor not make much sense to hold the queue spinlock through the entire indication worker function. By removing items from the queue early we don't need to hold the lock

[PATCH][next] scsi: arcmsr: remove redundant check for secs < 0

From: Colin Ian King The check for secs being less than zero is redundant for two reasons. Firstly, secs is unsigned so the check is always going to be false. Secondly, if secs was signed the proceeding calculation of secs is never going to be negative. Hence we can

[PATCH][next] scsi: arcmsr: remove redundant check for secs < 0

From: Colin Ian King The check for secs being less than zero is redundant for two reasons. Firstly, secs is unsigned so the check is always going to be false. Secondly, if secs was signed the proceeding calculation of secs is never going to be negative. Hence we can remove this redundant check

[PATCH] x86/intel_rdt: Classify /proc/cpuinfo flag bits and add missing bits in documentation

From: Fenghua Yu With more flag bits in /proc/cpuinfo for RDT, it's better to classify the bits for readability. Some previously missing bits are added as well. Signed-off-by: Fenghua Yu --- Documentation/x86/intel_rdt_ui.txt | 7 ++- 1 file

[PATCH] x86/intel_rdt: Classify /proc/cpuinfo flag bits and add missing bits in documentation

From: Fenghua Yu With more flag bits in /proc/cpuinfo for RDT, it's better to classify the bits for readability. Some previously missing bits are added as well. Signed-off-by: Fenghua Yu --- Documentation/x86/intel_rdt_ui.txt | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff

Re: [PATCH 10/13] clk: qcom: support for Huayra PLL

On 09/28, Abhishek Sahu wrote: > Following are the major differences in Huayra PLL > > 1. PLL Alpha Value is 16 bits > 2. Depending on alpha_mode, the pll_alpha_val can be treated as >M/N value or as a two’s compliment number. > 3. Huayra PLL supports PLL dynamic programming. User can change

Re: [PATCH 10/13] clk: qcom: support for Huayra PLL

On 09/28, Abhishek Sahu wrote: > Following are the major differences in Huayra PLL > > 1. PLL Alpha Value is 16 bits > 2. Depending on alpha_mode, the pll_alpha_val can be treated as >M/N value or as a two’s compliment number. > 3. Huayra PLL supports PLL dynamic programming. User can change

Re: [PATCH 11/13] clk: qcom: support for Brammo PLL

On 09/28, Abhishek Sahu wrote: > 1. Brammo PLL does not allow configuration of VCO > 2. Supports the dynamic update in which the frequency can >be changed dynamically without turning off the PLL > 3. The register offsets are different from normal Alpha PLL > > Signed-off-by: Abhishek Sahu

Re: [PATCH 09/13] clk: qcom: add flag for VCO operation

On 09/28, Abhishek Sahu wrote: > Some of the Alpha PLL’s does not have VCO configuration so this > patch adds the flag and does not perform VCO operation if this > flag is set. > > Signed-off-by: Abhishek Sahu > --- Applied to clk-next -- Qualcomm Innovation Center,

Re: [PATCH 11/13] clk: qcom: support for Brammo PLL

On 09/28, Abhishek Sahu wrote: > 1. Brammo PLL does not allow configuration of VCO > 2. Supports the dynamic update in which the frequency can >be changed dynamically without turning off the PLL > 3. The register offsets are different from normal Alpha PLL > > Signed-off-by: Abhishek Sahu >

Re: [PATCH 09/13] clk: qcom: add flag for VCO operation

On 09/28, Abhishek Sahu wrote: > Some of the Alpha PLL’s does not have VCO configuration so this > patch adds the flag and does not perform VCO operation if this > flag is set. > > Signed-off-by: Abhishek Sahu > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code

Re: [PATCH 12/13] clk: qcom: support for 2 bit PLL post divider

On 09/28, Abhishek Sahu wrote: > Current PLL driver only supports 4 bit PLL post divider so > modified the PLL divider operations to support 2 bit PLL > post divider. > > Signed-off-by: Abhishek Sahu > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a

Re: [PATCH 12/13] clk: qcom: support for 2 bit PLL post divider

On 09/28, Abhishek Sahu wrote: > Current PLL driver only supports 4 bit PLL post divider so > modified the PLL divider operations to support 2 bit PLL > post divider. > > Signed-off-by: Abhishek Sahu > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora

Re: [PATCH 06/13] clk: qcom: flag for 64 bit CONFIG_CTL

On 09/28, Abhishek Sahu wrote: > Some of the Alpha PLL’s (like Spark, Brammo PLL) do not have > CONFIG_CTL_U register. This patch adds the flag in properties > for PLL’s which have CONFIG_CTL_U register and checks the same > while doing PLL initial configuration. > > Signed-off-by: Abhishek Sahu

Re: [PATCH 06/13] clk: qcom: flag for 64 bit CONFIG_CTL

On 09/28, Abhishek Sahu wrote: > Some of the Alpha PLL’s (like Spark, Brammo PLL) do not have > CONFIG_CTL_U register. This patch adds the flag in properties > for PLL’s which have CONFIG_CTL_U register and checks the same > while doing PLL initial configuration. > > Signed-off-by: Abhishek Sahu

Re: [PATCH 05/13] clk: qcom: add and use alpha register width from PLL properties

On 09/28, Abhishek Sahu wrote: > Currently SUPPORTS_16BIT_ALPHA flag determines the PLL alpha > register width. If this flag is set then the alpha register width > is 16 bits otherwise it is 40 bits. The alpha width is always > fixed for PLL type so it can be added in PLL properties and clock >

Re: [PATCH 05/13] clk: qcom: add and use alpha register width from PLL properties

On 09/28, Abhishek Sahu wrote: > Currently SUPPORTS_16BIT_ALPHA flag determines the PLL alpha > register width. If this flag is set then the alpha register width > is 16 bits otherwise it is 40 bits. The alpha width is always > fixed for PLL type so it can be added in PLL properties and clock >

Re: [PATCH 07/13] clk: qcom: support for alpha mode configuration

On 09/28, Abhishek Sahu wrote: > The current configuration does not fully configure PLL alpha mode > and values so this patch > > 1. Configures PLL_ALPHA_VAL_U for PLL which supports 40 bit alpha. > 2. Adds alpha enable and alpha mode configuration support. > > Signed-off-by: Abhishek Sahu

Re: [PATCH 07/13] clk: qcom: support for alpha mode configuration

On 09/28, Abhishek Sahu wrote: > The current configuration does not fully configure PLL alpha mode > and values so this patch > > 1. Configures PLL_ALPHA_VAL_U for PLL which supports 40 bit alpha. > 2. Adds alpha enable and alpha mode configuration support. > > Signed-off-by: Abhishek Sahu >

Re: [PATCH 08/13] clk: qcom: support for dynamic updating the PLL

On 09/28, Abhishek Sahu wrote: > Some of the Alpha PLL’s support dynamic update in which the > frequency can be changed dynamically without turning off the PLL. > > This dynamic update requires the following sequence > > 1. Write the desired values to pll_l_val and pll_alpha_val > 2. Toggle

Re: [PATCH 04/13] clk: qcom: fix 16 bit alpha support calculation

On 09/28, Abhishek Sahu wrote: > The alpha value calculation function has been written for 40 bit > alpha which is not coming properly for 16 bit > > 1. Alpha value is being calculated on the basis of >ALPHA_BITWIDTH to make the computation easy for 40 bit alpha. >After calculating the 32

Re: [PATCH 03/13] clk: qcom: support for alpha pll properties

On 09/28, Abhishek Sahu wrote: > Alpha PLL is a generic name used for QCOM PLL’s which uses L > and Alpha values for configuring the integer and fractional part. > QCOM SoC’s use different types of Alpha PLL’s for which basic > software configuration part is common with following differences. > >

Re: [PATCH 03/13] clk: qcom: support for alpha pll properties

On 09/28, Abhishek Sahu wrote: > Alpha PLL is a generic name used for QCOM PLL’s which uses L > and Alpha values for configuring the integer and fractional part. > QCOM SoC’s use different types of Alpha PLL’s for which basic > software configuration part is common with following differences. > >

Re: [PATCH 08/13] clk: qcom: support for dynamic updating the PLL

On 09/28, Abhishek Sahu wrote: > Some of the Alpha PLL’s support dynamic update in which the > frequency can be changed dynamically without turning off the PLL. > > This dynamic update requires the following sequence > > 1. Write the desired values to pll_l_val and pll_alpha_val > 2. Toggle

Re: [PATCH 04/13] clk: qcom: fix 16 bit alpha support calculation

On 09/28, Abhishek Sahu wrote: > The alpha value calculation function has been written for 40 bit > alpha which is not coming properly for 16 bit > > 1. Alpha value is being calculated on the basis of >ALPHA_BITWIDTH to make the computation easy for 40 bit alpha. >After calculating the 32

Re: [PATCH 13/13] clk: qcom: add read-only alpha pll post divider operations

On 09/28, Abhishek Sahu wrote: > Some of the divider settings are preconfigured and should not > be changed by the clock framework during frequency change. This > patch adds the read-only divider operation for QCOM alpha pll > post divider which is equivalent to generic divider operations in >

Re: [PATCH 13/13] clk: qcom: add read-only alpha pll post divider operations

On 09/28, Abhishek Sahu wrote: > Some of the divider settings are preconfigured and should not > be changed by the clock framework during frequency change. This > patch adds the read-only divider operation for QCOM alpha pll > post divider which is equivalent to generic divider operations in >

Re: [PATCH V2 net-next 2/8] net: hns3: Add mailbox support to VF driver

Sali, On Fri, Dec 8, 2017 at 10:16 PM, Salil Mehta wrote: > This patch adds the support of the mailbox to the VF driver. The > mailbox shall be used as an interface to communicate with the > PF driver for various purposes like {set|get} MAC related > operations, reset,

Re: [PATCH V2 net-next 2/8] net: hns3: Add mailbox support to VF driver

Sali, On Fri, Dec 8, 2017 at 10:16 PM, Salil Mehta wrote: > This patch adds the support of the mailbox to the VF driver. The > mailbox shall be used as an interface to communicate with the > PF driver for various purposes like {set|get} MAC related > operations, reset, link status etc. The

Re: [PATCH 00/13] Updates for QCOM Alpha PLL

On 12/08, Abhishek Sahu wrote: > On 2017-12-07 11:53, Stephen Boyd wrote: > >On 09/28, Abhishek Sahu wrote: > >>This patch series does the miscellaneous changes in QCOM Alpha PLL > >>operation and structure to support other types of Alpha PLL’s. > >> > >>1. It adds the pll_type which will be used

Re: [PATCH 00/13] Updates for QCOM Alpha PLL

On 12/08, Abhishek Sahu wrote: > On 2017-12-07 11:53, Stephen Boyd wrote: > >On 09/28, Abhishek Sahu wrote: > >>This patch series does the miscellaneous changes in QCOM Alpha PLL > >>operation and structure to support other types of Alpha PLL’s. > >> > >>1. It adds the pll_type which will be used

Re: [PATCH] asus-wireless: send an EV_SYN/SYN_REPORT between state changes

On Mon, Dec 04, 2017 at 10:26:17AM +1000, Peter Hutterer wrote: > Sending the switch state change twice within the same frame is invalid evdev > protocol and only works if the client handles keys immediately as well. > Processing events immediately is incorrect, it forces a fake order of events >

Re: [PATCH] asus-wireless: send an EV_SYN/SYN_REPORT between state changes

On Mon, Dec 04, 2017 at 10:26:17AM +1000, Peter Hutterer wrote: > Sending the switch state change twice within the same frame is invalid evdev > protocol and only works if the client handles keys immediately as well. > Processing events immediately is incorrect, it forces a fake order of events >

mmotm 2017-12-08-16-01 uploaded

The mm-of-the-moment snapshot 2017-12-08-16-01 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2017-12-08-16-01 uploaded

The mm-of-the-moment snapshot 2017-12-08-16-01 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH] ntb_transport: fix qp count bug

Sorry, ignore this. I sent an old patch. Logan On 08/12/17 05:01 PM, Logan Gunthorpe wrote: In cases where there are more mw's than spads/2-2, the mw count gets reduced to match the limitation. ntb_transport also tries to ensure that there are fewer qps than mws but uses the full mw count

Re: [PATCH] ntb_transport: fix qp count bug

Sorry, ignore this. I sent an old patch. Logan On 08/12/17 05:01 PM, Logan Gunthorpe wrote: In cases where there are more mw's than spads/2-2, the mw count gets reduced to match the limitation. ntb_transport also tries to ensure that there are fewer qps than mws but uses the full mw count

[PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

With Switchtec hardware, the buffer used for a memory window must be aligned to its size (the hardware only replaces the lower bits). In certain circumstances dma_alloc_coherent() will not provide a buffer that adheres to this requirement like when using the CMA and CONFIG_CMA_ALIGNMENT is set

[PATCH 2/2] ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()

With Switchtec hardware, the buffer used for a memory window must be aligned to its size (the hardware only replaces the lower bits). In certain circumstances dma_alloc_coherent() will not provide a buffer that adheres to this requirement like when using the CMA and CONFIG_CMA_ALIGNMENT is set

Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one particular instance, it does the > following: > > if

[PATCH 1/2] ntb_transport: Fix bug with max_mw_size parameter

When using the max_mw_size parameter of ntb_transport to limit the size of the Memory windows, communication cannot be established and the queues freeze. This is because the mw_size that's reported to the peer is correctly limited but the size used locally is not. So the MW is initialized with a

Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one particular instance, it does the > following: > > if

[PATCH 1/2] ntb_transport: Fix bug with max_mw_size parameter

When using the max_mw_size parameter of ntb_transport to limit the size of the Memory windows, communication cannot be established and the queues freeze. This is because the mw_size that's reported to the peer is correctly limited but the size used locally is not. So the MW is initialized with a

[PATCH] ntb_transport: fix qp count bug

In cases where there are more mw's than spads/2-2, the mw count gets reduced to match the limitation. ntb_transport also tries to ensure that there are fewer qps than mws but uses the full mw count instead of the reduced one. When this happens, the math in 'ntb_transport_setup_qp_mw' will get

[PATCH] ntb_transport: fix qp count bug

In cases where there are more mw's than spads/2-2, the mw count gets reduced to match the limitation. ntb_transport also tries to ensure that there are fewer qps than mws but uses the full mw count instead of the reduced one. When this happens, the math in 'ntb_transport_setup_qp_mw' will get

Re: [PATCH] ntb_netdev: set the net_device's parent

Sorry ignore this. I sent an old patch :( Logan On 08/12/17 05:01 PM, Logan Gunthorpe wrote: At present, ntb_netdev devices end up under /sys/devices/virtual/net completely unconnected to the ntb trees below them. This patch sets the parent of the net_device (using SET_NETDEV_DEV) to the

Re: [PATCH] ntb_netdev: set the net_device's parent

Sorry ignore this. I sent an old patch :( Logan On 08/12/17 05:01 PM, Logan Gunthorpe wrote: At present, ntb_netdev devices end up under /sys/devices/virtual/net completely unconnected to the ntb trees below them. This patch sets the parent of the net_device (using SET_NETDEV_DEV) to the

[PATCH] ntb_netdev: set the net_device's parent

At present, ntb_netdev devices end up under /sys/devices/virtual/net completely unconnected to the ntb trees below them. This patch sets the parent of the net_device (using SET_NETDEV_DEV) to the client_dev device. This results in a better connected sysfs path for the network device:

[PATCH] ntb_netdev: set the net_device's parent

At present, ntb_netdev devices end up under /sys/devices/virtual/net completely unconnected to the ntb trees below them. This patch sets the parent of the net_device (using SET_NETDEV_DEV) to the client_dev device. This results in a better connected sysfs path for the network device:

Re: [PATCH 0/9] remove some of unneeded kallsyms includes

On (12/08/17 14:24), Andrew Morton wrote: > On Fri, 8 Dec 2017 11:56:07 +0900 Sergey Senozhatsky > wrote: > > > A small patch set that removes some kallsyms includes > > here and there. Mostly those kallsyms includes are leftovers: > > printk() gained

Re: [PATCH 0/9] remove some of unneeded kallsyms includes

On (12/08/17 14:24), Andrew Morton wrote: > On Fri, 8 Dec 2017 11:56:07 +0900 Sergey Senozhatsky > wrote: > > > A small patch set that removes some kallsyms includes > > here and there. Mostly those kallsyms includes are leftovers: > > printk() gained %pS/%pF modifiers support some time

[PATCH] ACPI / CPPC: remove initial assignment of pcc_ss_data

From: Colin Ian King The initialization of pcc_ss_data from pcc_data[pcc_ss_id] before pcc_ss_id is being range checked could lead to an out-of-bounds array read. This very same initialization is also being performed after the range check on pcc_ss_id, so we can just

[PATCH] ACPI / CPPC: remove initial assignment of pcc_ss_data

From: Colin Ian King The initialization of pcc_ss_data from pcc_data[pcc_ss_id] before pcc_ss_id is being range checked could lead to an out-of-bounds array read. This very same initialization is also being performed after the range check on pcc_ss_id, so we can just remove this problematic and

Re: [PATCH] tools/slabinfo-gnuplot: force to use bash shell

On (12/08/17 14:02), Andrew Morton wrote: > > On (12/08/17 17:37), Liu, Changcheng wrote: > > > > > > On some linux distributions, the default link of sh > > > is dash which deoesn't support split array like > > > ${var//,/ } > > > It's better to force to use bash shell directly. > > > > > >

Re: [PATCH] tools/slabinfo-gnuplot: force to use bash shell

On (12/08/17 14:02), Andrew Morton wrote: > > On (12/08/17 17:37), Liu, Changcheng wrote: > > > > > > On some linux distributions, the default link of sh > > > is dash which deoesn't support split array like > > > ${var//,/ } > > > It's better to force to use bash shell directly. > > > > > >

Re: [PATCH 4/9] pci: remove unneeded kallsyms include

On (12/08/17 11:53), Bjorn Helgaas wrote: > On Fri, Dec 08, 2017 at 11:56:11AM +0900, Sergey Senozhatsky wrote: > > The file was converted from print_fn_descriptor_symbol() > > to %pF some time ago (c9bbb4abb658da "PCI: use %pF instead > > of print_fn_descriptor_symbol() in quirks.c"). kallsyms

Re: [PATCH 4/9] pci: remove unneeded kallsyms include

On (12/08/17 11:53), Bjorn Helgaas wrote: > On Fri, Dec 08, 2017 at 11:56:11AM +0900, Sergey Senozhatsky wrote: > > The file was converted from print_fn_descriptor_symbol() > > to %pF some time ago (c9bbb4abb658da "PCI: use %pF instead > > of print_fn_descriptor_symbol() in quirks.c"). kallsyms

Re: block: oopses on 4.13.*, 4.14.* and 4.15-rc2 (bisected)

On Fri, Dec 08, 2017 at 01:08:37PM -0700, Jens Axboe wrote: > On 12/08/2017 08:38 AM, Michele Ballabio wrote: > > Hi, > > kernels 4.13.*, 4.14.* 4.15-rc2 crash on occasion, especially > > on x86-32 systems. To trigger the problem, run as root: > > > > while true > > do > >

Re: block: oopses on 4.13.*, 4.14.* and 4.15-rc2 (bisected)

On Fri, Dec 08, 2017 at 01:08:37PM -0700, Jens Axboe wrote: > On 12/08/2017 08:38 AM, Michele Ballabio wrote: > > Hi, > > kernels 4.13.*, 4.14.* 4.15-rc2 crash on occasion, especially > > on x86-32 systems. To trigger the problem, run as root: > > > > while true > > do > >

Re: [PATCH] platform/x86: intel-vbtn: Simplify autorelease logic

On Sat, Dec 09, 2017 at 12:28:18AM +0100, Stefan Brüns wrote: > On Saturday, December 9, 2017 12:07:08 AM CET Darren Hart (VMware) wrote: > > The new notify_handler logic determining if autorelease should be used or > > not is a bit awkward, and can result in more than one call to > >

Re: [PATCH] platform/x86: intel-vbtn: Simplify autorelease logic

On Sat, Dec 09, 2017 at 12:28:18AM +0100, Stefan Brüns wrote: > On Saturday, December 9, 2017 12:07:08 AM CET Darren Hart (VMware) wrote: > > The new notify_handler logic determining if autorelease should be used or > > not is a bit awkward, and can result in more than one call to > >

<    1   2   3   4   5   6   7   8   9   10   >