[RFC2 PATCH 00/23] ARM64: support ILP32

This series enables aarch64 port with ilp32 mode. 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

Re: [PATCH v4 3/4] perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver

Hi Mark, On Tue, Jun 28, 2016 at 7:14 AM, Mark Rutland wrote: > On Tue, Jun 28, 2016 at 02:21:38PM +0100, Marc Zyngier wrote: >> On 28/06/16 12:13, Mark Rutland wrote: >> > On Mon, Jun 27, 2016 at 10:54:07AM -0700, Tai Tri Nguyen wrote: >> >> On Mon, Jun 27, 2016 at 9:00

[RFC2 PATCH 00/23] ARM64: support ILP32

This series enables aarch64 port with ilp32 mode. 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

Re: [PATCH v4 3/4] perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver

Hi Mark, On Tue, Jun 28, 2016 at 7:14 AM, Mark Rutland wrote: > On Tue, Jun 28, 2016 at 02:21:38PM +0100, Marc Zyngier wrote: >> On 28/06/16 12:13, Mark Rutland wrote: >> > On Mon, Jun 27, 2016 at 10:54:07AM -0700, Tai Tri Nguyen wrote: >> >> On Mon, Jun 27, 2016 at 9:00 AM, Mark Rutland >> >>

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

(adding Mathias Krause who did something similar via macros in 2014) https://lkml.org/lkml/2014/6/22/149 On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. The kernel already has > a mechanism to free up code and data memory that is only

Re: [PATCH v1 0/2] Introduce the initify gcc plugin

(adding Mathias Krause who did something similar via macros in 2014) https://lkml.org/lkml/2014/6/22/149 On Tue, 2016-06-28 at 13:34 +0200, Emese Revfy wrote: > I would like to introduce the initify gcc plugin. The kernel already has > a mechanism to free up code and data memory that is only

Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman wrote: > Before this patch, passing a range that is beyond the physical memory > range will succeed, the user will see a /dev/pmem0 and will be able to > access it. Reads will always return 0 and writes will be silently > ignored.

Re: [v3 PATCH 1/5] extcon: Add Type-C and DP support

On Tue, Jun 28, 2016 at 5:26 AM, Chanwoo Choi wrote: > Hi Chris, > > I agree to add the new EXTCON_DISP_DP connector. > But, other new definition should be discussed. > - EXTCON_DISP_DP_ALT > - EXTCON_TYPEC_POLARITY > - EXTCON_TYPEC_PIN_ASSIGN > > I think that TYPEC_POLARITY

Re: [RESEND PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman wrote: > Before this patch, passing a range that is beyond the physical memory > range will succeed, the user will see a /dev/pmem0 and will be able to > access it. Reads will always return 0 and writes will be silently > ignored. > > I've gotten more

Re: [v3 PATCH 1/5] extcon: Add Type-C and DP support

On Tue, Jun 28, 2016 at 5:26 AM, Chanwoo Choi wrote: > Hi Chris, > > I agree to add the new EXTCON_DISP_DP connector. > But, other new definition should be discussed. > - EXTCON_DISP_DP_ALT > - EXTCON_TYPEC_POLARITY > - EXTCON_TYPEC_PIN_ASSIGN > > I think that TYPEC_POLARITY and TYPEC_PIN_ASSING

Re: [PATCH 1/2] clk: clk-rk3*: set CLK_IS_CRITICAL flag to critical clocks

Hi Andi, Am Mittwoch, 29. Juni 2016, 01:09:22 schrieb Andi Shyti: > > > RK2928_CLKSEL_CON(0), 14, 2, MFLAGS, 8, 5, DFLAGS), > > > > > > - GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", CLK_IGNORE_UNUSED, > > > + GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", > > > +

Re: [PATCH v2] mm: oom: deduplicate victim selection code for memcg and global oom

On Mon, Jun 27, 2016 at 05:14:31PM -0700, David Rientjes wrote: > On Mon, 27 Jun 2016, Vladimir Davydov wrote: > > > When selecting an oom victim, we use the same heuristic for both memory > > cgroup and global oom. The only difference is the scope of tasks to > > select the victim from. So we

Re: [PATCH 1/2] clk: clk-rk3*: set CLK_IS_CRITICAL flag to critical clocks

Hi Andi, Am Mittwoch, 29. Juni 2016, 01:09:22 schrieb Andi Shyti: > > > RK2928_CLKSEL_CON(0), 14, 2, MFLAGS, 8, 5, DFLAGS), > > > > > > - GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", CLK_IGNORE_UNUSED, > > > + GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", > > > +

Re: [PATCH v2] mm: oom: deduplicate victim selection code for memcg and global oom

On Mon, Jun 27, 2016 at 05:14:31PM -0700, David Rientjes wrote: > On Mon, 27 Jun 2016, Vladimir Davydov wrote: > > > When selecting an oom victim, we use the same heuristic for both memory > > cgroup and global oom. The only difference is the scope of tasks to > > select the victim from. So we

Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child()

On Tue, 28 Jun 2016, SF Markus Elfring wrote: > >> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client > >> *client, const char *name, > >>status = platform_device_add_resources(pdev, , 1); > >>if (status < 0) { > >>dev_dbg(>dev,

Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child()

On Tue, 28 Jun 2016, SF Markus Elfring wrote: > >> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client > >> *client, const char *name, > >>status = platform_device_add_resources(pdev, , 1); > >>if (status < 0) { > >>dev_dbg(>dev,

Re: [PATCH v5] clk: tegra: Initialize UTMIPLL when enabling PLLU

Hi Rhyland, On 27/06/16 19:11, Rhyland Klein wrote: > Jonathan, can you confirm replacing usleep_range(100, 200) with udelay(2) > works for you? Yes for me, using a udelay(2) does seem to work. I have made sure that a usb device is still detected on the Jetson TX1. However, I am not sure the

Re: [PATCH v5] clk: tegra: Initialize UTMIPLL when enabling PLLU

Hi Rhyland, On 27/06/16 19:11, Rhyland Klein wrote: > Jonathan, can you confirm replacing usleep_range(100, 200) with udelay(2) > works for you? Yes for me, using a udelay(2) does seem to work. I have made sure that a usb device is still detected on the Jetson TX1. However, I am not sure the

Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

On Tue, Jun 28, 2016 at 04:33:46PM +0100, Catalin Marinas wrote: > On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote: > > +#define CPUINFO_ATTR_RO(_name) > > \ > > + static ssize_t show_##_name(struct device *dev,

Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

On Tue, Jun 28, 2016 at 04:33:46PM +0100, Catalin Marinas wrote: > On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote: > > +#define CPUINFO_ATTR_RO(_name) > > \ > > + static ssize_t show_##_name(struct device *dev,

Re: [PATCH v2 04/14] regulator: SY8106A regulator driver

On 27.6.2016 16:54, Mark Brown wrote: > On Sun, Jun 26, 2016 at 05:07:16PM +0200, Ondřej Jirman wrote: >> On 26.6.2016 13:26, Mark Brown wrote: > >>> I'm missing almost all of this series, I've just got this and another >>> patch which look like a standalone driver so it's hard to see any >>>

Re: [PATCH v3 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

On Fri, 24 Jun 2016, Ksenija Stanojevic wrote: > Add core files for mxs-lradc MFD driver. > > Note: this patch won't compile in iio/testing without this patch: > a8f447be8056 ("mfd: Add resource managed APIs for mfd_add_devices") > > Signed-off-by: Ksenija Stanojevic

Re: [PATCH v2 04/14] regulator: SY8106A regulator driver

On 27.6.2016 16:54, Mark Brown wrote: > On Sun, Jun 26, 2016 at 05:07:16PM +0200, Ondřej Jirman wrote: >> On 26.6.2016 13:26, Mark Brown wrote: > >>> I'm missing almost all of this series, I've just got this and another >>> patch which look like a standalone driver so it's hard to see any >>>

Re: [PATCH v3 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

On Fri, 24 Jun 2016, Ksenija Stanojevic wrote: > Add core files for mxs-lradc MFD driver. > > Note: this patch won't compile in iio/testing without this patch: > a8f447be8056 ("mfd: Add resource managed APIs for mfd_add_devices") > > Signed-off-by: Ksenija Stanojevic > Acked-by: Jonathan

Re: [Open-FCoE] [PATCH] MAINTAINERS: Change FCoE maintainer

On Thu, 2016-06-23 at 10:22 +0200, Johannes Thumshirn wrote: > Vasu is going to resign from his maintainer role and I'll take over. > > Signed-off-by: Johannes Thumshirn > --- >  MAINTAINERS | 2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, 28 Jun 2016 17:34:34 +0200 Jiri Olsa wrote: > When using trace_printk for cpumask I've got wrong results, > some bitmaps were completely different from what I expected. > > Currently you get wrong results when using trace_printk > on local cpumask, like: > > void

Re: [Open-FCoE] [PATCH] MAINTAINERS: Change FCoE maintainer

On Thu, 2016-06-23 at 10:22 +0200, Johannes Thumshirn wrote: > Vasu is going to resign from his maintainer role and I'll take over. > > Signed-off-by: Johannes Thumshirn > --- >  MAINTAINERS | 2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS >

Re: [RFC/PATCH] lib/vsprintf: Add support to store cpumask

On Tue, 28 Jun 2016 17:34:34 +0200 Jiri Olsa wrote: > When using trace_printk for cpumask I've got wrong results, > some bitmaps were completely different from what I expected. > > Currently you get wrong results when using trace_printk > on local cpumask, like: > > void test(void) > { >

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On 28 June 2016 at 17:51, Mark Brown wrote: > On Tue, Jun 28, 2016 at 02:40:41PM +0200, Michal Suchanek wrote: > >> There is no hardware other than pin header. You are preparing a >> factory image for a devboard with a pin header that can be used for >> connecting SPI devices.

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On 28 June 2016 at 17:51, Mark Brown wrote: > On Tue, Jun 28, 2016 at 02:40:41PM +0200, Michal Suchanek wrote: > >> There is no hardware other than pin header. You are preparing a >> factory image for a devboard with a pin header that can be used for >> connecting SPI devices. Some devices have

Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

On 28/06/16 16:33, Catalin Marinas wrote: On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote: +#define CPUINFO_ATTR_RO(_name) \ + static ssize_t show_##_name(struct device *dev, \ +

Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

On 28/06/16 16:33, Catalin Marinas wrote: On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote: +#define CPUINFO_ATTR_RO(_name) \ + static ssize_t show_##_name(struct device *dev, \ +

Re: [PATCH v2] input: tablet: pegasus_notetaker: USB PM fixes

Am 2016-06-23 um 19:18 schrieb Dmitry Torokhov: > Hi Martin, > > On Tue, Jun 14, 2016 at 01:20:15PM +0200, Martin Kepplinger wrote: >> static int pegasus_reset_resume(struct usb_interface *intf) >> { >> +struct pegasus *pegasus = usb_get_intfdata(intf); >> + >> +if (pegasus->dev->users)

Re: [PATCH v2] input: tablet: pegasus_notetaker: USB PM fixes

Am 2016-06-23 um 19:18 schrieb Dmitry Torokhov: > Hi Martin, > > On Tue, Jun 14, 2016 at 01:20:15PM +0200, Martin Kepplinger wrote: >> static int pegasus_reset_resume(struct usb_interface *intf) >> { >> +struct pegasus *pegasus = usb_get_intfdata(intf); >> + >> +if (pegasus->dev->users)

RE: [PATCH 3/4] perf annotate: add powerpc support

From: Ravi Bangoria > Sent: 28 June 2016 12:37 > > Powerpc has long list of branch instructions and hardcoding them in table > appears to be error-prone. So, add new function to find instruction > instead of creating table. > > Signed-off-by: Naveen N. Rao >

RE: [PATCH 3/4] perf annotate: add powerpc support

From: Ravi Bangoria > Sent: 28 June 2016 12:37 > > Powerpc has long list of branch instructions and hardcoding them in table > appears to be error-prone. So, add new function to find instruction > instead of creating table. > > Signed-off-by: Naveen N. Rao > Signed-off-by: Ravi Bangoria > ---

Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 28 Jun 2016 13:57:49 +0100 Mark Rutland wrote: > On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > > This patch set is based on the "Add support for complex gcc plugins that > > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > >

Re: [kernel-hardening] [PATCH v1 0/2] Introduce the initify gcc plugin

On Tue, 28 Jun 2016 13:57:49 +0100 Mark Rutland wrote: > On Tue, Jun 28, 2016 at 01:34:07PM +0200, Emese Revfy wrote: > > This patch set is based on the "Add support for complex gcc plugins that > > don't fit in a single file" patch set (git/kees/linux.git#kspp HEAD: > > e5d4798b284cd192c8b). >

Re: [PATCH 1/2] clk: clk-rk3*: set CLK_IS_CRITICAL flag to critical clocks

Hi Heiko, > > RK2928_CLKSEL_CON(0), 14, 2, MFLAGS, 8, 5, DFLAGS), > > - GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", CLK_IGNORE_UNUSED, > > + GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", > > + CLK_IS_CRITICAL | CLK_IGNORE_UNUSED, > > - you'll never need both

Re: [PATCH 1/2] clk: clk-rk3*: set CLK_IS_CRITICAL flag to critical clocks

Hi Heiko, > > RK2928_CLKSEL_CON(0), 14, 2, MFLAGS, 8, 5, DFLAGS), > > - GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", CLK_IGNORE_UNUSED, > > + GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_src", > > + CLK_IS_CRITICAL | CLK_IGNORE_UNUSED, > > - you'll never need both

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington wrote: > Hi Tomasz, > > On 06/28/2016 03:54 AM, Tomasz Nowicki wrote: > >> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c >> new file mode 100644 >> index 000..fb2b184 >> --- /dev/null >>

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington wrote: > Hi Tomasz, > > On 06/28/2016 03:54 AM, Tomasz Nowicki wrote: > >> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c >> new file mode 100644 >> index 000..fb2b184 >> --- /dev/null >> +++

Re: [RFC PATCH 0/4] ARM: remove big.LITTLE switcher support

On Tue, 28 Jun 2016, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, June 27, 2016 03:49:44 PM Nicolas Pitre wrote: > > On Mon, 27 Jun 2016, Bartlomiej Zolnierkiewicz wrote: > > > > > Hi, > > > > > > It seems that in mainline kernel big.LITTLE switcher support > > > may be usable only

Re: [RFC PATCH 0/4] ARM: remove big.LITTLE switcher support

On Tue, 28 Jun 2016, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, June 27, 2016 03:49:44 PM Nicolas Pitre wrote: > > On Mon, 27 Jun 2016, Bartlomiej Zolnierkiewicz wrote: > > > > > Hi, > > > > > > It seems that in mainline kernel big.LITTLE switcher support > > > may be usable only

[PATCH] audit: move audit_get_tty to reduce scope and kabi changes

The only users of audit_get_tty and audit_put_tty are internal to audit, so move it out of include/linux/audit.h to kernel.h and create a proper function rather than inlining it. This also reduces kABI changes. Suggested-by: Paul Moore Signed-off-by: Richard Guy Briggs

[PATCH] audit: move audit_get_tty to reduce scope and kabi changes

The only users of audit_get_tty and audit_put_tty are internal to audit, so move it out of include/linux/audit.h to kernel.h and create a proper function rather than inlining it. This also reduces kABI changes. Suggested-by: Paul Moore Signed-off-by: Richard Guy Briggs ---

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

On Mon, Jun 27, 2016 at 9:53 PM, Douglas Anderson wrote: > The original commit adding support for continuous voltage mode didn't > handle the regulator ramp delay properly. It treated the delay as a > fixed delay in uS despite the property being defined as uV / uS. Let's

Re: [PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

On Mon, Jun 27, 2016 at 9:53 PM, Douglas Anderson wrote: > The original commit adding support for continuous voltage mode didn't > handle the regulator ramp delay properly. It treated the delay as a > fixed delay in uS despite the property being defined as uV / uS. Let's > adjust it. Luckily

[PATCH] audit: move calcs after alloc and check when logging set loginuid

Move the calculations of values after the allocation in case the allocation fails. This avoids wasting effort in the rare case that it fails, but more importantly saves us extra logic to release the tty ref. Signed-off-by: Richard Guy Briggs --- kernel/auditsc.c |7 ---

[PATCH] audit: move calcs after alloc and check when logging set loginuid

Move the calculations of values after the allocation in case the allocation fails. This avoids wasting effort in the rare case that it fails, but more importantly saves us extra logic to release the tty ref. Signed-off-by: Richard Guy Briggs --- kernel/auditsc.c |7 --- 1 files

Re: RFC: out-of-tree tty driver breakage (changing ASYNC_ bits)

On 2016-06-28, Grant Edwards wrote: > On 2016-06-28, Grant Edwards wrote: >> On 2016-01-11, Peter Hurley wrote: >>> On 01/11/2016 07:53 AM, Grant Edwards wrote: On 2016-01-11, Greg KH

Re: RFC: out-of-tree tty driver breakage (changing ASYNC_ bits)

On 2016-06-28, Grant Edwards wrote: > On 2016-06-28, Grant Edwards wrote: >> On 2016-01-11, Peter Hurley wrote: >>> On 01/11/2016 07:53 AM, Grant Edwards wrote: On 2016-01-11, Greg KH wrote: > On Sun, Jan 10, 2016 at 01:42:44PM -0800, Peter Hurley wrote: > >> This will break

Re: [PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

hi, Any further comments or reviews? On Mon, Jun 20, 2016 at 11:23 AM, Vinay Simha BN wrote: > Add support for the JDI LT070ME05000 WUXGA DSI panel used in > Nexus 7 2013 devices. > > Programming sequence for the panel is was originally found in the >

Re: [PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

hi, Any further comments or reviews? On Mon, Jun 20, 2016 at 11:23 AM, Vinay Simha BN wrote: > Add support for the JDI LT070ME05000 WUXGA DSI panel used in > Nexus 7 2013 devices. > > Programming sequence for the panel is was originally found in the > android-msm-flo-3.4-lollipop-release branch

Re: [PATCH v2 1/2] drm/dsi: Implement dcs set/get display brightness

hi, Any further comments or reviews? On Mon, Jun 20, 2016 at 11:23 AM, Vinay Simha BN wrote: > Provide a small convenience wrapper that set/get the > display brightness value > > Cc: John Stultz > Cc: Sumit Semwal > Cc:

Re: [PATCH v2 1/2] drm/dsi: Implement dcs set/get display brightness

hi, Any further comments or reviews? On Mon, Jun 20, 2016 at 11:23 AM, Vinay Simha BN wrote: > Provide a small convenience wrapper that set/get the > display brightness value > > Cc: John Stultz > Cc: Sumit Semwal > Cc: Archit Taneja > Cc: Rob Clark > Cc: Jani Nikula > Cc: Thierry Reding

Re: [PATCH] media: s5p-mfc fix memory leak in s5p_mfc_remove()

On 06/28/2016 07:39 AM, Shuah Khan wrote: > On 06/28/2016 03:57 AM, Kamil Debski wrote: >> HI Shuah, >> >> Which branch do you base your patches on? >> >> I have trouble applying this path >> (https://patchwork.linuxtv.org/patch/34577/) and >> "s5p-mfc fix null pointer deference in

Re: [PATCH] media: s5p-mfc fix memory leak in s5p_mfc_remove()

On 06/28/2016 07:39 AM, Shuah Khan wrote: > On 06/28/2016 03:57 AM, Kamil Debski wrote: >> HI Shuah, >> >> Which branch do you base your patches on? >> >> I have trouble applying this path >> (https://patchwork.linuxtv.org/patch/34577/) and >> "s5p-mfc fix null pointer deference in

Re: RFC: out-of-tree tty driver breakage (changing ASYNC_ bits)

On 2016-06-28, Grant Edwards wrote: > On 2016-01-11, Peter Hurley wrote: >> On 01/11/2016 07:53 AM, Grant Edwards wrote: >>> On 2016-01-11, Greg KH wrote: On Sun, Jan 10, 2016 at 01:42:44PM -0800, Peter Hurley

Re: RFC: out-of-tree tty driver breakage (changing ASYNC_ bits)

On 2016-06-28, Grant Edwards wrote: > On 2016-01-11, Peter Hurley wrote: >> On 01/11/2016 07:53 AM, Grant Edwards wrote: >>> On 2016-01-11, Greg KH wrote: On Sun, Jan 10, 2016 at 01:42:44PM -0800, Peter Hurley wrote: > This will break out-of-tree drivers but I don't really see a

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Tue, Jun 28, 2016 at 02:40:41PM +0200, Michal Suchanek wrote: > There is no hardware other than pin header. You are preparing a > factory image for a devboard with a pin header that can be used for > connecting SPI devices. Some devices have fine kernel drivers and for > these you prepare fine

Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

On Tue, Jun 28, 2016 at 02:40:41PM +0200, Michal Suchanek wrote: > There is no hardware other than pin header. You are preparing a > factory image for a devboard with a pin header that can be used for > connecting SPI devices. Some devices have fine kernel drivers and for > these you prepare fine

[PATCH v2] drm: bridge/dw-hdmi: Add support for DWC Phy

This patch adds support for the Synopsys HDMI TX Phy in bridge dw-hdmi. The init flow is the same as the Rockchip Phy so we only need to add one define and one if statement. Also, the audio infoframe was fixed to sampling frequency of 44.1k. With this patch this is now corrected. As I don't know

Re: [v4.2-rc1 Regression] usb: Enable LPM for USB 2.01+ full-speed devices

On 06/28/2016 11:40 AM, Alan Stern wrote: > On Tue, 28 Jun 2016, Joseph Salisbury wrote: > >> On 06/24/2016 08:06 AM, Joseph Salisbury wrote: >>> On 06/22/2016 12:14 PM, Greg KH wrote: On Wed, Jun 22, 2016 at 11:38:43AM -0400, Joseph Salisbury wrote: > Hi Rupesh, > > A kernel bug

[PATCH v2] drm: bridge/dw-hdmi: Add support for DWC Phy

This patch adds support for the Synopsys HDMI TX Phy in bridge dw-hdmi. The init flow is the same as the Rockchip Phy so we only need to add one define and one if statement. Also, the audio infoframe was fixed to sampling frequency of 44.1k. With this patch this is now corrected. As I don't know

Re: [v4.2-rc1 Regression] usb: Enable LPM for USB 2.01+ full-speed devices

On 06/28/2016 11:40 AM, Alan Stern wrote: > On Tue, 28 Jun 2016, Joseph Salisbury wrote: > >> On 06/24/2016 08:06 AM, Joseph Salisbury wrote: >>> On 06/22/2016 12:14 PM, Greg KH wrote: On Wed, Jun 22, 2016 at 11:38:43AM -0400, Joseph Salisbury wrote: > Hi Rupesh, > > A kernel bug

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

On 06/28/2016 02:59 AM, Dexuan Cui wrote: The idea here is: IMO the syscalls sys_read()/write() shoudn't return -ENOMEM, so I have to make sure the buffer allocation succeeds? I tried to use kmalloc with __GFP_NOFAIL, but I hit a warning in in mm/page_alloc.c: WARN_ON_ONCE((gfp_flags &

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

On 06/28/2016 02:59 AM, Dexuan Cui wrote: The idea here is: IMO the syscalls sys_read()/write() shoudn't return -ENOMEM, so I have to make sure the buffer allocation succeeds? I tried to use kmalloc with __GFP_NOFAIL, but I hit a warning in in mm/page_alloc.c: WARN_ON_ONCE((gfp_flags &

Re: [RFC PATCH 00/27] ARM64: support ILP32

On Tue, Jun 21, 2016 at 08:06:18PM +0800, Zhangjian (Bamvor) wrote: > Hi, > > > In our test, we need to fix stack pointer in makecontext. Not sure > if it should be a standalone patch: Could you resend it? It seems, the format is broken: yury@yury-N73SV:~/work/toolchain/glibc$ git am

Re: [RFC PATCH 00/27] ARM64: support ILP32

On Tue, Jun 21, 2016 at 08:06:18PM +0800, Zhangjian (Bamvor) wrote: > Hi, > > > In our test, we need to fix stack pointer in makecontext. Not sure > if it should be a standalone patch: Could you resend it? It seems, the format is broken: yury@yury-N73SV:~/work/toolchain/glibc$ git am

Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child()

>> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client >> *client, const char *name, >> status = platform_device_add_resources(pdev, , 1); >> if (status < 0) { >> dev_dbg(>dev, "can't add irq\n"); >> -goto err;

Re: [PATCH 4/6] mfd: dm355evm_msp: Refactoring for add_child()

>> @@ -222,19 +222,21 @@ static struct device *add_child(struct i2c_client >> *client, const char *name, >> status = platform_device_add_resources(pdev, , 1); >> if (status < 0) { >> dev_dbg(>dev, "can't add irq\n"); >> -goto err;

Re: RFC: out-of-tree tty driver breakage (changing ASYNC_ bits)

On 2016-01-11, Peter Hurley wrote: > On 01/11/2016 07:53 AM, Grant Edwards wrote: >> On 2016-01-11, Greg KH wrote: >>> On Sun, Jan 10, 2016 at 01:42:44PM -0800, Peter Hurley wrote: >>> This will break out-of-tree drivers but I don't

Re: RFC: out-of-tree tty driver breakage (changing ASYNC_ bits)

On 2016-01-11, Peter Hurley wrote: > On 01/11/2016 07:53 AM, Grant Edwards wrote: >> On 2016-01-11, Greg KH wrote: >>> On Sun, Jan 10, 2016 at 01:42:44PM -0800, Peter Hurley wrote: >>> This will break out-of-tree drivers but I don't really see a realistic alternative. Also, I think the

Re: [v4.2-rc1 Regression] usb: Enable LPM for USB 2.01+ full-speed devices

On Tue, 28 Jun 2016, Joseph Salisbury wrote: > On 06/24/2016 08:06 AM, Joseph Salisbury wrote: > > On 06/22/2016 12:14 PM, Greg KH wrote: > >> On Wed, Jun 22, 2016 at 11:38:43AM -0400, Joseph Salisbury wrote: > >>> Hi Rupesh, > >>> > >>> A kernel bug report was opened against Ubuntu [0]. After a

Re: [v4.2-rc1 Regression] usb: Enable LPM for USB 2.01+ full-speed devices

On Tue, 28 Jun 2016, Joseph Salisbury wrote: > On 06/24/2016 08:06 AM, Joseph Salisbury wrote: > > On 06/22/2016 12:14 PM, Greg KH wrote: > >> On Wed, Jun 22, 2016 at 11:38:43AM -0400, Joseph Salisbury wrote: > >>> Hi Rupesh, > >>> > >>> A kernel bug report was opened against Ubuntu [0]. After a

Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support

On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote: > Hi Jan, > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote: > > This patch series provides access to various counters on the ThunderX SOC. > > > > For details of the uncore implementation see patch #1. > > > > Patches

Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support

On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote: > Hi Jan, > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote: > > This patch series provides access to various counters on the ThunderX SOC. > > > > For details of the uncore implementation see patch #1. > > > > Patches

Re: [RFC v2 3/3] dma-buf/sync_file: rework fence storage in struct file

2016-06-28 Chris Wilson : > On Tue, Jun 28, 2016 at 11:25:00AM -0300, Gustavo Padovan wrote: > > 2016-06-28 Chris Wilson : > > > > > On Mon, Jun 27, 2016 at 04:29:22PM -0300, Gustavo Padovan wrote: > > > > From: Gustavo Padovan

Re: [RFC v2 3/3] dma-buf/sync_file: rework fence storage in struct file

2016-06-28 Chris Wilson : > On Tue, Jun 28, 2016 at 11:25:00AM -0300, Gustavo Padovan wrote: > > 2016-06-28 Chris Wilson : > > > > > On Mon, Jun 27, 2016 at 04:29:22PM -0300, Gustavo Padovan wrote: > > > > From: Gustavo Padovan > > > > > > > > Create sync_file->fence to abstract the type of

[RFC/PATCH] lib/vsprintf: Add support to store cpumask

When using trace_printk for cpumask I've got wrong results, some bitmaps were completely different from what I expected. Currently you get wrong results when using trace_printk on local cpumask, like: void test(void) { struct cpumask mask; ... trace_printk("mask '%*pbl'\n",

[RFC/PATCH] lib/vsprintf: Add support to store cpumask

When using trace_printk for cpumask I've got wrong results, some bitmaps were completely different from what I expected. Currently you get wrong results when using trace_printk on local cpumask, like: void test(void) { struct cpumask mask; ... trace_printk("mask '%*pbl'\n",

Re: [PATCH] mfd: qcom_rpm: parametrize also ack selector size

On Wed, 22 Jun 2016, Linus Walleij wrote: > The RPM has two sets of selectors (IPC bit fields): request and > acknowledge. Apparently, some models use 4*32 bit words for select > and some use 7*32 bit words for request, but all use 7*32 words > for acknowledge bits. > > So apparently you can on

Re: [PATCH] mfd: qcom_rpm: parametrize also ack selector size

On Wed, 22 Jun 2016, Linus Walleij wrote: > The RPM has two sets of selectors (IPC bit fields): request and > acknowledge. Apparently, some models use 4*32 bit words for select > and some use 7*32 bit words for request, but all use 7*32 words > for acknowledge bits. > > So apparently you can on

Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote: > +#define CPUINFO_ATTR_RO(_name) > \ > + static ssize_t show_##_name(struct device *dev, > \ > + struct device_attribute

Re: [PATCH v6] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

On Tue, Jun 21, 2016 at 12:12:36PM +0100, Suzuki K. Poulose wrote: > +#define CPUINFO_ATTR_RO(_name) > \ > + static ssize_t show_##_name(struct device *dev, > \ > + struct device_attribute

Re: [PATCH -next] mfd: hi655x: Fix return value check in hi655x_pmic_probe()

On Sat, 18 Jun 2016, weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function devm_ioremap_resource() returns ERR_PTR() > and never returns NULL. The NULL test in the return value check should > be replaced with IS_ERR(). Also remove unneeded

Re: [PATCH v3 2/4] mfd: cros_ec: add EC_PWM function definitions

On Fri, 17 Jun 2016, Brian Norris wrote: > The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is > attached to the EC, rather than the main host SoC. The API provides > functionality-based (e.g., keyboard light, backlight) or index-based > addressing of the PWM(s). Duty cycles

Re: [PATCH -next] mfd: hi655x: Fix return value check in hi655x_pmic_probe()

On Sat, 18 Jun 2016, weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function devm_ioremap_resource() returns ERR_PTR() > and never returns NULL. The NULL test in the return value check should > be replaced with IS_ERR(). Also remove unneeded error handling of >

Re: [PATCH v3 2/4] mfd: cros_ec: add EC_PWM function definitions

On Fri, 17 Jun 2016, Brian Norris wrote: > The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is > attached to the EC, rather than the main host SoC. The API provides > functionality-based (e.g., keyboard light, backlight) or index-based > addressing of the PWM(s). Duty cycles

Re: [PATCH v2] mfd: twl6040: Handle mclk used for HPPLL and optional internal clock source

On Mon, 20 Jun 2016, Peter Ujfalusi wrote: > On some boards, like omap5-uevm the MCLK is gated by default and in order > to be able to use the High performance modes of twl6040 it need to be > enabled by SW. > Add support for handling the MCLK source clock via CCF. > At the same time lower the

RE: [PATCH v12 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, June 28, 2016 21:45 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com;

Re: [PATCH v2] mfd: twl6040: Handle mclk used for HPPLL and optional internal clock source

On Mon, 20 Jun 2016, Peter Ujfalusi wrote: > On some boards, like omap5-uevm the MCLK is gated by default and in order > to be able to use the High performance modes of twl6040 it need to be > enabled by SW. > Add support for handling the MCLK source clock via CCF. > At the same time lower the

RE: [PATCH v12 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, June 28, 2016 21:45 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com;

[PATCH 1/6] scripts/gdb: silence 'nothing to do' message

The constants.py generation, involves a rule to link into the main makefile. This rule has no command and generates a spurious warning message in the build logs when CONFIG_SCRIPTS_GDB is enabled. Fix simply by giving a no-op action Reported-by: Jan Kiszka Signed-off-by:

[PATCH 1/6] scripts/gdb: silence 'nothing to do' message

The constants.py generation, involves a rule to link into the main makefile. This rule has no command and generates a spurious warning message in the build logs when CONFIG_SCRIPTS_GDB is enabled. Fix simply by giving a no-op action Reported-by: Jan Kiszka Signed-off-by: Kieran Bingham ---

Re: [RESEND][PATCH] mfd: Add support for COMe-cSL6 and COMe-mAL10 to Kontron PLD driver

On Sun, 19 Jun 2016, Michael Brunner wrote: > This is an unmodified resend of the patch already been sent on > February 17 as it seems to have fallen through the net. > > This patch adds the DMI system ID of the Kontron COMe-cSL6 and > COME-mAL10 boards to the Kontron PLD driver. The list of

Re: [RESEND][PATCH] mfd: Add support for COMe-cSL6 and COMe-mAL10 to Kontron PLD driver

On Sun, 19 Jun 2016, Michael Brunner wrote: > This is an unmodified resend of the patch already been sent on > February 17 as it seems to have fallen through the net. > > This patch adds the DMI system ID of the Kontron COMe-cSL6 and > COME-mAL10 boards to the Kontron PLD driver. The list of

[PATCH 4/6] scripts/gdb: Perform path expansion to lx-symbol's arguments

From: Nikolay Borisov Python doesn't do automatic expansion of paths. In case one passes path of the from ~/foo/bar the gdb scripts won't automatically expand that and as a result the symbols files won't be loaded. Fix this by explicitly expanding all paths which begin

[PATCH 5/6] Revert "scripts/gdb: add a Radix Tree Parser"

This reverts commit e127a73d41ac ("scripts/gdb: add a Radix Tree Parser") The python implementation of radix-tree was merged at the same time as the radix-tree system was heavily reworked from commit e9256efcc8e3 ("radix-tree: introduce radix_tree_empty") to 3bcadd6fa6c4 ("radix-tree: free up the

<    4   5   6   7   8   9   10   11   12   13   >