[PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd

Signed-off-by: Daniel Lezcano --- Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++ arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 + 2 files changed, 7 insertions(+) diff --git

[PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd

Signed-off-by: Daniel Lezcano --- Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++ arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 + 2 files changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt

[PATCH V3 1/2] clk: hi6220: Add the hi655x's pmic clock

The hi655x multi function device is a PMIC providing regulators. The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement this clock in order to add it in the hi655x MFD and allow proper wireless initialization. Signed-off-by: Daniel Lezcano ---

[PATCH V3 1/2] clk: hi6220: Add the hi655x's pmic clock

The hi655x multi function device is a PMIC providing regulators. The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement this clock in order to add it in the hi655x MFD and allow proper wireless initialization. Signed-off-by: Daniel Lezcano --- Changelog: V3: -

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

On 4/16/2017 9:16 PM, Xie XiuQi wrote: On 2017/4/17 11:08, Xie XiuQi wrote: On 3/30/2017 4:31 AM, Xie XiuQi wrote: Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

On 4/16/2017 9:16 PM, Xie XiuQi wrote: On 2017/4/17 11:08, Xie XiuQi wrote: On 3/30/2017 4:31 AM, Xie XiuQi wrote: Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace

Re: [PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote: > orderly_poweroff is triggered when a graceful shutdown > of system is desired. This may be used in many critical states of the > kernel such as when subsystems detects conditions such as critical > temperature conditions. However, in

Re: [PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote: > orderly_poweroff is triggered when a graceful shutdown > of system is desired. This may be used in many critical states of the > kernel such as when subsystems detects conditions such as critical > temperature conditions. However, in

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Mon, Apr 17, 2017 at 11:22:08AM -0500, Alan Tull wrote: > On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse wrote: > > On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote: > >> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: > >> > >> Hi

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Mon, Apr 17, 2017 at 11:22:08AM -0500, Alan Tull wrote: > On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse wrote: > > On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote: > >> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: > >> > >> Hi Jerome, > >> > >> > On Fri, Apr 14, 2017 at

[PATCH] powerpc/mm/hugetlb: Add support for 1G huge pages

POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch enables the usage of 1G page size for hugetlbfs. This also update the helper such we can do 1G page allocation at runtime. Since we can do this only when radix translation mode is enabled, we can't use the generic

[PATCH] powerpc/mm/hugetlb: Add support for 1G huge pages

POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch enables the usage of 1G page size for hugetlbfs. This also update the helper such we can do 1G page allocation at runtime. Since we can do this only when radix translation mode is enabled, we can't use the generic

RE: [PATCH] ACPICA: Export mutex functions

There is a model for the drivers to directly acquire an AML mutex object. That is why the acquire/release public interfaces were added to ACPICA. I forget all of the details, but the model was developed with MS and others during the ACPI 6.0 timeframe. > -Original Message- > From:

[PATCH 6/7] powerpc/hugetlb: Add follow_huge_pd implementation for ppc64.

Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/hugetlbpage.c | 43 +++ 1 file changed, 43 insertions(+) diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 80f6d2ed551a..5c829a83a4cc

RE: [PATCH] ACPICA: Export mutex functions

There is a model for the drivers to directly acquire an AML mutex object. That is why the acquire/release public interfaces were added to ACPICA. I forget all of the details, but the model was developed with MS and others during the ACPI 6.0 timeframe. > -Original Message- > From:

[PATCH 6/7] powerpc/hugetlb: Add follow_huge_pd implementation for ppc64.

Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/hugetlbpage.c | 43 +++ 1 file changed, 43 insertions(+) diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 80f6d2ed551a..5c829a83a4cc 100644 ---

[PATCH 7/7] powerpc/hugetlb: Enable hugetlb migration for ppc64

Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/platforms/Kconfig.cputype | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index f4ba4bf0d762..9fb075745c7f 100644 ---

[PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

Architectures like ppc64 supports hugepage size that is not mapped to any of of the page table levels. Instead they add an alternate page table entry format called hugepage directory (hugepd). hugepd indicates that the page table entry maps to a set of hugetlb pages. Add support for this in

[PATCH 7/7] powerpc/hugetlb: Enable hugetlb migration for ppc64

Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/platforms/Kconfig.cputype | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index f4ba4bf0d762..9fb075745c7f 100644 ---

[PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

Architectures like ppc64 supports hugepage size that is not mapped to any of of the page table levels. Instead they add an alternate page table entry format called hugepage directory (hugepd). hugepd indicates that the page table entry maps to a set of hugetlb pages. Add support for this in

[PATCH 1/7] mm/hugetlb/migration: Use set_huge_pte_at instead of set_pte_at

The right interface to use to set a hugetlb pte entry is set_huge_pte_at. Use that instead of set_pte_at. Signed-off-by: Aneesh Kumar K.V --- mm/migrate.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/mm/migrate.c

[PATCH 1/7] mm/hugetlb/migration: Use set_huge_pte_at instead of set_pte_at

The right interface to use to set a hugetlb pte entry is set_huge_pte_at. Use that instead of set_pte_at. Signed-off-by: Aneesh Kumar K.V --- mm/migrate.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index

[PATCH 3/7] mm/hugetlb: export hugetlb_entry_migration helper

We will be using this later from the ppc64 code. Change the return type to bool. Signed-off-by: Aneesh Kumar K.V --- include/linux/hugetlb.h | 1 + mm/hugetlb.c| 8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH 2/7] mm/follow_page_mask: Split follow_page_mask to smaller functions.

Makes code reading easy. No functional changes in this patch. In a followup patch, we will be updating the follow_page_mask to handle hugetlb hugepd format so that archs like ppc64 can switch to the generic version. This split helps in doing that nicely. Signed-off-by: Aneesh Kumar K.V

[PATCH 4/7] mm/follow_page_mask: Add support for hugetlb pgd entries.

From: Anshuman Khandual ppc64 supports pgd hugetlb entries. Add code to handle hugetlb pgd entries to follow_page_mask so that ppc64 can switch to it to handle hugetlbe entries. Signed-off-by: Anshuman Khandual Signed-off-by: Aneesh

[PATCH 3/7] mm/hugetlb: export hugetlb_entry_migration helper

We will be using this later from the ppc64 code. Change the return type to bool. Signed-off-by: Aneesh Kumar K.V --- include/linux/hugetlb.h | 1 + mm/hugetlb.c| 8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/include/linux/hugetlb.h

[PATCH 2/7] mm/follow_page_mask: Split follow_page_mask to smaller functions.

Makes code reading easy. No functional changes in this patch. In a followup patch, we will be updating the follow_page_mask to handle hugetlb hugepd format so that archs like ppc64 can switch to the generic version. This split helps in doing that nicely. Signed-off-by: Aneesh Kumar K.V ---

[PATCH 4/7] mm/follow_page_mask: Add support for hugetlb pgd entries.

From: Anshuman Khandual ppc64 supports pgd hugetlb entries. Add code to handle hugetlb pgd entries to follow_page_mask so that ppc64 can switch to it to handle hugetlbe entries. Signed-off-by: Anshuman Khandual Signed-off-by: Aneesh Kumar K.V --- include/linux/hugetlb.h | 4 mm/gup.c

[PATCH 0/7] HugeTLB migration support for PPC64

This patch series add support for hugetlb page migration. Aneesh Kumar K.V (6): mm/hugetlb/migration: Use set_huge_pte_at instead of set_pte_at mm/follow_page_mask: Split follow_page_mask to smaller functions. mm/hugetlb: export hugetlb_entry_migration helper mm/follow_page_mask: Add

[PATCH 0/7] HugeTLB migration support for PPC64

This patch series add support for hugetlb page migration. Aneesh Kumar K.V (6): mm/hugetlb/migration: Use set_huge_pte_at instead of set_pte_at mm/follow_page_mask: Split follow_page_mask to smaller functions. mm/hugetlb: export hugetlb_entry_migration helper mm/follow_page_mask: Add

Re:drivers:watchdog:aspeed_wdt: using msleep instead of mdelay

On Sun, 16 Apr 2017 12:53:28 -0700,Guenter Roeck wrote: > On 04/16/2017 09:33 AM, Karim Eshapa wrote: >> >> that's useful for the scheduler, power management unless >> the driver needs to delay in atomic context >> look at documentation/timers/timers-howto > > Possibly, but how can you guarantee

Re:drivers:watchdog:aspeed_wdt: using msleep instead of mdelay

On Sun, 16 Apr 2017 12:53:28 -0700,Guenter Roeck wrote: > On 04/16/2017 09:33 AM, Karim Eshapa wrote: >> >> that's useful for the scheduler, power management unless >> the driver needs to delay in atomic context >> look at documentation/timers/timers-howto > > Possibly, but how can you guarantee

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, Apr 17, 2017 at 9:52 AM, Logan Gunthorpe wrote: > > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: >> But is it ? For example take a GPU, does it, in your scheme, need an >> additional "p2pmem" child ? Why can't the GPU driver just use some >> helper to

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, Apr 17, 2017 at 9:52 AM, Logan Gunthorpe wrote: > > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: >> But is it ? For example take a GPU, does it, in your scheme, need an >> additional "p2pmem" child ? Why can't the GPU driver just use some >> helper to instantiate the necessary

Re: [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx

From: George Cherian Date: Thu, 13 Apr 2017 07:25:01 + > Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set > the max bgx per node count. > > This fixes the issue intoduced by following commit > 78aacb6f6 net: thunderx: Fix invalid mac addresses for node1

Re: [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx

From: George Cherian Date: Thu, 13 Apr 2017 07:25:01 + > Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set > the max bgx per node count. > > This fixes the issue intoduced by following commit > 78aacb6f6 net: thunderx: Fix invalid mac addresses for node1 interfaces > With this

Re: [PATCH net-next] l2tp: device MTU setup, tunnel socket needs a lock

From: "R. Parameswaran" Date: Wed, 12 Apr 2017 18:31:04 -0700 (PDT) > > The MTU overhead calculation in L2TP device set-up > merged via commit b784e7ebfce8cfb16c6f95e14e8532d0768ab7ff > needs to be adjusted to lock the tunnel socket while > referencing the sub-data

Re: [PATCH net-next] l2tp: device MTU setup, tunnel socket needs a lock

From: "R. Parameswaran" Date: Wed, 12 Apr 2017 18:31:04 -0700 (PDT) > > The MTU overhead calculation in L2TP device set-up > merged via commit b784e7ebfce8cfb16c6f95e14e8532d0768ab7ff > needs to be adjusted to lock the tunnel socket while > referencing the sub-data structures to derive the >

Re: [PATCH] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Hi Dmitry, El Fri, Apr 14, 2017 at 09:02:03PM -0700 Dmitry Torokhov ha dit: > On Tue, Apr 11, 2017 at 12:17 PM, Matthias Kaehlcke wrote: > > Besides reusing existing code this removes the special case handling > > for 64-bit masks, which causes clang to raise a shift count

Re: [PATCH] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Hi Dmitry, El Fri, Apr 14, 2017 at 09:02:03PM -0700 Dmitry Torokhov ha dit: > On Tue, Apr 11, 2017 at 12:17 PM, Matthias Kaehlcke wrote: > > Besides reusing existing code this removes the special case handling > > for 64-bit masks, which causes clang to raise a shift count overflow > > warning

Re: [PATCH resend 3/4] uapi glibc compat: Do not check for __USE_MISC

From: Hauke Mehrtens Date: Wed, 12 Apr 2017 22:31:02 +0200 > __USE_MISC is glibc specific and not available in musl libc. Only do > this check when glibc is used. This fixes a problem with musl libc. > > Acked-by: Mikko Rapeli > Signed-off-by: Hauke

Re: [PATCH resend 3/4] uapi glibc compat: Do not check for __USE_MISC

From: Hauke Mehrtens Date: Wed, 12 Apr 2017 22:31:02 +0200 > __USE_MISC is glibc specific and not available in musl libc. Only do > this check when glibc is used. This fixes a problem with musl libc. > > Acked-by: Mikko Rapeli > Signed-off-by: Hauke Mehrtens You yourself introduce this

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > But is it ? For example take a GPU, does it, in your scheme, need an > additional "p2pmem" child ? Why can't the GPU driver just use some > helper to instantiate the necessary struct pages ? What does having an > actual "struct device" child

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > But is it ? For example take a GPU, does it, in your scheme, need an > additional "p2pmem" child ? Why can't the GPU driver just use some > helper to instantiate the necessary struct pages ? What does having an > actual "struct device" child

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote: > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote: > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote: > > >> Compiling the DT file with W=1,

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote: > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote: > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote: > > >> Compiling the DT file with W=1, DTC warns like

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote: > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote: > >> Compiling the DT file with W=1, DTC warns like follows: > >> > >> Warning (unit_address_vs_reg): Node

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote: > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote: > >> Compiling the DT file with W=1, DTC warns like follows: > >> > >> Warning (unit_address_vs_reg): Node

Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

On Fri, Apr 14, 2017 at 5:17 PM, Sinan Kaya wrote: > On 4/14/2017 5:44 PM, Bjorn Helgaas wrote: >> I think there's an argument to be made that if we care about ASPM >> configuration, we should be using a non-POLICY_DEFAULT setting. And I >> think there's value in having

Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

On Fri, Apr 14, 2017 at 5:17 PM, Sinan Kaya wrote: > On 4/14/2017 5:44 PM, Bjorn Helgaas wrote: >> I think there's an argument to be made that if we care about ASPM >> configuration, we should be using a non-POLICY_DEFAULT setting. And I >> think there's value in having POLICY_DEFAULT be the

Re: [PATCH 0/2] i2c: xgene-slimpro: Add ACPI support

Hi All, Do you have any comments on this patch set? Thanks On Tue, Mar 28, 2017 at 1:46 PM, Hoan Tran wrote: > This patch set adds ACPI support by using PCC mailbox communication interface. > > Hoan Tran (2): > i2c: xgene-slimpro: Use a single function to send command message

Re: [PATCH 0/2] i2c: xgene-slimpro: Add ACPI support

Hi All, Do you have any comments on this patch set? Thanks On Tue, Mar 28, 2017 at 1:46 PM, Hoan Tran wrote: > This patch set adds ACPI support by using PCC mailbox communication interface. > > Hoan Tran (2): > i2c: xgene-slimpro: Use a single function to send command message > i2c:

Re: [PATCH v2 0/3] perf: xgene: Add support for SoC PMU version 3

Hi All, Do you have any comments on this patch set? Thanks On Mon, Apr 3, 2017 at 9:47 AM, Hoan Tran wrote: > This patch set adds support for SoC-wide (AKA uncore) Performance Monitoring > Unit version 3. > > It can support up to > - 2 IOB PMU instances > - 8 L3C PMU

Re: [PATCH v2 0/3] perf: xgene: Add support for SoC PMU version 3

Hi All, Do you have any comments on this patch set? Thanks On Mon, Apr 3, 2017 at 9:47 AM, Hoan Tran wrote: > This patch set adds support for SoC-wide (AKA uncore) Performance Monitoring > Unit version 3. > > It can support up to > - 2 IOB PMU instances > - 8 L3C PMU instances > - 2 MCB PMU

[PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

We were returning without decrementing if the error happened, meaning that at the next submit we wouldn't try to bring up the power domain. Signed-off-by: Eric Anholt --- I stumbled across this error when testing my CMA patch with a very low (64MB) CMA area -- we would oops on

[PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

We were returning without decrementing if the error happened, meaning that at the next submit we wouldn't try to bring up the power domain. Signed-off-by: Eric Anholt --- I stumbled across this error when testing my CMA patch with a very low (64MB) CMA area -- we would oops on the submit after

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse wrote: > On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote: >> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: >> >> Hi Jerome, >> >> > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse wrote: > On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote: >> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: >> >> Hi Jerome, >> >> > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote: >> >> On Wed, Apr 12, 2017 at

Re: [kernel-hardening] Re: [PATCH 3/4] restrict unprivileged TIOCSTI tty ioctl

On 04/17/2017 10:18 AM, Jann Horn wrote: On Mon, Apr 17, 2017 at 8:53 AM, Greg KH wrote: On Mon, Apr 17, 2017 at 02:07:05AM -0400, Matt Brown wrote: this patch depends on patch 1 and 2 enforces restrictions on unprivileged users injecting commands into other

Re: [kernel-hardening] Re: [PATCH 3/4] restrict unprivileged TIOCSTI tty ioctl

On 04/17/2017 10:18 AM, Jann Horn wrote: On Mon, Apr 17, 2017 at 8:53 AM, Greg KH wrote: On Mon, Apr 17, 2017 at 02:07:05AM -0400, Matt Brown wrote: this patch depends on patch 1 and 2 enforces restrictions on unprivileged users injecting commands into other processes in the same tty session

Re: Using ion memory for direct-io

On 04/14/2017 02:18 AM, Zengtao (B) wrote: > Hi > > Currently, the ion mapped to userspace will be forced with VM_IO and > VM_PFNMAP flags. > When I use the ion memory to do the direct-io, it will fail when reaching the > get_user_pages, > > Back to the VM_IO and VM_PFNMAP flag, there two

Re: Using ion memory for direct-io

On 04/14/2017 02:18 AM, Zengtao (B) wrote: > Hi > > Currently, the ion mapped to userspace will be forced with VM_IO and > VM_PFNMAP flags. > When I use the ion memory to do the direct-io, it will fail when reaching the > get_user_pages, > > Back to the VM_IO and VM_PFNMAP flag, there two

Re: [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures

On Fri, Apr 07, 2017 at 03:07:12PM +0200, Michał Kępień wrote: > If acpi_fujitsu_laptop_leds_register() returns an error, the latter will > become the return value of acpi_fujitsu_laptop_add(), which in turn will > be reported by driver core. Simplify code by replacing pr_err() calls > with

Re: [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures

On Fri, Apr 07, 2017 at 03:07:12PM +0200, Michał Kępień wrote: > If acpi_fujitsu_laptop_leds_register() returns an error, the latter will > become the return value of acpi_fujitsu_laptop_add(), which in turn will > be reported by driver core. Simplify code by replacing pr_err() calls > with

Re: pinctrl: imx: Checking reuse of grouping functionality

> However the imx pinctrl driver _absolutely_ needs this configuration to work. Thanks for your explanation that the file “drivers/pinctrl/freescale/Kconfig” will usually provide needed information for this software module. Would it make sense to document such a requirement also by a

Re: pinctrl: imx: Checking reuse of grouping functionality

> However the imx pinctrl driver _absolutely_ needs this configuration to work. Thanks for your explanation that the file “drivers/pinctrl/freescale/Kconfig” will usually provide needed information for this software module. Would it make sense to document such a requirement also by a

Re: [RFC PATCH 9/9] debugfs: free debugfs_fsdata instances

On Sun, Apr 16, 2017 at 11:51:37AM +0200, Nicolai Stange wrote: > Currently, a dentry's debugfs_fsdata instance is allocated from > debugfs_file_get() at first usage, i.e. at first file opening. > > It won't ever get freed though. > > Ideally, these instances would get freed after the last open

Re: [RFC PATCH 9/9] debugfs: free debugfs_fsdata instances

On Sun, Apr 16, 2017 at 11:51:37AM +0200, Nicolai Stange wrote: > Currently, a dentry's debugfs_fsdata instance is allocated from > debugfs_file_get() at first usage, i.e. at first file opening. > > It won't ever get freed though. > > Ideally, these instances would get freed after the last open

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote: > On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: > > Hi Jerome, > > > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote: > >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote: > >> >

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote: > On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: > > Hi Jerome, > > > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote: > >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote: > >> > On Wed, Apr 12, 2017

Re: [PATCH] ACPICA: Export mutex functions

Hi, On Mon, Apr 17, 2017 at 09:39:35AM +, Zheng, Lv wrote: > Hi, > > > From: Guenter Roeck [mailto:li...@roeck-us.net] > > Subject: Re: [PATCH] ACPICA: Export mutex functions > > > > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote: > > > The ACPICA mutex functions are based on

Re: [PATCH] ACPICA: Export mutex functions

Hi, On Mon, Apr 17, 2017 at 09:39:35AM +, Zheng, Lv wrote: > Hi, > > > From: Guenter Roeck [mailto:li...@roeck-us.net] > > Subject: Re: [PATCH] ACPICA: Export mutex functions > > > > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote: > > > The ACPICA mutex functions are based on

[PATCH -mm] fault-inject: don't convert unsigned type value as signed int

This fixes fault-inject-simplify-access-check-for-fail-nth.patch in -mm tree which by mistake partially reverts the change by fault-inject- parse-as-natural-1-based-value-for-fail-nth-write-interface.patch. Cc: Dmitry Vyukov Reported-by: Dmitry Vyukov

[PATCH -mm] fault-inject: don't convert unsigned type value as signed int

This fixes fault-inject-simplify-access-check-for-fail-nth.patch in -mm tree which by mistake partially reverts the change by fault-inject- parse-as-natural-1-based-value-for-fail-nth-write-interface.patch. Cc: Dmitry Vyukov Reported-by: Dmitry Vyukov Signed-off-by: Akinobu Mita ---

Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link()

Am 17.04.2017 um 17:27 schrieb Ralph Sennhauser: > Hi Amir, Richard > > Looks like the fix didn't make it into 4.11-rc7 either, isn't it time > to just disable O_TMPFILE support in ubifs for now? Giving plenty > time for the proper fix. As I said to Amir, don't panic. I'm *very* busy right now

Re: [PATCH] ubifs: Fix O_TMPFILE corner case in ubifs_link()

Am 17.04.2017 um 17:27 schrieb Ralph Sennhauser: > Hi Amir, Richard > > Looks like the fix didn't make it into 4.11-rc7 either, isn't it time > to just disable O_TMPFILE support in ubifs for now? Giving plenty > time for the proper fix. As I said to Amir, don't panic. I'm *very* busy right now

Re: [PATCH] pci-sysfs: Make PCI bridge attribute visible in sysfs

On Mon, Apr 17, 2017 at 12:50 AM, Wong Vee Khee wrote: > From: vwong > > Export the PCIe link attributes of PCI bridges to sysfs. This needs justification for *why* we should export these via sysfs. Some of these things, e.g., secondary/subordinate

Re: [PATCH] pci-sysfs: Make PCI bridge attribute visible in sysfs

On Mon, Apr 17, 2017 at 12:50 AM, Wong Vee Khee wrote: > From: vwong > > Export the PCIe link attributes of PCI bridges to sysfs. This needs justification for *why* we should export these via sysfs. Some of these things, e.g., secondary/subordinate bus numbers, are already visible to

Re: [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space

Hi Joerg, > When this function fails it just sends a SIGSEGV signal to > user-space using force_sig(). This signal is missing > essential information about the cause, e.g. the trap_nr or > an error code. > > Fix this by propagating the error to the only caller of > mpx_handle_bd_fault(),

Re: [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space

Hi Joerg, > When this function fails it just sends a SIGSEGV signal to > user-space using force_sig(). This signal is missing > essential information about the cause, e.g. the trap_nr or > an error code. > > Fix this by propagating the error to the only caller of > mpx_handle_bd_fault(),

Re: [PATCH] backlight: pwm_bl: Fix condition to set enable gpio as output

Hi, Le dimanche 16 avril 2017 à 22:55 +0200, Geert Uytterhoeven a écrit : > On Sun, Apr 16, 2017 at 12:35 PM, Paul Kocialkowski wrote: > > The move to a dedicated pwm_backlight_initial_power_state function in > > commit 7613c922315e308a6486d802abed2eb74443dffd modified the

Re: [PATCH] backlight: pwm_bl: Fix condition to set enable gpio as output

Hi, Le dimanche 16 avril 2017 à 22:55 +0200, Geert Uytterhoeven a écrit : > On Sun, Apr 16, 2017 at 12:35 PM, Paul Kocialkowski wrote: > > The move to a dedicated pwm_backlight_initial_power_state function in > > commit 7613c922315e308a6486d802abed2eb74443dffd modified the condition > > to set

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: Hi Jerome, > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote: >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote: >> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote: >> > > On

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse wrote: Hi Jerome, > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote: >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote: >> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote: >> > > On Wed, Apr 12, 2017

[PATCH 25/25] sky2: Use seq_puts() in sky2_debug_show()

From: Markus Elfring Date: Mon, 17 Apr 2017 16:15:12 +0200 A string which did not contain a data format specification should be put into a sequence. Thus use the corresponding function "seq_puts". This issue was detected by using the Coccinelle software.

[PATCH 25/25] sky2: Use seq_puts() in sky2_debug_show()

From: Markus Elfring Date: Mon, 17 Apr 2017 16:15:12 +0200 A string which did not contain a data format specification should be put into a sequence. Thus use the corresponding function "seq_puts". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 24/25] skge: Adjust a null pointer check in skge_down()

From: Markus Elfring Date: Mon, 17 Apr 2017 16:08:39 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written "!skge->mem". Thus fix the affected source code place. Signed-off-by: Markus Elfring

Re: [RFC 3/3] sched/topology: Different sched groups must not have the same balance cpu

On 04/14/2017 01:49 PM, Peter Zijlstra wrote: > On Thu, Apr 13, 2017 at 10:56:09AM -0300, Lauro Ramos Venancio wrote: >> Currently, the group balance cpu is the groups's first CPU. But with >> overlapping groups, two different groups can have the same first CPU. >> >> This patch uses the group

[PATCH 24/25] skge: Adjust a null pointer check in skge_down()

From: Markus Elfring Date: Mon, 17 Apr 2017 16:08:39 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written "!skge->mem". Thus fix the affected source code place. Signed-off-by: Markus Elfring --- drivers/net/ethernet/marvell/skge.c

Re: [RFC 3/3] sched/topology: Different sched groups must not have the same balance cpu

On 04/14/2017 01:49 PM, Peter Zijlstra wrote: > On Thu, Apr 13, 2017 at 10:56:09AM -0300, Lauro Ramos Venancio wrote: >> Currently, the group balance cpu is the groups's first CPU. But with >> overlapping groups, two different groups can have the same first CPU. >> >> This patch uses the group

[PATCH 23/25] skge: Use seq_puts() in skge_debug_show()

From: Markus Elfring Date: Mon, 17 Apr 2017 15:43:08 +0200 A string which did not contain a data format specification should be put into a sequence. Thus use the corresponding function "seq_puts". This issue was detected by using the Coccinelle software.

[PATCH 23/25] skge: Use seq_puts() in skge_debug_show()

From: Markus Elfring Date: Mon, 17 Apr 2017 15:43:08 +0200 A string which did not contain a data format specification should be put into a sequence. Thus use the corresponding function "seq_puts". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 22/25] net: pxa168_eth: Adjust four checks for null pointers

From: Markus Elfring Date: Mon, 17 Apr 2017 15:23:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written … Thus

[PATCH 22/25] net: pxa168_eth: Adjust four checks for null pointers

From: Markus Elfring Date: Mon, 17 Apr 2017 15:23:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written … Thus fix the affected source code

[PATCH 21/25] net: pxa168_eth: Use kcalloc() in two functions

From: Markus Elfring Date: Mon, 17 Apr 2017 14:32:14 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using

[PATCH 21/25] net: pxa168_eth: Use kcalloc() in two functions

From: Markus Elfring Date: Mon, 17 Apr 2017 14:32:14 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using the Coccinelle software.

[PATCH 20/25] net: mvpp2: Adjust a null pointer check in mvpp2_egress_enable()

From: Markus Elfring Date: Mon, 17 Apr 2017 14:07:52 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written "txq->descs". Thus fix the affected source code place. Signed-off-by: Markus Elfring

[PATCH 20/25] net: mvpp2: Adjust a null pointer check in mvpp2_egress_enable()

From: Markus Elfring Date: Mon, 17 Apr 2017 14:07:52 +0200 The script "checkpatch.pl" pointed information out like the following. Comparison to NULL could be written "txq->descs". Thus fix the affected source code place. Signed-off-by: Markus Elfring --- drivers/net/ethernet/marvell/mvpp2.c

[PATCH 19/25] net: mvpp2: Rename a jump label in mvpp2_prs_vlan_add()

From: Markus Elfring Date: Mon, 17 Apr 2017 13:50:35 +0200 Adjust jump labels according to the Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/net/ethernet/marvell/mvpp2.c | 5 ++--- 1 file changed, 2

[PATCH 19/25] net: mvpp2: Rename a jump label in mvpp2_prs_vlan_add()

From: Markus Elfring Date: Mon, 17 Apr 2017 13:50:35 +0200 Adjust jump labels according to the Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/net/ethernet/marvell/mvpp2.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

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