RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

Hi > -Original Message- > From: 李書帆 [mailto:leechu...@gmail.com] > Sent: 2018年3月12日 13:22 > To: Jun Li > Cc: Greg Kroah-Hartman ; > heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com; > shufan_...@richtek.com;

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

Hi > -Original Message- > From: 李書帆 [mailto:leechu...@gmail.com] > Sent: 2018年3月12日 13:22 > To: Jun Li > Cc: Greg Kroah-Hartman ; > heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com; > shufan_...@richtek.com; cy_hu...@richtek.com; > linux-kernel@vger.kernel.org;

Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

Hi Tobin, > "Tobin C. Harding" hat am 12. März 2018 um 06:46 geschrieben: > > > On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. The array > > here is fixed (declared with a const variable) but

Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

Hi Tobin, > "Tobin C. Harding" hat am 12. März 2018 um 06:46 geschrieben: > > > On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. The array > > here is fixed (declared with a const variable) but it appears like

Re: [PATCH V2] ZBOOT: fix stack protector in compressed boot phase

Hi Huacai, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180309] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH V2] ZBOOT: fix stack protector in compressed boot phase

Hi Huacai, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180309] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 0/2] mtd: use put_device() if device_register fail

On Monday 12 March 2018 01:05 AM, Richard Weinberger wrote: Am Freitag, 9. März 2018, 11:50:47 CET schrieb Arvind Yadav: if device_register() returned an error! Always use put_device() to give up the reference initialized. Arvind Yadav (2): [PATCH 1/2] mtd: use put_device() if

Re: [PATCH 0/2] mtd: use put_device() if device_register fail

On Monday 12 March 2018 01:05 AM, Richard Weinberger wrote: Am Freitag, 9. März 2018, 11:50:47 CET schrieb Arvind Yadav: if device_register() returned an error! Always use put_device() to give up the reference initialized. Arvind Yadav (2): [PATCH 1/2] mtd: use put_device() if

Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote: > The kernel would like to have all stack VLA usage removed[1]. The array > here is fixed (declared with a const variable) but it appears like a VLA > to the compiler. Also, currently we are putting 768 bytes on the > stack. This

Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote: > The kernel would like to have all stack VLA usage removed[1]. The array > here is fixed (declared with a const variable) but it appears like a VLA > to the compiler. Also, currently we are putting 768 bytes on the > stack. This

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

Re: smp_mb__after_spinlock requirement too strong?

On Sun, Mar 11, 2018 at 03:55:41PM +0800, 焦晓冬 wrote: > Peter pointed out in this patch https://patchwork.kernel.org/patch/9771921/ > that the spinning-lock used at __schedule() should be RCsc to ensure > visibility of writes prior to __schedule when the task is to be migrated to > another CPU. >

Re: smp_mb__after_spinlock requirement too strong?

On Sun, Mar 11, 2018 at 03:55:41PM +0800, 焦晓冬 wrote: > Peter pointed out in this patch https://patchwork.kernel.org/patch/9771921/ > that the spinning-lock used at __schedule() should be RCsc to ensure > visibility of writes prior to __schedule when the task is to be migrated to > another CPU. >

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

Hello, Rafael: 2018-03-05 16:47 GMT+08:00 Ganesh Mahendran : > single_open() interface requires that the whole output must > fit into a single buffer. This will lead to timeout when > system memory is not in a good situation. > > This patch use seq_open() to show

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

Hello, Rafael: 2018-03-05 16:47 GMT+08:00 Ganesh Mahendran : > single_open() interface requires that the whole output must > fit into a single buffer. This will lead to timeout when > system memory is not in a good situation. > > This patch use seq_open() to show wakeup stats. This method > need

[PATCH] perf: update perf_cgroup time for ancestor cgroup(s)

When a perf_event is attached to parent cgroup, it should count events for all children cgroups: parent_group < perf_event \ - child_group < process(es) However, in our tests, we found this perf_event cannot report reliable results. This is because perf_event->cgrp and

[PATCH] perf: update perf_cgroup time for ancestor cgroup(s)

When a perf_event is attached to parent cgroup, it should count events for all children cgroups: parent_group < perf_event \ - child_group < process(es) However, in our tests, we found this perf_event cannot report reliable results. This is because perf_event->cgrp and

Liebe Freunde

Liebe Freunde Ich habe ein Geschäft von $ 65.400.000.00 Million (fünfundsechzig Millionen, vierhunderttausend US-Dollar), die er in unserer Bank hinterlegt hat und gerade lügt, nicht beansprucht zu teilen, sollten Sie interessiert sein. Sollten Sie interessiert sein, wenden Sie sich bitte an

Liebe Freunde

Liebe Freunde Ich habe ein Geschäft von $ 65.400.000.00 Million (fünfundsechzig Millionen, vierhunderttausend US-Dollar), die er in unserer Bank hinterlegt hat und gerade lügt, nicht beansprucht zu teilen, sollten Sie interessiert sein. Sollten Sie interessiert sein, wenden Sie sich bitte an

[PATCH v2 3/3] dt-bindings: phy-mtk-tphy: add properties for U2 slew rate calibrate

Add two properties of ref_clk and coefficient used by U2 slew rate calibrate which may vary on different SoCs Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v2 2/3] phy: phy-mtk-tphy: add configurable parameters for slew rate calibrate

There are two parameters, ref_clk and coefficient, for U2 slew rate calibrate which may vary on different SoCs, here allow them to be configurable Signed-off-by: Chunfeng Yun --- drivers/phy/mediatek/phy-mtk-tphy.c | 20 +++- 1 file changed, 15

[PATCH v2 2/3] phy: phy-mtk-tphy: add configurable parameters for slew rate calibrate

There are two parameters, ref_clk and coefficient, for U2 slew rate calibrate which may vary on different SoCs, here allow them to be configurable Signed-off-by: Chunfeng Yun --- drivers/phy/mediatek/phy-mtk-tphy.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-)

[PATCH v2 3/3] dt-bindings: phy-mtk-tphy: add properties for U2 slew rate calibrate

Add two properties of ref_clk and coefficient used by U2 slew rate calibrate which may vary on different SoCs Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v2 1/3] phy: phy-mtk-tphy: keep default value of mcu_bus_ck_gate_en

The default value of mcu_bus_ck_gate_en is 1, if clear it, will prevent system to enter deep idle mode, so keep its default value and without affecting PCIe function. Signed-off-by: Chunfeng Yun --- drivers/phy/mediatek/phy-mtk-tphy.c | 3 +-- 1 file changed, 1

[PATCH v2 1/3] phy: phy-mtk-tphy: keep default value of mcu_bus_ck_gate_en

The default value of mcu_bus_ck_gate_en is 1, if clear it, will prevent system to enter deep idle mode, so keep its default value and without affecting PCIe function. Signed-off-by: Chunfeng Yun --- drivers/phy/mediatek/phy-mtk-tphy.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

Re: [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions

On Fri, Mar 09, 2018 at 12:17:07PM -0800, Paul E. McKenney wrote: > On Fri, Mar 09, 2018 at 02:57:00PM +0800, Boqun Feng wrote: > > On Thu, Mar 08, 2018 at 07:42:55AM -0800, Paul E. McKenney wrote: > > > On Thu, Mar 08, 2018 at 04:30:06PM +0800, Boqun Feng wrote: > > > > On Thu, Mar 08, 2018 at

Re: [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions

On Fri, Mar 09, 2018 at 12:17:07PM -0800, Paul E. McKenney wrote: > On Fri, Mar 09, 2018 at 02:57:00PM +0800, Boqun Feng wrote: > > On Thu, Mar 08, 2018 at 07:42:55AM -0800, Paul E. McKenney wrote: > > > On Thu, Mar 08, 2018 at 04:30:06PM +0800, Boqun Feng wrote: > > > > On Thu, Mar 08, 2018 at

Re: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

Hi Jun, Thank you. 2018-03-12 12:33 GMT+08:00 Jun Li : > Hi, > >> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) { >> + struct tcpci *tcpci = dev_id; >> + >> + return tcpci_irq(tcpci); >> +} >> > ... > >> + err = devm_request_threaded_irq(>dev, client->irq,

Re: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

Hi Jun, Thank you. 2018-03-12 12:33 GMT+08:00 Jun Li : > Hi, > >> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) { >> + struct tcpci *tcpci = dev_id; >> + >> + return tcpci_irq(tcpci); >> +} >> > ... > >> + err = devm_request_threaded_irq(>dev, client->irq, NULL, >> +

Re: [PATCH] rbd: Remove VLA stack usage

On Sun, Mar 11, 2018 at 10:02:04PM -0700, Eric Biggers wrote: > On Mon, Mar 12, 2018 at 03:49:40PM +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. > > Can you please stop writing this? The Linux kernel isn't sentient; it doesn't > "like" anything.

Re: [PATCH] rbd: Remove VLA stack usage

On Sun, Mar 11, 2018 at 10:02:04PM -0700, Eric Biggers wrote: > On Mon, Mar 12, 2018 at 03:49:40PM +1100, Tobin C. Harding wrote: > > The kernel would like to have all stack VLA usage removed[1]. > > Can you please stop writing this? The Linux kernel isn't sentient; it doesn't > "like" anything.

Re: [PATCH] rbd: Remove VLA stack usage

On Mon, Mar 12, 2018 at 03:49:40PM +1100, Tobin C. Harding wrote: > The kernel would like to have all stack VLA usage removed[1]. Can you please stop writing this? The Linux kernel isn't sentient; it doesn't "like" anything. You need to explain why *you* (and other people) believe these changes

Re: [PATCH] rbd: Remove VLA stack usage

On Mon, Mar 12, 2018 at 03:49:40PM +1100, Tobin C. Harding wrote: > The kernel would like to have all stack VLA usage removed[1]. Can you please stop writing this? The Linux kernel isn't sentient; it doesn't "like" anything. You need to explain why *you* (and other people) believe these changes

[PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH] rbd: Remove VLA saving ack buffer size

The kernel would like to have all stack VLA usage removed[1]. Here the array is declared using a variable that is declared using a constant statement but the compiler still emits a warning. We can clear the warning bu using the constant statement directly. The buffer size variable is set to

[PATCH] rbd: Remove VLA saving ack buffer size

The kernel would like to have all stack VLA usage removed[1]. Here the array is declared using a variable that is declared using a constant statement but the compiler still emits a warning. We can clear the warning bu using the constant statement directly. The buffer size variable is set to

[PATCH] rbd: Remove VLA stack usage

The kernel would like to have all stack VLA usage removed[1]. Here the array is declared using a variable that is declared using a constant statement but the compiler still emits a warning. We can clear the warning bu using the constant statement directly. In place of later usage of the size

[PATCH] rbd: Remove VLA stack usage

The kernel would like to have all stack VLA usage removed[1]. Here the array is declared using a variable that is declared using a constant statement but the compiler still emits a warning. We can clear the warning bu using the constant statement directly. In place of later usage of the size

Re: [PATCH] mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions

On Saturday 10 March 2018 05:29 PM, Linus Walleij wrote: > > But this patch doesn't hide the partition from userspace does it? > > They will still appear in /dev/mmcblk0boot1 etc. > > Just not reported as "real" partitions in /proc/partitions. > > Or do I misunderstand it? > > You are correct.

Re: [PATCH] mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions

On Saturday 10 March 2018 05:29 PM, Linus Walleij wrote: > > But this patch doesn't hide the partition from userspace does it? > > They will still appear in /dev/mmcblk0boot1 etc. > > Just not reported as "real" partitions in /proc/partitions. > > Or do I misunderstand it? > > You are correct.

Re: [PATCH v4 14/24] fpga: dfl: fme: add partial reconfiguration sub feature support

On Sun, Mar 11, 2018 at 01:09:31PM -0700, matthew.gerl...@linux.intel.com wrote: > > > On Mon, 5 Mar 2018, Alan Tull wrote: > > > Hi Hao, > > I do think we should consider different hw implementations with this code > because it does look like most of it is generic. Specifically, I think >

Re: [PATCH v4 14/24] fpga: dfl: fme: add partial reconfiguration sub feature support

On Sun, Mar 11, 2018 at 01:09:31PM -0700, matthew.gerl...@linux.intel.com wrote: > > > On Mon, 5 Mar 2018, Alan Tull wrote: > > > Hi Hao, > > I do think we should consider different hw implementations with this code > because it does look like most of it is generic. Specifically, I think >

Re: [PATCH 10/10] dt-bindings: thermal: Remove "cooling-{min|max}-level" properties

On 09-02-18, 14:28, Viresh Kumar wrote: > The "cooling-min-level" and "cooling-max-level" properties are not > parsed by any part of kernel currently and the max cooling state of a > CPU cooling device is found by referring to the cpufreq table instead. > > Remove the unused bindings. > >

Re: [PATCH 10/10] dt-bindings: thermal: Remove "cooling-{min|max}-level" properties

On 09-02-18, 14:28, Viresh Kumar wrote: > The "cooling-min-level" and "cooling-max-level" properties are not > parsed by any part of kernel currently and the max cooling state of a > CPU cooling device is found by referring to the cpufreq table instead. > > Remove the unused bindings. > >

Re: [PATCH 07/10] ARM: dts: gemini: Remove "cooling-{min|max}-level" for gpio-fan node

On 09-02-18, 14:28, Viresh Kumar wrote: > The "cooling-min-level" and "cooling-max-level" properties are not > parsed by any part of the kernel currently and the max cooling state of > gpio-fan cooling device is found by referring to the > "gpio-fan,speed-map" instead. > > Remove the unused

Re: [PATCH 07/10] ARM: dts: gemini: Remove "cooling-{min|max}-level" for gpio-fan node

On 09-02-18, 14:28, Viresh Kumar wrote: > The "cooling-min-level" and "cooling-max-level" properties are not > parsed by any part of the kernel currently and the max cooling state of > gpio-fan cooling device is found by referring to the > "gpio-fan,speed-map" instead. > > Remove the unused

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

Hi, > +static irqreturn_t _tcpci_irq(int irq, void *dev_id) { > + struct tcpci *tcpci = dev_id; > + > + return tcpci_irq(tcpci); > +} > ... > + err = devm_request_threaded_irq(>dev, client->irq, NULL, > + _tcpci_irq, >

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

Hi, > +static irqreturn_t _tcpci_irq(int irq, void *dev_id) { > + struct tcpci *tcpci = dev_id; > + > + return tcpci_irq(tcpci); > +} > ... > + err = devm_request_threaded_irq(>dev, client->irq, NULL, > + _tcpci_irq, >

Re: [PATCH 06/10] ARM64: dts: meson: Remove "cooling-{min|max}-level" for CPU nodes

On 09-02-18, 10:03, Neil Armstrong wrote: > On 09/02/2018 09:58, Viresh Kumar wrote: > > The "cooling-min-level" and "cooling-max-level" properties are not > > parsed by any part of the kernel currently and the max cooling state of > > a CPU cooling device is found by referring to the cpufreq

Re: [PATCH 06/10] ARM64: dts: meson: Remove "cooling-{min|max}-level" for CPU nodes

On 09-02-18, 10:03, Neil Armstrong wrote: > On 09/02/2018 09:58, Viresh Kumar wrote: > > The "cooling-min-level" and "cooling-max-level" properties are not > > parsed by any part of the kernel currently and the max cooling state of > > a CPU cooling device is found by referring to the cpufreq

Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

On 16-01-18, 15:22, Viresh Kumar wrote: > This extends the sysfs interface for thermal cooling devices and exposes > some pretty useful statistics. These statistics have proven to be quite > useful specially while doing benchmarks related to the task scheduler, > where we want to make sure that

Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

On 16-01-18, 15:22, Viresh Kumar wrote: > This extends the sysfs interface for thermal cooling devices and exposes > some pretty useful statistics. These statistics have proven to be quite > useful specially while doing benchmarks related to the task scheduler, > where we want to make sure that

[PATCH v9] mmc: Export host capabilities to debugfs.

This patch exports the host capabilities to debugfs This idea of sharing host capabilities over debugfs came up from Abbas Raza Earlier discussions: https://lkml.org/lkml/2018/3/5/357 https://www.spinics.net/lists/linux-mmc/msg48219.html Signed-off-by: Harish Jenny K N

[PATCH v9] mmc: Export host capabilities to debugfs.

This patch exports the host capabilities to debugfs This idea of sharing host capabilities over debugfs came up from Abbas Raza Earlier discussions: https://lkml.org/lkml/2018/3/5/357 https://www.spinics.net/lists/linux-mmc/msg48219.html Signed-off-by: Harish Jenny K N --- Changes in v9 -

[PATCH] of: unittest: Remove VLA stack usage

The kernel would like to have all stack VLA usage removed[1]. This is a test function so the execution speed is not critical. We can allocate memory for this buffer instead of using a VLA. If kmalloc() fails just return. Allocate buffer with kmalloc(). [1]: https://lkml.org/lkml/2018/3/7/621

[PATCH] of: unittest: Remove VLA stack usage

The kernel would like to have all stack VLA usage removed[1]. This is a test function so the execution speed is not critical. We can allocate memory for this buffer instead of using a VLA. If kmalloc() fails just return. Allocate buffer with kmalloc(). [1]: https://lkml.org/lkml/2018/3/7/621

[PATCH 3/4] ARM: dts: sun8i: a33: Enable PMIC power supplies on A33-OLinuXino

The A33-OLinuXino has a DC jack wired to the onboard PMIC's ACIN pins. There is also a battery connector, wired to the PMIC's battery charger. Enable the power supplies for both these components. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 8

[PATCH 2/4] ARM: dts: sun8i: a33: Drop sunxi-common-regulators.dtsi for A33-OLinuXino

None of the common regulators defined in sunxi-common-regulators.dtsi are used for the A33-OLinuXino. Drop the include. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 3/4] ARM: dts: sun8i: a33: Enable PMIC power supplies on A33-OLinuXino

The A33-OLinuXino has a DC jack wired to the onboard PMIC's ACIN pins. There is also a battery connector, wired to the PMIC's battery charger. Enable the power supplies for both these components. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 8 1 file

[PATCH 2/4] ARM: dts: sun8i: a33: Drop sunxi-common-regulators.dtsi for A33-OLinuXino

None of the common regulators defined in sunxi-common-regulators.dtsi are used for the A33-OLinuXino. Drop the include. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts

[PATCH 0/4] ARM: dts: sun8i: a33: Improvements for A33-OLinuXino

Hi, Here are some cleanup and improvements for the A33-OLinuXino device tree. The first two patches drop some unneeded bits. The latter two enable peripherals that we now support. ChenYu Chen-Yu Tsai (4): ARM: dts: sun8i: a33: Drop GPIO pinmux settings for A33-OLinuXino ARM: dts: sun8i:

[PATCH 1/4] ARM: dts: sun8i: a33: Drop GPIO pinmux settings for A33-OLinuXino

Normal GPIO usage does not need an additional pinmix setting. Exclusive usage of the pin will be guaranteed by the driver. Drop the extra pinmux settings. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 23 +-- 1 file changed, 1

[PATCH 0/4] ARM: dts: sun8i: a33: Improvements for A33-OLinuXino

Hi, Here are some cleanup and improvements for the A33-OLinuXino device tree. The first two patches drop some unneeded bits. The latter two enable peripherals that we now support. ChenYu Chen-Yu Tsai (4): ARM: dts: sun8i: a33: Drop GPIO pinmux settings for A33-OLinuXino ARM: dts: sun8i:

[PATCH 1/4] ARM: dts: sun8i: a33: Drop GPIO pinmux settings for A33-OLinuXino

Normal GPIO usage does not need an additional pinmix setting. Exclusive usage of the pin will be guaranteed by the driver. Drop the extra pinmux settings. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 23 +-- 1 file changed, 1 insertion(+), 22

[PATCH 4/4] ARM: dts: sun8i: a33: Enable A33 internal audio codec on A33-OLinuXino

The A33-OLinuXino routes the SoC's headphone output to a headphone jack, and the microphone input to a microphone jack. Power to the microphone is provided by MBIAS. This patch enables the various parts of the codec, and adds widgets and routes for simple-card. HBIAS is connected to the

[PATCH 4/4] ARM: dts: sun8i: a33: Enable A33 internal audio codec on A33-OLinuXino

The A33-OLinuXino routes the SoC's headphone output to a headphone jack, and the microphone input to a microphone jack. Power to the microphone is provided by MBIAS. This patch enables the various parts of the codec, and adds widgets and routes for simple-card. HBIAS is connected to the

[PATCH] ARM: dts: sun8i: reference tablet design: Enable PMIC power supplies

The A23/A33 reference tablet design has a DC barrel tied to the ACIN of the PMIC. And being a tablet, it has a Li-Po battery. Enable both power supplies in the device tree. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 8 1 file

[PATCH] ARM: dts: sun8i: reference tablet design: Enable PMIC power supplies

The A23/A33 reference tablet design has a DC barrel tied to the ACIN of the PMIC. And being a tablet, it has a Li-Po battery. Enable both power supplies in the device tree. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 8 1 file changed, 8

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

On Sun, Mar 11, 2018 at 11:24:38PM +, Ian Armstrong wrote: > On Sat, 10 Mar 2018 16:57:41 + > "French, Nicholas A." wrote: > > > > > No what if the framebuffer driver is just requested as a > > > > secondary step after firmware loading? > > > > > > Its a possibility. The

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

On Sun, Mar 11, 2018 at 11:24:38PM +, Ian Armstrong wrote: > On Sat, 10 Mar 2018 16:57:41 + > "French, Nicholas A." wrote: > > > > > No what if the framebuffer driver is just requested as a > > > > secondary step after firmware loading? > > > > > > Its a possibility. The decoder

Re: [pci PATCH v4 1/4] pci-iov: Add support for unmanaged SR-IOV

On Thu, 08 Mar 2018 11:02:29 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > This patch is meant to add some basic functionality to support for SR-IOV > on devices when the VFs are not managed by some other entity in the device >

Re: [pci PATCH v4 1/4] pci-iov: Add support for unmanaged SR-IOV

On Thu, 08 Mar 2018 11:02:29 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > This patch is meant to add some basic functionality to support for SR-IOV > on devices when the VFs are not managed by some other entity in the device > other than the kernel. > > A new sysfs value called

Re: [RFC PATCH v2 00/12] Rewrite asm-generic/bitops/{atomic,lock}.h and use on arm64

Hi Will, 2018-03-01 16:16 GMT+09:00 Masahiro Yamada : > 2018-02-27 0:04 GMT+09:00 Will Deacon : >> Hi everyone, >> >> This is version two of the RFC I previously posted here: >> >> https://www.spinics.net/lists/arm-kernel/msg634719.html >> >>

Re: [RFC PATCH v2 00/12] Rewrite asm-generic/bitops/{atomic,lock}.h and use on arm64

Hi Will, 2018-03-01 16:16 GMT+09:00 Masahiro Yamada : > 2018-02-27 0:04 GMT+09:00 Will Deacon : >> Hi everyone, >> >> This is version two of the RFC I previously posted here: >> >> https://www.spinics.net/lists/arm-kernel/msg634719.html >> >> Changes since v1 include: >> >> * Fixed

[PATCH 3.2 000/104] 3.2.101-rc1 review

This is the start of the stable review cycle for the 3.2.101 release. There are 104 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 14 12:00:00 UTC 2018. Anything

[PATCH 3.2 000/104] 3.2.101-rc1 review

This is the start of the stable review cycle for the 3.2.101 release. There are 104 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 14 12:00:00 UTC 2018. Anything

[PATCH 3.2 005/104] ath6kl: fix uninitialized variable in ath6kl_sdio_enable_scatter()

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit 527f6570300980251e818e80865b437eefb4e5d3 upstream. gcc 4.8 warns /backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c: In function

[PATCH 3.2 005/104] ath6kl: fix uninitialized variable in ath6kl_sdio_enable_scatter()

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit 527f6570300980251e818e80865b437eefb4e5d3 upstream. gcc 4.8 warns /backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c: In function

[PATCH 3.2 004/104] brcm80211: Remove bogus memcpy in ai_detach

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit af2c8ffe56133928355d1d51978b35115ffbbc2a upstream. gcc 4.8 warns for this memcpy. While the copy size is correct, the whole copy seems to be a nop

[PATCH 3.2 004/104] brcm80211: Remove bogus memcpy in ai_detach

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit af2c8ffe56133928355d1d51978b35115ffbbc2a upstream. gcc 4.8 warns for this memcpy. While the copy size is correct, the whole copy seems to be a nop because the destination is

[PATCH 3.2 009/104] rtl8192c:dm: Properly initialize local array and set value.

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Han Shen commit 7c8f0db0d024efda38976fc2acf7743f458e1d96 upstream. GCC 4.8 is spitting out uninitialized-variable warnings against

[PATCH 3.2 009/104] rtl8192c:dm: Properly initialize local array and set value.

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Han Shen commit 7c8f0db0d024efda38976fc2acf7743f458e1d96 upstream. GCC 4.8 is spitting out uninitialized-variable warnings against "drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c". This

[PATCH 3.2 103/104] x86: fix build warnign with 32-bit PAE

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann I ran into a 4.9 build warning in randconfig testing, starting with the KAISER patches: arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':

[PATCH 3.2 103/104] x86: fix build warnign with 32-bit PAE

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann I ran into a 4.9 build warning in randconfig testing, starting with the KAISER patches: arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':

[PATCH 3.2 001/104] brcmfmac: work-around gcc 4.7 build issue

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Alexandre Oliva commit 5addc0de28f5e286f9d121112c450807b5a5 upstream. Alexandre Oliva says: "It's an issue brought about by GCC 4.7's

[PATCH 3.2 001/104] brcmfmac: work-around gcc 4.7 build issue

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Alexandre Oliva commit 5addc0de28f5e286f9d121112c450807b5a5 upstream. Alexandre Oliva says: "It's an issue brought about by GCC 4.7's partial-inlining, that ends up splitting the udelay

[PATCH 3.2 012/104] usb: renesas_usbhs: fixup __usbhs_for_each_pipe 1st pos

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Kuninori Morimoto commit c2fa3edc58a262dfcb7aea78e24661e90e00098c upstream. __usbhs_for_each_pipe() is the macro which moves around each pipe, but it has a

[PATCH 3.2 008/104] rtlwifi: rtl8192de: Fix W=1 build warnings

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Larry Finger commit 8925d518663628f769173d3586c66987fdd3ab61 upstream. when this driver is built with "make W=1", the following warning is printed:

[PATCH 3.2 012/104] usb: renesas_usbhs: fixup __usbhs_for_each_pipe 1st pos

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Kuninori Morimoto commit c2fa3edc58a262dfcb7aea78e24661e90e00098c upstream. __usbhs_for_each_pipe() is the macro which moves around each pipe, but it has a bug which didn't care about 1st

[PATCH 3.2 008/104] rtlwifi: rtl8192de: Fix W=1 build warnings

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Larry Finger commit 8925d518663628f769173d3586c66987fdd3ab61 upstream. when this driver is built with "make W=1", the following warning is printed:

[PATCH 3.2 015/104] gcov: add support for gcc 4.7 gcov format

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Frantisek Hrbata commit 5f41ea0386a53414d688cfcaa321a78310e5f7c1 upstream. The gcov in-memory format changed in gcc 4.7. The biggest change, which requires this special

[PATCH 3.2 015/104] gcov: add support for gcc 4.7 gcov format

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Frantisek Hrbata commit 5f41ea0386a53414d688cfcaa321a78310e5f7c1 upstream. The gcov in-memory format changed in gcc 4.7. The biggest change, which requires this special implementation, is

[PATCH 3.2 003/104] rtlwifi: rtl8192se: Fix gcc 4.7.x warning

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Larry Finger commit f761b6947dde42890beea59b020e1be87491809e upstream. With gcc 4.7.x, the following warning is issued as the routine that sets the array has the

[PATCH 3.2 003/104] rtlwifi: rtl8192se: Fix gcc 4.7.x warning

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Larry Finger commit f761b6947dde42890beea59b020e1be87491809e upstream. With gcc 4.7.x, the following warning is issued as the routine that sets the array has the possibility of not

[PATCH 3.2 013/104] usb: renesas_usbhs: tidyup original usbhsx_for_each_xxx macro

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Kuninori Morimoto commit 925403f425a4a9c503f2fc295652647b1eb10d82 upstream. Current usbhsx_for_each_xxx macro will read out-of-array's memory after last loop

[PATCH 3.2 013/104] usb: renesas_usbhs: tidyup original usbhsx_for_each_xxx macro

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Kuninori Morimoto commit 925403f425a4a9c503f2fc295652647b1eb10d82 upstream. Current usbhsx_for_each_xxx macro will read out-of-array's memory after last loop operation. It was not good C

  1   2   3   4   5   6   7   8   9   10   >