[sysfs] Sysfs acceptable paths to custom functionality

I am developing a driver for an audio codec that has fixed DSP functionality. On the device there are coefficients that can be programmed to implement different types of filters that can be used to implement an EQ or 3D sound effects. Based on what I have seen in the Kernel so far our device

[sysfs] Sysfs acceptable paths to custom functionality

I am developing a driver for an audio codec that has fixed DSP functionality. On the device there are coefficients that can be programmed to implement different types of filters that can be used to implement an EQ or 3D sound effects. Based on what I have seen in the Kernel so far our device

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu 05-10-17 15:02:18, David Rientjes wrote: [...] > I would need to add patches to add the "evaluate as a whole but do not > kill all" knob and a knob for "oom priority" so that userspace has the > same influence over a cgroup based comparison that it does with a process > based comparison

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu 05-10-17 15:02:18, David Rientjes wrote: [...] > I would need to add patches to add the "evaluate as a whole but do not > kill all" knob and a knob for "oom priority" so that userspace has the > same influence over a cgroup based comparison that it does with a process > based comparison

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

On Thu, Oct 05, 2017 at 04:03:37PM -0700, Jacob Pan wrote: > DMA faults can be detected by IOMMU at device level. Adding a pointer > to struct device allows IOMMU subsystem to report relevant faults > back to the device driver for further handling. > For direct assigned device (or user space

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

On Thu, Oct 05, 2017 at 04:03:37PM -0700, Jacob Pan wrote: > DMA faults can be detected by IOMMU at device level. Adding a pointer > to struct device allows IOMMU subsystem to report relevant faults > back to the device driver for further handling. > For direct assigned device (or user space

Re: [PATCH 1/4] dt-bindings: media: Binding document for Qualcomm Camera Control Interface driver

On Mon 02 Oct 07:13 PDT 2017, Todor Tomov wrote: > diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt > b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt > new file mode 100644 > index 000..f4c5338 > --- /dev/null > +++

Re: [PATCH 1/4] dt-bindings: media: Binding document for Qualcomm Camera Control Interface driver

On Mon 02 Oct 07:13 PDT 2017, Todor Tomov wrote: > diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt > b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt > new file mode 100644 > index 000..f4c5338 > --- /dev/null > +++

Re: [PATCH 2/4] i2c: Add Qualcomm Camera Control Interface driver

On Mon 02 Oct 07:13 PDT 2017, Todor Tomov wrote: > diff --git a/drivers/i2c/busses/i2c-qcom-cci.c > b/drivers/i2c/busses/i2c-qcom-cci.c [..] > +#define NUM_MASTERS 1 So you will only register one of the masters? [..] > +enum cci_i2c_queue_t { > + QUEUE_0, > + QUEUE_1 Could these be

Re: [PATCH 2/4] i2c: Add Qualcomm Camera Control Interface driver

On Mon 02 Oct 07:13 PDT 2017, Todor Tomov wrote: > diff --git a/drivers/i2c/busses/i2c-qcom-cci.c > b/drivers/i2c/busses/i2c-qcom-cci.c [..] > +#define NUM_MASTERS 1 So you will only register one of the masters? [..] > +enum cci_i2c_queue_t { > + QUEUE_0, > + QUEUE_1 Could these be

Re: [PATCH] net/ipv6: remove unused err variable on icmpv6_push_pending_frames

From: Tim Hansen Date: Thu, 5 Oct 2017 15:45:32 -0400 > int err is unused by icmpv6_push_pending_frames(), this patch returns removes > the variable and returns the function with 0. > > git bisect shows this variable has been around since linux has been in git in >

Re: [PATCH] net/ipv6: remove unused err variable on icmpv6_push_pending_frames

From: Tim Hansen Date: Thu, 5 Oct 2017 15:45:32 -0400 > int err is unused by icmpv6_push_pending_frames(), this patch returns removes > the variable and returns the function with 0. > > git bisect shows this variable has been around since linux has been in git in > commit

[PATCH v2 3/3] arm64: dts: uniphier: add efuse node for LD20

Add efuse node for UniPhier LD20 SoC. This efuse node is included in soc-glue. Signed-off-by: Keiji Hayashibara --- arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git

[PATCH v2 3/3] arm64: dts: uniphier: add efuse node for LD20

Add efuse node for UniPhier LD20 SoC. This efuse node is included in soc-glue. Signed-off-by: Keiji Hayashibara --- arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi

[PATCH v2 0/3] add UniPhier efuse support

This series adds support for eFuse implemented on UniPhier LD20 SoCs. The eFuse device is under soc-glue and this register implements as read only. patch V1 https://lkml.org/lkml/2017/8/31/880 Changes between V2 and V1 = 1. Fix sparse warnings 2. Changed to implement

[PATCH v2 2/3] nvmem: uniphier: add UniPhier eFuse driver

Add eFuse driver for Socionext UniPhier series SoC. Note that eFuse device is under soc-glue and this register implements as read only. Signed-off-by: Keiji Hayashibara --- drivers/nvmem/Kconfig | 11 + drivers/nvmem/Makefile | 2 +

[PATCH v2 0/3] add UniPhier efuse support

This series adds support for eFuse implemented on UniPhier LD20 SoCs. The eFuse device is under soc-glue and this register implements as read only. patch V1 https://lkml.org/lkml/2017/8/31/880 Changes between V2 and V1 = 1. Fix sparse warnings 2. Changed to implement

[PATCH v2 2/3] nvmem: uniphier: add UniPhier eFuse driver

Add eFuse driver for Socionext UniPhier series SoC. Note that eFuse device is under soc-glue and this register implements as read only. Signed-off-by: Keiji Hayashibara --- drivers/nvmem/Kconfig | 11 + drivers/nvmem/Makefile | 2 + drivers/nvmem/uniphier-efuse.c | 97

[PATCH v2 1/3] dt-bindings: nvmem: add description for UniPhier eFuse

Add uniphier-efuse dt-bindings documentation. Signed-off-by: Keiji Hayashibara --- .../devicetree/bindings/nvmem/uniphier-efuse.txt | 49 ++ 1 file changed, 49 insertions(+) create mode 100644

[PATCH v2 1/3] dt-bindings: nvmem: add description for UniPhier eFuse

Add uniphier-efuse dt-bindings documentation. Signed-off-by: Keiji Hayashibara --- .../devicetree/bindings/nvmem/uniphier-efuse.txt | 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt diff --git

Re: [PATCH] firmware: add firmware to new device's devres list for second time cache

On Thu, Oct 5, 2017 at 5:17 AM, Luis R. Rodriguez wrote: > On Tue, Aug 22, 2017 at 03:52:46PM +0800, Kai-Heng Feng wrote: >> Currently, firmware will only be chached if assign_firmware_buf() gets >> called. > > True, but also more importantly we peg the fw cache to the device

Re: [PATCH] firmware: add firmware to new device's devres list for second time cache

On Thu, Oct 5, 2017 at 5:17 AM, Luis R. Rodriguez wrote: > On Tue, Aug 22, 2017 at 03:52:46PM +0800, Kai-Heng Feng wrote: >> Currently, firmware will only be chached if assign_firmware_buf() gets >> called. > > True, but also more importantly we peg the fw cache to the device via devres > *iff*

Re: [PATCH] net/mlx4_core: Convert timers to use timer_setup()

On Wed, Oct 04, 2017 at 05:51:54PM -0700, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Tariq Toukan

Re: [PATCH] net/mlx4_core: Convert timers to use timer_setup()

On Wed, Oct 04, 2017 at 05:51:54PM -0700, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Tariq Toukan > Cc:

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Thu, 5 Oct 2017 19:58:08 -0400 Steven Rostedt wrote: > On Thu, 5 Oct 2017 16:35:22 -0700 > Kees Cook wrote: > > > > As far as I can see, tcp probe, dccp probe, sctp probe and lkdtm > > > are using jprobe to probe function. Please consider to

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Thu, 5 Oct 2017 19:58:08 -0400 Steven Rostedt wrote: > On Thu, 5 Oct 2017 16:35:22 -0700 > Kees Cook wrote: > > > > As far as I can see, tcp probe, dccp probe, sctp probe and lkdtm > > > are using jprobe to probe function. Please consider to migrate. > > > > I'm happy to do so, but I'm

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Thu, 5 Oct 2017 21:11:30 -0400 Steven Rostedt wrote: > On Fri, 6 Oct 2017 09:32:52 +0900 > Masami Hiramatsu wrote: > > > I think using ftrace gives you lower latency, but you need to depend on > > CONFIG_FUNCTION_TRACER instead of CONFIG_KPROBES. >

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Thu, 5 Oct 2017 21:11:30 -0400 Steven Rostedt wrote: > On Fri, 6 Oct 2017 09:32:52 +0900 > Masami Hiramatsu wrote: > > > I think using ftrace gives you lower latency, but you need to depend on > > CONFIG_FUNCTION_TRACER instead of CONFIG_KPROBES. > > Which shouldn't be an issue, since all

Re: [PATCH] md: raid10: remove VLAIS

On Fri, Oct 06, 2017 at 01:22:12PM +1100, Neil Brown wrote: > On Thu, Oct 05 2017, Matthias Kaehlcke wrote: > > > Hi Neil, > > > > El Fri, Oct 06, 2017 at 10:58:59AM +1100 NeilBrown ha dit: > > > >> On Thu, Oct 05 2017, Matthias Kaehlcke wrote: > >> > >> > The raid10 driver can't be built with

Re: [PATCH] md: raid10: remove VLAIS

On Fri, Oct 06, 2017 at 01:22:12PM +1100, Neil Brown wrote: > On Thu, Oct 05 2017, Matthias Kaehlcke wrote: > > > Hi Neil, > > > > El Fri, Oct 06, 2017 at 10:58:59AM +1100 NeilBrown ha dit: > > > >> On Thu, Oct 05 2017, Matthias Kaehlcke wrote: > >> > >> > The raid10 driver can't be built with

Re: btusb "firmware request while host is not available" at resume

Hi Luis, On Wed, Oct 4, 2017 at 8:20 AM, Luis R. Rodriguez wrote: > So please retest now that the revert happened: commit > f007cad159e99fa2acd3b2e9364fbb32ad28b971 ("Revert "firmware: add sanity check > on shutdown/suspend"). I can confirm the issue is gone after the commit.

Re: btusb "firmware request while host is not available" at resume

Hi Luis, On Wed, Oct 4, 2017 at 8:20 AM, Luis R. Rodriguez wrote: > So please retest now that the revert happened: commit > f007cad159e99fa2acd3b2e9364fbb32ad28b971 ("Revert "firmware: add sanity check > on shutdown/suspend"). I can confirm the issue is gone after the commit. Also, thanks for

[RFC 2/2] phy: exynos5-usbdrd: remove disable and enable of phy clk

remove the disable and enable of phy clk. phy clk is needed to tune the phy controller. Before: mout_usbd300 112400 0 0 dout_usbd300 002400 0 0 sclk_usbd300

[RFC 2/2] phy: exynos5-usbdrd: remove disable and enable of phy clk

remove the disable and enable of phy clk. phy clk is needed to tune the phy controller. Before: mout_usbd300 112400 0 0 dout_usbd300 002400 0 0 sclk_usbd300

[RFC 1/2] ARM: dts: exynos: update the usbdrd phy and ref clk

update the usbdrd link control and phy contol clks. Signed-off-by: Anand Moon --- Tested on Odroid XU4 and Odroid HC1 develpment board. Did not test Odroid XU develpment board. --- arch/arm/boot/dts/exynos5410.dtsi | 4 ++-- arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- 2

[RFC 1/2] ARM: dts: exynos: update the usbdrd phy and ref clk

update the usbdrd link control and phy contol clks. Signed-off-by: Anand Moon --- Tested on Odroid XU4 and Odroid HC1 develpment board. Did not test Odroid XU develpment board. --- arch/arm/boot/dts/exynos5410.dtsi | 4 ++-- arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- 2 files changed, 4

Re: [PATCH] kvm, mm: account kvm related kmem slabs to kmemcg

On 10/06/2017 06:37 AM, Shakeel Butt wrote: > The kvm slabs can consume a significant amount of system memory > and indeed in our production environment we have observed that > a lot of machines are spending significant amount of memory that > can not be left as system memory overhead. Also the

Re: [PATCH] kvm, mm: account kvm related kmem slabs to kmemcg

On 10/06/2017 06:37 AM, Shakeel Butt wrote: > The kvm slabs can consume a significant amount of system memory > and indeed in our production environment we have observed that > a lot of machines are spending significant amount of memory that > can not be left as system memory overhead. Also the

Re: [PATCH] net: qcom/emac: make function emac_isr static

From: Colin King Date: Thu, 5 Oct 2017 10:10:23 +0100 > From: Colin Ian King > > The function emac_isr is local to the source and does not need to > be in global scope, so make it static. > > Cleans up sparse warnings: > symbol 'emac_isr'

Re: [PATCH] ALSA: usb-audio: Add sample rate quirk for Plantronics P610

Hi, On Fri, Oct 6, 2017 at 2:22 AM, Takashi Iwai wrote: > On Thu, 05 Oct 2017 20:04:06 +0200, > Kai-Heng Feng wrote: >> >> Like other Plantronics devices, P610 does not support sample >> rate reading. Apply sample rate quirk to it. >> >> BugLink:

Re: [PATCH] net: qcom/emac: make function emac_isr static

From: Colin King Date: Thu, 5 Oct 2017 10:10:23 +0100 > From: Colin Ian King > > The function emac_isr is local to the source and does not need to > be in global scope, so make it static. > > Cleans up sparse warnings: > symbol 'emac_isr' was not declared. Should it be static? > >

Re: [PATCH] ALSA: usb-audio: Add sample rate quirk for Plantronics P610

Hi, On Fri, Oct 6, 2017 at 2:22 AM, Takashi Iwai wrote: > On Thu, 05 Oct 2017 20:04:06 +0200, > Kai-Heng Feng wrote: >> >> Like other Plantronics devices, P610 does not support sample >> rate reading. Apply sample rate quirk to it. >> >> BugLink: https://bugs.launchpad.net/bugs/1719853 >> >>

Re: [PATCH resend] platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface

Hi Hans, On Fri, Oct 6, 2017 at 2:04 AM, Hans de Goede wrote: > Hi All, > > This is a resend with Kai Heng Feng added to the Cc. Kai can you please > test this patch. This patch replaces yours, as many devices seem to be > affected so a whitelist is the better approach here.

Re: [PATCH resend] platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface

Hi Hans, On Fri, Oct 6, 2017 at 2:04 AM, Hans de Goede wrote: > Hi All, > > This is a resend with Kai Heng Feng added to the Cc. Kai can you please > test this patch. This patch replaces yours, as many devices seem to be > affected so a whitelist is the better approach here. I'll let the

Re: [PATCH] net/ipv4: Remove unused variable in route.c

From: Tim Hansen Date: Wed, 4 Oct 2017 15:59:49 -0400 > int rc is unmodified after initalization in net/ipv4/route.c, this patch > simply cleans up that variable and returns 0. > > This was found with coccicheck M=net/ipv4/ on linus' tree. > > Signed-off-by: Tim Hansen

Re: [PATCH net v2] RDS: IB: Initialize max_items based on underlying device attributes

From: Avinash Repaka Date: Wed, 4 Oct 2017 12:11:29 -0700 > Use max_1m_mrs/max_8k_mrs while setting max_items, as the former > variables are set based on the underlying device attributes. > > Signed-off-by: Avinash Repaka > Acked-by:

Re: [PATCH net v2] RDS: IB: Initialize max_items based on underlying device attributes

From: Avinash Repaka Date: Wed, 4 Oct 2017 12:11:29 -0700 > Use max_1m_mrs/max_8k_mrs while setting max_items, as the former > variables are set based on the underlying device attributes. > > Signed-off-by: Avinash Repaka > Acked-by: Santosh Shilimkar Applied to net-next.

Re: [PATCH] net/ipv4: Remove unused variable in route.c

From: Tim Hansen Date: Wed, 4 Oct 2017 15:59:49 -0400 > int rc is unmodified after initalization in net/ipv4/route.c, this patch > simply cleans up that variable and returns 0. > > This was found with coccicheck M=net/ipv4/ on linus' tree. > > Signed-off-by: Tim Hansen Applied to net-next.

Re: [PATCH net v2] RDS: IB: Limit the scope of has_fr/has_fmr variables

From: Avinash Repaka Date: Wed, 4 Oct 2017 12:10:43 -0700 > This patch fixes the scope of has_fr and has_fmr variables as they are > needed only in rds_ib_add_one(). > > Signed-off-by: Avinash Repaka > Acked-by: Santosh Shilimkar

Re: [PATCH net v2] RDS: IB: Limit the scope of has_fr/has_fmr variables

From: Avinash Repaka Date: Wed, 4 Oct 2017 12:10:43 -0700 > This patch fixes the scope of has_fr and has_fmr variables as they are > needed only in rds_ib_add_one(). > > Signed-off-by: Avinash Repaka > Acked-by: Santosh Shilimkar Applied to net-next.

Re: [PATCH net v2 3/9] net/mac89x0: Fix and modernize log messages

From: Finn Thain Date: Thu, 5 Oct 2017 21:11:05 -0400 (EDT) > Fix misplaced newlines in conditional log messages. Please don't do this, the way the author formatted the strings was intentional, they intended to print out: NAME: cs89%c0%s rev %c found at

Re: [PATCH net v2 3/9] net/mac89x0: Fix and modernize log messages

From: Finn Thain Date: Thu, 5 Oct 2017 21:11:05 -0400 (EDT) > Fix misplaced newlines in conditional log messages. Please don't do this, the way the author formatted the strings was intentional, they intended to print out: NAME: cs89%c0%s rev %c found at %#8lx IRQ %d ADDR %pM But now

Re: [PATCH v6 3/3] drm/panel: Add support for the Raspberry Pi 7" Touchscreen.

On 09/28/2017 01:06 AM, Eric Anholt wrote: This driver communicates with the Atmel microcontroller for sequencing the poweron of the TC358762 DSI-DPI bridge and controlling the backlight PWM. v2: Set the same default orientation as the closed source firmware used, which is the best for

Re: [PATCH v6 3/3] drm/panel: Add support for the Raspberry Pi 7" Touchscreen.

On 09/28/2017 01:06 AM, Eric Anholt wrote: This driver communicates with the Atmel microcontroller for sequencing the poweron of the TC358762 DSI-DPI bridge and controlling the backlight PWM. v2: Set the same default orientation as the closed source firmware used, which is the best for

Re: [PATCH] staging: ccree: local variable "dev" not required

On Thursday 05 October 2017 11:30 PM, Joe Perches wrote: > On Thu, 2017-10-05 at 10:07 +0300, Gilad Ben-Yossef wrote: >> On Wed, Oct 4, 2017 at 10:12 PM, wrote: >>> There is no need to create a local pointer variable "dev" and >>> pass it various API's, instead use plat_dev

Re: [PATCH] staging: ccree: local variable "dev" not required

On Thursday 05 October 2017 11:30 PM, Joe Perches wrote: > On Thu, 2017-10-05 at 10:07 +0300, Gilad Ben-Yossef wrote: >> On Wed, Oct 4, 2017 at 10:12 PM, wrote: >>> There is no need to create a local pointer variable "dev" and >>> pass it various API's, instead use plat_dev which is enumerated

Re: [PATCHv2 1/2] mm: Introduce wrappers to access mm->nr_ptes

On 10/05/2017 03:44 PM, Kirill A. Shutemov wrote: > Let's add wrappers for ->nr_ptes with the same interface as for nr_pmd > and nr_pud. > > It's preparation for consolidation of page-table counters in mm_struct. > > Signed-off-by: Kirill A. Shutemov Hey

Re: [PATCHv2 1/2] mm: Introduce wrappers to access mm->nr_ptes

On 10/05/2017 03:44 PM, Kirill A. Shutemov wrote: > Let's add wrappers for ->nr_ptes with the same interface as for nr_pmd > and nr_pud. > > It's preparation for consolidation of page-table counters in mm_struct. > > Signed-off-by: Kirill A. Shutemov Hey Kirill, This patch does not apply

Re: [PATCH v2 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

Hi Dmitry, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.14-rc3 next-20170929] [cannot apply to tegra/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

Hi Dmitry, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.14-rc3 next-20170929] [cannot apply to tegra/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 3/3] binfmt_elf: Search an unmapped area with total_size but not map the whole image

In elf_map(), we can search an unmapped area for the whole image of dynamic loader with total_size, then map the first PT_LOAD segment with its own size. But not map the while image, then unmap the remainder at the end. And also update the code comment in elf_map() accordingly. Signed-off-by:

[PATCH 2/3] binfmt_elf: Get the total_size only for dynamic loader in load_elf_binary()

In commit: eab09532d4 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") ... PIE programs are loaded offset from ELF_ET_DYN_BASE, and its map has been set as MAP_FIXED. Only dynamic loader will be mapped from below mm->mmap_base (E.g "./ld.so someprog"), and need take account of the need to

[PATCH 3/3] binfmt_elf: Search an unmapped area with total_size but not map the whole image

In elf_map(), we can search an unmapped area for the whole image of dynamic loader with total_size, then map the first PT_LOAD segment with its own size. But not map the while image, then unmap the remainder at the end. And also update the code comment in elf_map() accordingly. Signed-off-by:

[PATCH 2/3] binfmt_elf: Get the total_size only for dynamic loader in load_elf_binary()

In commit: eab09532d4 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") ... PIE programs are loaded offset from ELF_ET_DYN_BASE, and its map has been set as MAP_FIXED. Only dynamic loader will be mapped from below mm->mmap_base (E.g "./ld.so someprog"), and need take account of the need to

[PATCH 0/3] binfmt_elf: Clean up codes related to total_size passed into elf_map()

Currently total_size passed into elf_map() is non-zero only for dynamic loader, either in load_elf_interp(), or in load_elf_binary() for ET_DYN without INTERP case. Now PIE programs are loaded offset from ELF_ET_DYN_BASE, and map flags has been set as MAP_FIXED, no need to use tatal_size strategy.

[PATCH 1/3] binfmt_elf: Clean up the variable name of map flags

In load_elf_interp() and elf_map(), variables with value of map flags are named as type or elf_type. That may bring confusion since their values not only contain map type which is MAP_SHARED or MAP_PRIVATE, also MAP_FIXED or MAP_DENYWRITE, etc. So change them as flags or elf_flags.

[PATCH 0/3] binfmt_elf: Clean up codes related to total_size passed into elf_map()

Currently total_size passed into elf_map() is non-zero only for dynamic loader, either in load_elf_interp(), or in load_elf_binary() for ET_DYN without INTERP case. Now PIE programs are loaded offset from ELF_ET_DYN_BASE, and map flags has been set as MAP_FIXED, no need to use tatal_size strategy.

[PATCH 1/3] binfmt_elf: Clean up the variable name of map flags

In load_elf_interp() and elf_map(), variables with value of map flags are named as type or elf_type. That may bring confusion since their values not only contain map type which is MAP_SHARED or MAP_PRIVATE, also MAP_FIXED or MAP_DENYWRITE, etc. So change them as flags or elf_flags.

Re: [PATCH RFC hack dont apply] intel_idle: support running within a VM

On Wed, Oct 04, 2017 at 11:31:43AM -0700, Jacob Pan wrote: > On Wed, 4 Oct 2017 20:12:28 +0300 > "Michael S. Tsirkin" wrote: > > > On Wed, Oct 04, 2017 at 10:09:39AM -0700, Jacob Pan wrote: > > > On Wed, 4 Oct 2017 05:09:09 +0300 > > > "Michael S. Tsirkin"

Re: [PATCH RFC hack dont apply] intel_idle: support running within a VM

On Wed, Oct 04, 2017 at 11:31:43AM -0700, Jacob Pan wrote: > On Wed, 4 Oct 2017 20:12:28 +0300 > "Michael S. Tsirkin" wrote: > > > On Wed, Oct 04, 2017 at 10:09:39AM -0700, Jacob Pan wrote: > > > On Wed, 4 Oct 2017 05:09:09 +0300 > > > "Michael S. Tsirkin" wrote: > > > > > > > On Mon, Oct

Re: [PATCH 2/2] perf, tools, stat: Reset ids counter when retrying events

> Poisoned by user: f7 > ASan internal: fe > Forgot add. This should be Cc: sta...@vger.kernel.org # 4.4+ [it breaks pmu-tools] -Andi

Re: [PATCH 2/2] perf, tools, stat: Reset ids counter when retrying events

> Poisoned by user: f7 > ASan internal: fe > Forgot add. This should be Cc: sta...@vger.kernel.org # 4.4+ [it breaks pmu-tools] -Andi

Re: [PATCH v2 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

Hi Dmitry, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.14-rc3 next-20170929] [cannot apply to tegra/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

Hi Dmitry, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.14-rc3 next-20170929] [cannot apply to tegra/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH]Support new Alps HID Touchpad device

Hi, Jiri, Sorry, I have fixed the build warning error, and send the patch again. Best Regards, Masaki Ota

[PATCH 1/7] Delete unnecessary structure

From: Masaki Ota -Delete "struct u1_dev devInfo" structure, because u1_dev structure is already declared as "struct u1_dev *data", and this structure is used for getting U1 data in [PATCH 2/7]. Signed-off-by: Masaki Ota ---

[PATCH]Support new Alps HID Touchpad device

Hi, Jiri, Sorry, I have fixed the build warning error, and send the patch again. Best Regards, Masaki Ota

[PATCH 1/7] Delete unnecessary structure

From: Masaki Ota -Delete "struct u1_dev devInfo" structure, because u1_dev structure is already declared as "struct u1_dev *data", and this structure is used for getting U1 data in [PATCH 2/7]. Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 69

[PATCH 2/7] Separate U1 device code

From: Masaki Ota -Create "static int u1_init()" function for separate U1 device initialization code from Main initialization. -Create "has_sp" variable for checking whether it has SP device or not. Signed-off-by: Masaki Ota ---

[PATCH 2/7] Separate U1 device code

From: Masaki Ota -Create "static int u1_init()" function for separate U1 device initialization code from Main initialization. -Create "has_sp" variable for checking whether it has SP device or not. Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 120

[PATCH 4/7] replace some variables

From: Masaki Ota -Move some variables(dev_ctrl, dev_type, sen_line_num_x, sen_line_num_y, pitch_x, pitch_y, resolution, btn_info) from u1_dev structure to "u1_init()", because these variables are only used in "u1_init()" function. Signed-off-by: Masaki Ota

[PATCH 4/7] replace some variables

From: Masaki Ota -Move some variables(dev_ctrl, dev_type, sen_line_num_x, sen_line_num_y, pitch_x, pitch_y, resolution, btn_info) from u1_dev structure to "u1_init()", because these variables are only used in "u1_init()" function. Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 67

[PATCH 6/7] Add new U1 device ID

From: Masaki Ota -Add new U1 device Product ID -This device is used on HP Elite book x360 series Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 3 +++ drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 1 + 3 files changed, 5

[PATCH 6/7] Add new U1 device ID

From: Masaki Ota -Add new U1 device Product ID -This device is used on HP Elite book x360 series Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 3 +++ drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 1 + 3 files changed, 5 insertions(+) diff --git a/drivers/hid/hid-alps.c

[PATCH 5/7] Support Alps T4 Touchpad device

From: Masaki Ota -Define T4 device specification value for support T4 device. -Create "t4_contact_data" and "t4_input_report" structure for decode T4 data and store it. -Create "t4_calc_check_sum()" function for calculate checksum value to send the device. T4 needs to

[PATCH 5/7] Support Alps T4 Touchpad device

From: Masaki Ota -Define T4 device specification value for support T4 device. -Create "t4_contact_data" and "t4_input_report" structure for decode T4 data and store it. -Create "t4_calc_check_sum()" function for calculate checksum value to send the device. T4 needs to send this value when

[PATCH 3/7] Add some variables

From: Masaki Ota -Create x_min, y_min and max_fingers variables for set correct XY minimum value and the number of max finger on each devices. -Move the Button pad checking code to U1 init function, because this checking code is for U1 device. Signed-off-by: Masaki Ota

[PATCH 7/7] Support Alps U1 USB Touchpad device

From: Masaki Ota -Add T4 USB device Product ID. (0x1216) -Separate T4 USB device initialization code from T4 Standard device code. -T4 USB device is used on HP Elite x2 series Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 35

[PATCH 7/7] Support Alps U1 USB Touchpad device

From: Masaki Ota -Add T4 USB device Product ID. (0x1216) -Separate T4 USB device initialization code from T4 Standard device code. -T4 USB device is used on HP Elite x2 series Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 35 +-- drivers/hid/hid-core.c

[PATCH 3/7] Add some variables

From: Masaki Ota -Create x_min, y_min and max_fingers variables for set correct XY minimum value and the number of max finger on each devices. -Move the Button pad checking code to U1 init function, because this checking code is for U1 device. Signed-off-by: Masaki Ota ---

[PATCH v5 4/5] cramfs: add mmap support

When cramfs_physmem is used then we have the opportunity to map files directly from ROM, directly into user space, saving on RAM usage. This gives us Execute-In-Place (XIP) support. For a file to be mmap()-able, the map area has to correspond to a range of uncompressed and contiguous blocks, and

[PATCH v5 4/5] cramfs: add mmap support

When cramfs_physmem is used then we have the opportunity to map files directly from ROM, directly into user space, saving on RAM usage. This gives us Execute-In-Place (XIP) support. For a file to be mmap()-able, the map area has to correspond to a range of uncompressed and contiguous blocks, and

[PATCH v5 3/5] cramfs: implement uncompressed and arbitrary data block positioning

Two new capabilities are introduced here: - The ability to store some blocks uncompressed. - The ability to locate blocks anywhere. Those capabilities can be used independently, but the combination opens the possibility for execute-in-place (XIP) of program text segments that must remain

[PATCH v5 3/5] cramfs: implement uncompressed and arbitrary data block positioning

Two new capabilities are introduced here: - The ability to store some blocks uncompressed. - The ability to locate blocks anywhere. Those capabilities can be used independently, but the combination opens the possibility for execute-in-place (XIP) of program text segments that must remain

[PATCH v5 0/5] cramfs refresh for embedded usage

This series brings a nice refresh to the cramfs filesystem, adding the following capabilities: - Direct memory access, bypassing the block and/or MTD layers entirely. - Ability to store individual data blocks uncompressed. - Ability to locate individual data blocks anywhere in the filesystem.

[PATCH v5 1/5] cramfs: direct memory access support

Small embedded systems typically execute the kernel code in place (XIP) directly from flash to save on precious RAM usage. This adds the ability to consume filesystem data directly from flash to the cramfs filesystem as well. Cramfs is particularly well suited to this feature as it is very simple

[PATCH v5 2/5] cramfs: make cramfs_physmem usable as root fs

Signed-off-by: Nicolas Pitre Tested-by: Chris Brandt --- init/do_mounts.c | 8 1 file changed, 8 insertions(+) diff --git a/init/do_mounts.c b/init/do_mounts.c index c2de5104aa..43b5817f60 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c

[PATCH v5 2/5] cramfs: make cramfs_physmem usable as root fs

Signed-off-by: Nicolas Pitre Tested-by: Chris Brandt --- init/do_mounts.c | 8 1 file changed, 8 insertions(+) diff --git a/init/do_mounts.c b/init/do_mounts.c index c2de5104aa..43b5817f60 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -556,6 +556,14 @@ void __init

[PATCH v5 0/5] cramfs refresh for embedded usage

This series brings a nice refresh to the cramfs filesystem, adding the following capabilities: - Direct memory access, bypassing the block and/or MTD layers entirely. - Ability to store individual data blocks uncompressed. - Ability to locate individual data blocks anywhere in the filesystem.

[PATCH v5 1/5] cramfs: direct memory access support

Small embedded systems typically execute the kernel code in place (XIP) directly from flash to save on precious RAM usage. This adds the ability to consume filesystem data directly from flash to the cramfs filesystem as well. Cramfs is particularly well suited to this feature as it is very simple

  1   2   3   4   5   6   7   8   9   10   >