Re: [RFC PATCH 2/2] rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()

On 07/05/2016 01:46 PM, Krzysztof Kozlowski wrote: On 07/04/2016 01:03 PM, Alim Akhtar wrote: As per code flow it is possible that s3c_rtc_setfreq() might get called with rtc clock disabled and in set_freq we perform h/w registers read/write, which might results in a kernel crash while

Re: [RFC PATCH 2/2] rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()

On 07/05/2016 01:46 PM, Krzysztof Kozlowski wrote: On 07/04/2016 01:03 PM, Alim Akhtar wrote: As per code flow it is possible that s3c_rtc_setfreq() might get called with rtc clock disabled and in set_freq we perform h/w registers read/write, which might results in a kernel crash while

Re: [RFC PATCH 1/2] rtc: s3c: Remove unnecessary call to disable already disabled clock

On 07/05/2016 10:46 AM, Alim Akhtar wrote: > Hi Krzsztof, > > On 07/05/2016 12:48 PM, Krzysztof Kozlowski wrote: >> On 07/04/2016 01:03 PM, Alim Akhtar wrote: >>> At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called >>> with rtc >>> clock already disabled, which looks extra and

Re: [RFC PATCH 1/2] rtc: s3c: Remove unnecessary call to disable already disabled clock

On 07/05/2016 10:46 AM, Alim Akhtar wrote: > Hi Krzsztof, > > On 07/05/2016 12:48 PM, Krzysztof Kozlowski wrote: >> On 07/04/2016 01:03 PM, Alim Akhtar wrote: >>> At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called >>> with rtc >>> clock already disabled, which looks extra and

Re: [RFC PATCH 1/2] rtc: s3c: Remove unnecessary call to disable already disabled clock

Hi Krzsztof, On 07/05/2016 12:48 PM, Krzysztof Kozlowski wrote: On 07/04/2016 01:03 PM, Alim Akhtar wrote: At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called with rtc clock already disabled, which looks extra and unnecessary call. Lets clean it up. Does not look right. Till

Re: [RFC PATCH 1/2] rtc: s3c: Remove unnecessary call to disable already disabled clock

Hi Krzsztof, On 07/05/2016 12:48 PM, Krzysztof Kozlowski wrote: On 07/04/2016 01:03 PM, Alim Akhtar wrote: At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called with rtc clock already disabled, which looks extra and unnecessary call. Lets clean it up. Does not look right. Till

Re: [PATCH v2] checkkconfigsymbols.py: add --no-color option, don't print color to non-TTY

Hi Andrew, I am fine with this version of the patch, thanks. Usually patches to this script go through Greg's misc tree. Best regards, Valentin On Tue, Jul 5, 2016 at 9:47 AM, Andrew Donnellan wrote: > Only print the ANSI colour escape codes if stdout is a TTY.

Re: [PATCH v2] checkkconfigsymbols.py: add --no-color option, don't print color to non-TTY

Hi Andrew, I am fine with this version of the patch, thanks. Usually patches to this script go through Greg's misc tree. Best regards, Valentin On Tue, Jul 5, 2016 at 9:47 AM, Andrew Donnellan wrote: > Only print the ANSI colour escape codes if stdout is a TTY. Useful if > redirecting output

Re: [PATCH] pinctrl: sunxi: fix nand0 function name for sun8i

On Mon, Jul 04, 2016 at 10:29:31AM +0800, Icenowy Zheng wrote: > In sun4/5/6/7i, all the pin function related to NAND0 controller is > named "nand0". However, in sun8i, some of the functions are named as > "nand". This patch renamed them to "nand0", for the consistency. > > Signed-off-by: Icenowy

Re: [PATCH] pinctrl: sunxi: fix nand0 function name for sun8i

On Mon, Jul 04, 2016 at 10:29:31AM +0800, Icenowy Zheng wrote: > In sun4/5/6/7i, all the pin function related to NAND0 controller is > named "nand0". However, in sun8i, some of the functions are named as > "nand". This patch renamed them to "nand0", for the consistency. > > Signed-off-by: Icenowy

Re: [PATCH] perf: fix pmu::filter_match for SW-led groups

On Mon, Jul 04, 2016 at 07:05:35PM +0100, Mark Rutland wrote: > On Sat, Jul 02, 2016 at 06:40:25PM +0200, Peter Zijlstra wrote: > > One of the ways I was looking at getting that done is a virtual runtime > > scheduler (just like cfs). The tricky point is merging two virtual > > runtime trees. But

Re: [PATCH] perf: fix pmu::filter_match for SW-led groups

On Mon, Jul 04, 2016 at 07:05:35PM +0100, Mark Rutland wrote: > On Sat, Jul 02, 2016 at 06:40:25PM +0200, Peter Zijlstra wrote: > > One of the ways I was looking at getting that done is a virtual runtime > > scheduler (just like cfs). The tricky point is merging two virtual > > runtime trees. But

Re: portable device tree connector -- problem statement

On Mon, Jul 04, 2016 at 01:58:53PM -0700, Frank Rowand wrote: > On the other hand, I have no previous detailed knowledge of the beagle > family. This is in no way specific to the BeagleBones, there's plenty of other boards out there with similar setups like the Raspberry Pi and its derivatives.

Re: portable device tree connector -- problem statement

On Mon, Jul 04, 2016 at 01:58:53PM -0700, Frank Rowand wrote: > On the other hand, I have no previous detailed knowledge of the beagle > family. This is in no way specific to the BeagleBones, there's plenty of other boards out there with similar setups like the Raspberry Pi and its derivatives.

Re: linux-next: build failure after merge of the tip tree (from the drm-intel tree)

On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote: > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index d3502c0603e5..1f91f187b2a8 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3290,7 +3290,7 @@

Re: linux-next: build failure after merge of the tip tree (from the drm-intel tree)

On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote: > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index d3502c0603e5..1f91f187b2a8 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3290,7 +3290,7 @@

Re: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

On Thu, 2016-06-30 at 15:58 +, Dexuan Cui wrote: > Hyper-V Sockets (hv_sock) supplies a byte-stream based communication > mechanism between the host and the guest. It's somewhat like TCP over > VMBus, but the transportation layer (VMBus) is much simpler than IP. trivia: > diff --git

Re: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

On Thu, 2016-06-30 at 15:58 +, Dexuan Cui wrote: > Hyper-V Sockets (hv_sock) supplies a byte-stream based communication > mechanism between the host and the guest. It's somewhat like TCP over > VMBus, but the transportation layer (VMBus) is much simpler than IP. trivia: > diff --git

Re: [PATCH 3/6] Clocksource: add nuc970 clocksource driver

On 2016年06月28日 03:46, Daniel Lezcano wrote: On 06/25/2016 12:37 PM, Wan Zongshun wrote: This patch is to add nuc970 clocksource driver support. Hi Wan, add a detailed description of how works this timer and its general design. If there is a pointer or a reference to a manual that would be

Re: [PATCH 3/6] Clocksource: add nuc970 clocksource driver

On 2016年06月28日 03:46, Daniel Lezcano wrote: On 06/25/2016 12:37 PM, Wan Zongshun wrote: This patch is to add nuc970 clocksource driver support. Hi Wan, add a detailed description of how works this timer and its general design. If there is a pointer or a reference to a manual that would be

Re: [RFC PATCH 2/2] rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()

On 07/04/2016 01:03 PM, Alim Akhtar wrote: > As per code flow it is possible that s3c_rtc_setfreq() might get called > with rtc clock disabled and in set_freq we perform h/w registers read/write, > which might results in a kernel crash while probing rtc driver. > Below is one such case: >

Re: [RFC PATCH 2/2] rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()

On 07/04/2016 01:03 PM, Alim Akhtar wrote: > As per code flow it is possible that s3c_rtc_setfreq() might get called > with rtc clock disabled and in set_freq we perform h/w registers read/write, > which might results in a kernel crash while probing rtc driver. > Below is one such case: >

Re: [PATCH 01/31] mm, vmstat: add infrastructure for per-node vmstats

On Tue, Jul 05, 2016 at 08:50:18AM +0900, Minchan Kim wrote: > > @@ -172,13 +174,17 @@ void refresh_zone_stat_thresholds(void) > > int threshold; > > > > for_each_populated_zone(zone) { > > + struct pglist_data *pgdat = zone->zone_pgdat; > > unsigned long max_drift,

Re: [PATCH 01/31] mm, vmstat: add infrastructure for per-node vmstats

On Tue, Jul 05, 2016 at 08:50:18AM +0900, Minchan Kim wrote: > > @@ -172,13 +174,17 @@ void refresh_zone_stat_thresholds(void) > > int threshold; > > > > for_each_populated_zone(zone) { > > + struct pglist_data *pgdat = zone->zone_pgdat; > > unsigned long max_drift,

Re: Subject: PROBLEM: CPU accounting/scheduling regression in v4.6 CPU scheduling patchset?

On Sun, Jul 03, 2016 at 05:24:11PM +, Vladimir Panteleev wrote: > dmesg output: > https://dump.v.panteleev.md/b8a3ba608a914a3d70667dad697dddfb/1467563818.log [0.059350] smpboot: CPU0: Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz (family: 0x6, model: 0x3e, stepping: 0x4) ... [0.069372]

Re: Subject: PROBLEM: CPU accounting/scheduling regression in v4.6 CPU scheduling patchset?

On Sun, Jul 03, 2016 at 05:24:11PM +, Vladimir Panteleev wrote: > dmesg output: > https://dump.v.panteleev.md/b8a3ba608a914a3d70667dad697dddfb/1467563818.log [0.059350] smpboot: CPU0: Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz (family: 0x6, model: 0x3e, stepping: 0x4) ... [0.069372]

Re: [PATCH v5 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

On Tuesday, July 5, 2016 10:42:41 AM CEST Shawn Lin wrote: > +config PCIE_ROCKCHIP > + tristate "Rockchip PCIe controller" > + depends on ARM64 && ARCH_ROCKCHIP > + depends on OF > + select MFD_SYSCON > + select PCI_MSI_IRQ_DOMAIN if PCI_MSI Please use "depends on

Re: [PATCH v5 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

On Tuesday, July 5, 2016 10:42:41 AM CEST Shawn Lin wrote: > +config PCIE_ROCKCHIP > + tristate "Rockchip PCIe controller" > + depends on ARM64 && ARCH_ROCKCHIP > + depends on OF > + select MFD_SYSCON > + select PCI_MSI_IRQ_DOMAIN if PCI_MSI Please use "depends on

Re: [alsa-devel] [PATCH 3/4] ASoC: mediatek: add BT implementation

On Tue, Jul 05, 2016 at 09:52:13AM +0800, Garlic Tseng wrote: > On Mon, 2016-07-04 at 16:44 +0200, Mark Brown wrote: > > We really shouldn't be writing the registers or other internal data of > > the device. Instead we should be getting the driver for the relevant > > hardware component to do

Re: [alsa-devel] [PATCH 3/4] ASoC: mediatek: add BT implementation

On Tue, Jul 05, 2016 at 09:52:13AM +0800, Garlic Tseng wrote: > On Mon, 2016-07-04 at 16:44 +0200, Mark Brown wrote: > > We really shouldn't be writing the registers or other internal data of > > the device. Instead we should be getting the driver for the relevant > > hardware component to do

RE: [PATCH 2/2] qe/ic: refactor qe_ic to simplify

On 07/05/2016 11:51 AM, Jason Cooper wrote: > -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Tuesday, July 05, 2016 11:51 AM > To: Qiang Zhao > Cc: o...@buserror.net; t...@linutronix.de; marc.zyng...@arm.com;

RE: [PATCH 2/2] qe/ic: refactor qe_ic to simplify

On 07/05/2016 11:51 AM, Jason Cooper wrote: > -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Tuesday, July 05, 2016 11:51 AM > To: Qiang Zhao > Cc: o...@buserror.net; t...@linutronix.de; marc.zyng...@arm.com; linuxppc- > d...@lists.ozlabs.org;

[PATCH net] r8152: fix runtime function for RTL8152

The RTL8152 doesn't have U1U2 and U2P3 features, so use different runtime functions for RTL812 and RTL8153 by adding autosuspend_en() to rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 24 +--- 1 file changed, 17 insertions(+), 7

[PATCH net] r8152: fix runtime function for RTL8152

The RTL8152 doesn't have U1U2 and U2P3 features, so use different runtime functions for RTL812 and RTL8153 by adding autosuspend_en() to rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git

Re: [PATCH 31/31] mm, vmstat: Remove zone and node double accounting by approximating retries

> > The number of LRU pages, dirty pages and writeback pages must be accounted > for on both zones and nodes because of the reclaim retry logic, compaction > retry logic and highmem calculations all depending on per-zone stats. > > The retry logic is only critical for allocations that can use

Re: [PATCH 31/31] mm, vmstat: Remove zone and node double accounting by approximating retries

> > The number of LRU pages, dirty pages and writeback pages must be accounted > for on both zones and nodes because of the reclaim retry logic, compaction > retry logic and highmem calculations all depending on per-zone stats. > > The retry logic is only critical for allocations that can use

Re: [PATCH 4/6] irqchip: add irqchip driver for nuc900

On Tuesday, July 5, 2016 3:47:25 PM CEST Wan Zongshun wrote: > On 2016年06月29日 23:27, Arnd Bergmann wrote: > > On Saturday, June 25, 2016 6:37:20 PM CEST Wan Zongshun wrote: > >> +#define IRQ_WDT W90X900_IRQ(1) > >> +#define IRQ_WWDTW90X900_IRQ(2) > >> +#define IRQ_LVD

Re: [PATCH 4/6] irqchip: add irqchip driver for nuc900

On Tuesday, July 5, 2016 3:47:25 PM CEST Wan Zongshun wrote: > On 2016年06月29日 23:27, Arnd Bergmann wrote: > > On Saturday, June 25, 2016 6:37:20 PM CEST Wan Zongshun wrote: > >> +#define IRQ_WDT W90X900_IRQ(1) > >> +#define IRQ_WWDTW90X900_IRQ(2) > >> +#define IRQ_LVD

Re: [PATCH 1/6] ARM: NUC900: Add nuc970 machine support

On Tuesday, July 5, 2016 3:38:23 PM CEST Wan Zongshun wrote: > On 2016年06月29日 23:19, Arnd Bergmann wrote: > >> diff --git a/arch/arm/mach-w90x900/include/mach/nuc970-regs-gcr.h > >> b/arch/arm/mach-w90x900/include/mach/nuc970-regs-gcr.h > >> new file mode 100644 > >> index 000..e7eb653 > >>

Re: [PATCH 1/6] ARM: NUC900: Add nuc970 machine support

On Tuesday, July 5, 2016 3:38:23 PM CEST Wan Zongshun wrote: > On 2016年06月29日 23:19, Arnd Bergmann wrote: > >> diff --git a/arch/arm/mach-w90x900/include/mach/nuc970-regs-gcr.h > >> b/arch/arm/mach-w90x900/include/mach/nuc970-regs-gcr.h > >> new file mode 100644 > >> index 000..e7eb653 > >>

Re: [RFC] arm64: kexec_file_load support

On Mon, Jul 04, 2016 at 07:50:19PM -0300, Thiago Jung Bauermann wrote: > Hello, > > Am Montag, 04 Juli 2016, 15:58:15 schrieb AKASHI Takahiro: > > On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote: > > > I agree that it would be better if we could have a system call where a >

Re: [RFC] arm64: kexec_file_load support

On Mon, Jul 04, 2016 at 07:50:19PM -0300, Thiago Jung Bauermann wrote: > Hello, > > Am Montag, 04 Juli 2016, 15:58:15 schrieb AKASHI Takahiro: > > On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote: > > > I agree that it would be better if we could have a system call where a >

Re: [RFC] arm64: kexec_file_load support

Hi Dave, On Tue, Jul 05, 2016 at 09:25:56AM +0800, Dave Young wrote: > On 07/04/16 at 03:58pm, AKASHI Takahiro wrote: > > Hi, > > > > On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote: > > > Am Freitag, 01 Juli 2016, 14:11:12 schrieb AKASHI Takahiro: > > > > I'm not sure

Re: [RFC] arm64: kexec_file_load support

Hi Dave, On Tue, Jul 05, 2016 at 09:25:56AM +0800, Dave Young wrote: > On 07/04/16 at 03:58pm, AKASHI Takahiro wrote: > > Hi, > > > > On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote: > > > Am Freitag, 01 Juli 2016, 14:11:12 schrieb AKASHI Takahiro: > > > > I'm not sure

Re: [PATCH 0/3] clocksource: timer-atmel-pit: driver cleanup

Le 05/07/2016 00:12, Alexandre Belloni a écrit : > Hi, > > Here are a few cleanups I had laying around for a while. I rebased and > tested on top of 4.7-rc1. > > The series will apply after: > "clocksource: timer-atmel-pit: enable mck" > > > Alexandre Belloni (3): > clocksource:

Re: [PATCH 0/3] clocksource: timer-atmel-pit: driver cleanup

Le 05/07/2016 00:12, Alexandre Belloni a écrit : > Hi, > > Here are a few cleanups I had laying around for a while. I rebased and > tested on top of 4.7-rc1. > > The series will apply after: > "clocksource: timer-atmel-pit: enable mck" > > > Alexandre Belloni (3): > clocksource:

Re: kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

On Tue, Jul 05, 2016 at 11:00:21AM +0800, AceLan Kao wrote: > These are logs from my machine. > > *** Before plug-in the USB key > > u@u-XPS-13-9xxx:~$ sudo lspci - -s 00:1c.0 > 00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1) (prog-if 00 > [Normal decode]) [...] >

Re: kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

On Tue, Jul 05, 2016 at 11:00:21AM +0800, AceLan Kao wrote: > These are logs from my machine. > > *** Before plug-in the USB key > > u@u-XPS-13-9xxx:~$ sudo lspci - -s 00:1c.0 > 00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1) (prog-if 00 > [Normal decode]) [...] >

Re: [PATCH] clocksource: timer-atmel-pit: enable mck

Le 04/07/2016 22:24, Boris Brezillon a écrit : > On Mon, 4 Jul 2016 18:00:09 +0200 > Alexandre Belloni wrote: > >> mck is needed to get the PIT working. Explicitly prepare_enable it instead >> of assuming it is enabled. >> >> This solves an issue were the

Re: [PATCH 4/6] irqchip: add irqchip driver for nuc900

On 2016年06月29日 23:27, Arnd Bergmann wrote: On Saturday, June 25, 2016 6:37:20 PM CEST Wan Zongshun wrote: +#define IRQ_WDTW90X900_IRQ(1) +#define IRQ_WWDT W90X900_IRQ(2) +#define IRQ_LVDW90X900_IRQ(3) +#define IRQ_EXT0 W90X900_IRQ(4) +#define

Re: [PATCH] clocksource: timer-atmel-pit: enable mck

Le 04/07/2016 22:24, Boris Brezillon a écrit : > On Mon, 4 Jul 2016 18:00:09 +0200 > Alexandre Belloni wrote: > >> mck is needed to get the PIT working. Explicitly prepare_enable it instead >> of assuming it is enabled. >> >> This solves an issue were the system is freezing when the ETM/ETB

Re: [PATCH 4/6] irqchip: add irqchip driver for nuc900

On 2016年06月29日 23:27, Arnd Bergmann wrote: On Saturday, June 25, 2016 6:37:20 PM CEST Wan Zongshun wrote: +#define IRQ_WDTW90X900_IRQ(1) +#define IRQ_WWDT W90X900_IRQ(2) +#define IRQ_LVDW90X900_IRQ(3) +#define IRQ_EXT0 W90X900_IRQ(4) +#define

[PATCH v2] checkkconfigsymbols.py: add --no-color option, don't print color to non-TTY

Only print the ANSI colour escape codes if stdout is a TTY. Useful if redirecting output to a file or piping to another script. Also add a new option, --no-color, if the user wants to disable colour output for whatever reason. Signed-off-by: Andrew Donnellan ---

[PATCH v2] checkkconfigsymbols.py: add --no-color option, don't print color to non-TTY

Only print the ANSI colour escape codes if stdout is a TTY. Useful if redirecting output to a file or piping to another script. Also add a new option, --no-color, if the user wants to disable colour output for whatever reason. Signed-off-by: Andrew Donnellan --- V1->V2: -

[PATCH] [RFC] pmem: add pmem support codes on ARM64

The PMEM driver on top of NVDIMM(Non-Volatile DIMM) has already been supported on X86_64 and there exist several ARM64 platforms which support DIMM type memories. This patch set enables the PMEM driver on ARM64 (AArch64) architecture on top of NVDIMM. While developing this patch set, QEMU 2.6.50

[PATCH] [RFC] pmem: add pmem support codes on ARM64

The PMEM driver on top of NVDIMM(Non-Volatile DIMM) has already been supported on X86_64 and there exist several ARM64 platforms which support DIMM type memories. This patch set enables the PMEM driver on ARM64 (AArch64) architecture on top of NVDIMM. While developing this patch set, QEMU 2.6.50

Re: [PATCH 3/6] Clocksource: add nuc970 clocksource driver

On 2016年06月29日 23:25, Arnd Bergmann wrote: On Saturday, June 25, 2016 6:37:19 PM CEST Wan Zongshun wrote: This patch is to add nuc970 clocksource driver support. Signed-off-by: Wan Zongshun --- .../mach-w90x900/include/mach/nuc970-regs-timer.h | 44 +

Re: [PATCH 3/6] Clocksource: add nuc970 clocksource driver

On 2016年06月29日 23:25, Arnd Bergmann wrote: On Saturday, June 25, 2016 6:37:19 PM CEST Wan Zongshun wrote: This patch is to add nuc970 clocksource driver support. Signed-off-by: Wan Zongshun --- .../mach-w90x900/include/mach/nuc970-regs-timer.h | 44 + drivers/clocksource/Kconfig

Re: [PATCH 2/3] iio: adc: add support for Allwinner SoCs ADC

On 04/07/2016 18:29, Guenter Roeck wrote: > On 07/04/2016 12:26 AM, Quentin Schulz wrote: >> On 03/07/2016 17:43, Guenter Roeck wrote: >>> On 07/03/2016 04:54 AM, Jonathan Cameron wrote: On 28/06/16 09:18, Quentin Schulz wrote: > The Allwinner SoCs all have an ADC that can also act as a

Re: [PATCH 2/3] iio: adc: add support for Allwinner SoCs ADC

On 04/07/2016 18:29, Guenter Roeck wrote: > On 07/04/2016 12:26 AM, Quentin Schulz wrote: >> On 03/07/2016 17:43, Guenter Roeck wrote: >>> On 07/03/2016 04:54 AM, Jonathan Cameron wrote: On 28/06/16 09:18, Quentin Schulz wrote: > The Allwinner SoCs all have an ADC that can also act as a

Re: [PATCH 1/6] ARM: NUC900: Add nuc970 machine support

On 2016年06月29日 23:19, Arnd Bergmann wrote: On Saturday, June 25, 2016 6:37:17 PM CEST Wan Zongshun wrote: NUC970 is a new SoC of Nuvoton nuc900 series, this patch is to add machine file support for it. Signed-off-by: Wan Zongshun Nice to see some activity on the port!

Re: [PATCH 1/6] ARM: NUC900: Add nuc970 machine support

On 2016年06月29日 23:19, Arnd Bergmann wrote: On Saturday, June 25, 2016 6:37:17 PM CEST Wan Zongshun wrote: NUC970 is a new SoC of Nuvoton nuc900 series, this patch is to add machine file support for it. Signed-off-by: Wan Zongshun Nice to see some activity on the port! ---

Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

2016-06-30 3:07 GMT+08:00 Juri Lelli : > setup_new_dl_entity() takes two parameters, but it only actually uses > one of them, under a different name, to setup a new dl_entity, after: > > 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity" > > as we

Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

2016-06-30 3:07 GMT+08:00 Juri Lelli : > setup_new_dl_entity() takes two parameters, but it only actually uses > one of them, under a different name, to setup a new dl_entity, after: > > 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity" > > as we currently do > >

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

Yury Norov writes: > ABI details: > - types are taken from AARCH32, next types turned to 64-bit, >as modern requirement for new APIs tells: > ino_t is u64 type > off_t is s64 type > blkcnt_t is s64 type > fsblkcnt_t is u64

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

Yury Norov writes: > ABI details: > - types are taken from AARCH32, next types turned to 64-bit, >as modern requirement for new APIs tells: > ino_t is u64 type > off_t is s64 type > blkcnt_t is s64 type > fsblkcnt_t is u64 type > fsfilcnt_t is

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Tue, Jul 05, 2016 at 02:26:46PM +0800, Xiao Guangrong wrote: > > > On 07/05/2016 01:16 PM, Neo Jia wrote: > >On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote: > >> > >> > >>On 07/05/2016 09:35 AM, Neo Jia wrote: > >>>On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Tue, Jul 05, 2016 at 02:26:46PM +0800, Xiao Guangrong wrote: > > > On 07/05/2016 01:16 PM, Neo Jia wrote: > >On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote: > >> > >> > >>On 07/05/2016 09:35 AM, Neo Jia wrote: > >>>On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong

Re: [PATCH 2/4] dt-bindings: Document the STM32 reset bindings

Hi Philipp, On 07/04/2016 07:36 PM, Philipp Zabel wrote: Am Montag, den 04.07.2016, 15:47 +0200 schrieb gabriel.fernan...@st.com: From: Maxime Coquelin This adds documentation of device tree bindings for the STM32 reset controller. Signed-off-by: Maxime Coquelin

Re: [PATCH 2/4] dt-bindings: Document the STM32 reset bindings

Hi Philipp, On 07/04/2016 07:36 PM, Philipp Zabel wrote: Am Montag, den 04.07.2016, 15:47 +0200 schrieb gabriel.fernan...@st.com: From: Maxime Coquelin This adds documentation of device tree bindings for the STM32 reset controller. Signed-off-by: Maxime Coquelin The way I understand

Re: [PATCH 3/4] drivers: reset: Add STM32 reset driver

Hi Philipp, Thanks for reviewing. On 07/04/2016 07:36 PM, Philipp Zabel wrote: Hi Gabriel, Am Montag, den 04.07.2016, 15:47 +0200 schrieb gabriel.fernan...@st.com: From: Gabriel Fernandez Isn't Maxime the author of this driver? Yes i upstream with his agreement.

Re: [PATCH 3/4] drivers: reset: Add STM32 reset driver

Hi Philipp, Thanks for reviewing. On 07/04/2016 07:36 PM, Philipp Zabel wrote: Hi Gabriel, Am Montag, den 04.07.2016, 15:47 +0200 schrieb gabriel.fernan...@st.com: From: Gabriel Fernandez Isn't Maxime the author of this driver? Yes i upstream with his agreement. I only made small

Re: [PATCH 30/31] mm, vmstat: print node-based stats in zoneinfo file

> > There are a number of stats that were previously accessible via zoneinfo > that are now invisible. While it is possible to create a new file for the > node stats, this may be missed by users. Instead this patch prints the > stats under the first populated zone in /proc/zoneinfo. > >

Re: [PATCH 30/31] mm, vmstat: print node-based stats in zoneinfo file

> > There are a number of stats that were previously accessible via zoneinfo > that are now invisible. While it is possible to create a new file for the > node stats, this may be missed by users. Instead this patch prints the > stats under the first populated zone in /proc/zoneinfo. > >

Re: checkkconfigsymbols.py: add --no-color option

On 04/07/16 22:24, Josh Triplett wrote: Rather than requiring an explicit option, how about detecting whether stdout is a TTY and automatically suppressing color? You could check "os.isatty(1)" in main(), and set a global "color = False". That would automatically handle the cases of redirecting

Re: checkkconfigsymbols.py: add --no-color option

On 04/07/16 22:24, Josh Triplett wrote: Rather than requiring an explicit option, how about detecting whether stdout is a TTY and automatically suppressing color? You could check "os.isatty(1)" in main(), and set a global "color = False". That would automatically handle the cases of redirecting

Re: [PATCH 6/7] gpu: drm: sun4i_drv: add missing of_node_put after calling of_parse_phandle

On Tue, Jul 05, 2016 at 10:04:53AM +0800, Peter Chen wrote: > of_node_put needs to be called when the device node which is got > from of_parse_phandle has finished using. > > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Signed-off-by: Peter Chen

Re: [PATCH 6/7] gpu: drm: sun4i_drv: add missing of_node_put after calling of_parse_phandle

On Tue, Jul 05, 2016 at 10:04:53AM +0800, Peter Chen wrote: > of_node_put needs to be called when the device node which is got > from of_parse_phandle has finished using. > > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Signed-off-by: Peter Chen Applied, thanks! Maxime -- Maxime Ripard, Free

Re: [RFC PATCH 1/2] rtc: s3c: Remove unnecessary call to disable already disabled clock

On 07/04/2016 01:03 PM, Alim Akhtar wrote: > At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called with rtc > clock already disabled, which looks extra and unnecessary call. > Lets clean it up. Does not look right. Till that place, the clocks are enabled. Then s3c_rtc_setaie() is

Re: [RFC PATCH 1/2] rtc: s3c: Remove unnecessary call to disable already disabled clock

On 07/04/2016 01:03 PM, Alim Akhtar wrote: > At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called with rtc > clock already disabled, which looks extra and unnecessary call. > Lets clean it up. Does not look right. Till that place, the clocks are enabled. Then s3c_rtc_setaie() is

Re: [PATCH 24/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to compaction_ready

> > The scan_control structure has enough information available for > compaction_ready() to make a decision. The classzone_idx manipulations in > shrink_zones() are no longer necessary as the highest populated zone is > no longer used to determine if shrink_slab should be called or not. > >

Re: [PATCH 23/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to shrink_node

> > shrink_node receives all information it needs about classzone_idx > from sc->reclaim_idx so remove the aliases. > > Signed-off-by: Mel Gorman > --- Acked-by: Hillf Danton > mm/vmscan.c | 20 +--- > 1 file changed, 9

Re: [PATCH 24/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to compaction_ready

> > The scan_control structure has enough information available for > compaction_ready() to make a decision. The classzone_idx manipulations in > shrink_zones() are no longer necessary as the highest populated zone is > no longer used to determine if shrink_slab should be called or not. > >

Re: [PATCH 23/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to shrink_node

> > shrink_node receives all information it needs about classzone_idx > from sc->reclaim_idx so remove the aliases. > > Signed-off-by: Mel Gorman > --- Acked-by: Hillf Danton > mm/vmscan.c | 20 +--- > 1 file changed, 9 insertions(+), 11 deletions(-) >

Re: [v2,1/2] refactor code parsing size based on memory range

On 07/05/2016 10:48 AM, Michael Ellerman wrote: On 06/24/2016 10:56 AM, Michael Ellerman wrote: On Wed, 2016-22-06 at 19:25:26 UTC, Hari Bathini wrote: ... While the code is moved to kernel/params.c file, there is no change in logic for crashkernel parameter parsing as the moved code is

Re: [v2,1/2] refactor code parsing size based on memory range

On 07/05/2016 10:48 AM, Michael Ellerman wrote: On 06/24/2016 10:56 AM, Michael Ellerman wrote: On Wed, 2016-22-06 at 19:25:26 UTC, Hari Bathini wrote: ... While the code is moved to kernel/params.c file, there is no change in logic for crashkernel parameter parsing as the moved code is

Re: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

From: Dexuan Cui Date: Tue, 5 Jul 2016 06:46:24 + >> From: David Miller [mailto:da...@davemloft.net] >> Sent: Tuesday, July 5, 2016 14:27 >> To: Dexuan Cui >> Subject: Re: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets >> >> From:

Re: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

From: Dexuan Cui Date: Tue, 5 Jul 2016 06:46:24 + >> From: David Miller [mailto:da...@davemloft.net] >> Sent: Tuesday, July 5, 2016 14:27 >> To: Dexuan Cui >> Subject: Re: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets >> >> From: Dexuan Cui >> Date: Tue, 5 Jul 2016 01:58:31

Re: [PATCH 21/31] mm, page_alloc: Wake kswapd based on the highest eligible zone

> > The ac_classzone_idx is used as the basis for waking kswapd and that is based > on the preferred zoneref. If the preferred zoneref's highest zone is lower > than what is available on other nodes, it's possible that kswapd is woken > on a zone with only higher, but still eligible, zones. As

Re: [PATCH 21/31] mm, page_alloc: Wake kswapd based on the highest eligible zone

> > The ac_classzone_idx is used as the basis for waking kswapd and that is based > on the preferred zoneref. If the preferred zoneref's highest zone is lower > than what is available on other nodes, it's possible that kswapd is woken > on a zone with only higher, but still eligible, zones. As

Re: [PATCH] net-next: mediatek: remove superfluous free_irq() call

From: John Crispin Date: Mon, 4 Jul 2016 15:37:10 +0200 > Commit 8067302973a1 ("net-next: mediatek: add support for IRQ grouping") > adds handling for irq 1 and 2 to the uninit function but did not remove > irq 0 which is not used since irq grouping was introduced. Fix this by

Re: [PATCH] net-next: mediatek: remove superfluous free_irq() call

From: John Crispin Date: Mon, 4 Jul 2016 15:37:10 +0200 > Commit 8067302973a1 ("net-next: mediatek: add support for IRQ grouping") > adds handling for irq 1 and 2 to the uninit function but did not remove > irq 0 which is not used since irq grouping was introduced. Fix this by > removing the

[PATCH 0/3] perf tools: Add hist_entry allocation callbacks

hi, this patchset tries to add support provide own allocation zalloc/free methods for hist_entry object. v2 changes: - merged patch 1 and 2 from RFC The reason is to provide a way to be able to store more data within hist_entry object in a transparent way to its current usage by allocating its

[PATCH 3/3] perf tools: Introduce hists__add_entry_ops function

Introducing hists__add_entry_ops function to allow using the allocation callbacks externally. Link: http://lkml.kernel.org/n/tip-r4bumbbg5st7p38hjm2z1...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/util/hist.c | 42 +++---

[PATCH 0/3] perf tools: Add hist_entry allocation callbacks

hi, this patchset tries to add support provide own allocation zalloc/free methods for hist_entry object. v2 changes: - merged patch 1 and 2 from RFC The reason is to provide a way to be able to store more data within hist_entry object in a transparent way to its current usage by allocating its

[PATCH 3/3] perf tools: Introduce hists__add_entry_ops function

Introducing hists__add_entry_ops function to allow using the allocation callbacks externally. Link: http://lkml.kernel.org/n/tip-r4bumbbg5st7p38hjm2z1...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/util/hist.c | 42 +++--- tools/perf/util/hist.h |

[PATCH 2/3] perf tools: Introduce hist_entry_ops

Introducing allocation callbacks, that allows to extend current hist_entry object into objects with special needs without polluting the current hist_entry object. Link: http://lkml.kernel.org/n/tip-yvapb3gmmn01qo7qn9lzl...@git.kernel.org Signed-off-by: Jiri Olsa ---

[PATCH 1/3] perf tools: Introduce hist_entry__init function

Move hist_entry initialization code into separate function. It'll be useful and more clear for following patches that introduce allocation callbacks. Releasing the hist_entry object in hist_entry__new function (where it's allocated) rather than in hist_entry__init. Link:

[PATCH 2/3] perf tools: Introduce hist_entry_ops

Introducing allocation callbacks, that allows to extend current hist_entry object into objects with special needs without polluting the current hist_entry object. Link: http://lkml.kernel.org/n/tip-yvapb3gmmn01qo7qn9lzl...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/util/hist.c | 31

[PATCH 1/3] perf tools: Introduce hist_entry__init function

Move hist_entry initialization code into separate function. It'll be useful and more clear for following patches that introduce allocation callbacks. Releasing the hist_entry object in hist_entry__new function (where it's allocated) rather than in hist_entry__init. Link:

<    8   9   10   11   12   13   14   >