[PATCH-next v2 1/2] cpufreq: powernv: Move smp_call_function_any() out of irq safe block

Fix a WARN_ON caused by smp_call_function_any() when irq is disabled, because of changes made in the patch ('cpufreq: powernv: Ramp-down global pstate slower than local-pstate') https://patchwork.ozlabs.org/patch/612058/ WARNING: CPU: 0 PID: 4 at kernel/smp.c:291

[PATCH-next v2 2/2] cpufreq: powernv: del_timer_sync when global and local pstate are equal

When global and local pstate are equal in a powernv_target_index() call, we don't queue a timer. But we may have timer already queued for future. This could cause the timer to fire one additional time for no use. Signed-off-by: Akshay Adiga --- Patch is based on

[PATCH-next v2 1/2] cpufreq: powernv: Move smp_call_function_any() out of irq safe block

Fix a WARN_ON caused by smp_call_function_any() when irq is disabled, because of changes made in the patch ('cpufreq: powernv: Ramp-down global pstate slower than local-pstate') https://patchwork.ozlabs.org/patch/612058/ WARNING: CPU: 0 PID: 4 at kernel/smp.c:291

[PATCH-next v2 2/2] cpufreq: powernv: del_timer_sync when global and local pstate are equal

When global and local pstate are equal in a powernv_target_index() call, we don't queue a timer. But we may have timer already queued for future. This could cause the timer to fire one additional time for no use. Signed-off-by: Akshay Adiga --- Patch is based on Rafael's linux-next

[PATCH 13/20] X86_64, UV: Fold blade info into per node hub info structs

Migrate references from the blade info structs to the per node hub info structs. This phases out the allocation of the list of per blade info structs on node 0, in favor of a per node hub info struct allocated on the node's local memory. There are also some minor cosemetic changes in the

[PATCH 15/20] X86_64, UV: Add obtaining GAM Range Table from UV BIOS

UV4 uses a GAM (globally addressed memory) architecture that supports variable sized memory per node. This replaces the old "M" value (number of address bits per node) with a range table for conversions between addresses and physical node (pnode) id's. This table is obtained from UV BIOS via the

[PATCH 14/20] X86_64, UV: Add UV4 addressing discovery function

UV4 requires early system wide addressing values. This involves the use of the CPUID instruction to obtain these values. The current function (detect_extended_topology()) in the kernel has been copied and streamlined, with the limitation that only CPU's used by UV architectures are supported.

[PATCH 10/20] X86_64, UV: Move scir info to the per cpu info struct

Change the references to the SCIR fields to the new per cpu info structs. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer

[PATCH 11/20] X86_64, UV: Move blade local processor ID to the per cpu info struct

Move references to blade local processor ID to the new per cpu info structs. Create an access function that makes this move, and other potential moves opaque to callers of this function. Define a flag that indicates to callers in external GPL modules that this function replaces any local

[PATCH-next v2 0/2] cpufreq: powernv: Fixes for Global pstate management

Fixes are based on patch https://patchwork.ozlabs.org/patch/612058/ which is in Rafael's linux-next. - Patch [1] fixes WARN_ON in powernv_target_index() - Patch [2] Deleting any pending timer to saves an unnecessary irq call in powernv_target_index() Akshay Adiga (2): cpufreq: powernv: Move

[PATCH 09/20] X86_64, UV: Create per cpu info structs to replace per hub info structs

The major portion of the hub info is common to all cpus on that hub. This is step one of moving the per cpu hub info to a per node hub info struct. This patch creates the small per cpu info struct that will contain only information specific to each CPU. Signed-off-by: Mike Travis

Re: [PATCH 7/8] wbt: add general throttling mechanism

On 05/03/2016 09:22 AM, Jan Kara wrote: On Tue 03-05-16 08:23:27, Jens Axboe wrote: On 05/03/2016 03:34 AM, Jan Kara wrote: On Thu 28-04-16 12:53:50, Jens Axboe wrote: 2) As far as I can see in patch 8/8, you have plugged the throttling above the IO scheduler. When there are e.g. multiple

[PATCH 13/20] X86_64, UV: Fold blade info into per node hub info structs

Migrate references from the blade info structs to the per node hub info structs. This phases out the allocation of the list of per blade info structs on node 0, in favor of a per node hub info struct allocated on the node's local memory. There are also some minor cosemetic changes in the

[PATCH 15/20] X86_64, UV: Add obtaining GAM Range Table from UV BIOS

UV4 uses a GAM (globally addressed memory) architecture that supports variable sized memory per node. This replaces the old "M" value (number of address bits per node) with a range table for conversions between addresses and physical node (pnode) id's. This table is obtained from UV BIOS via the

[PATCH 14/20] X86_64, UV: Add UV4 addressing discovery function

UV4 requires early system wide addressing values. This involves the use of the CPUID instruction to obtain these values. The current function (detect_extended_topology()) in the kernel has been copied and streamlined, with the limitation that only CPU's used by UV architectures are supported.

[PATCH 10/20] X86_64, UV: Move scir info to the per cpu info struct

Change the references to the SCIR fields to the new per cpu info structs. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer --- arch/x86/include/asm/uv/uv_hub.h | 17 ++---

[PATCH 11/20] X86_64, UV: Move blade local processor ID to the per cpu info struct

Move references to blade local processor ID to the new per cpu info structs. Create an access function that makes this move, and other potential moves opaque to callers of this function. Define a flag that indicates to callers in external GPL modules that this function replaces any local

[PATCH-next v2 0/2] cpufreq: powernv: Fixes for Global pstate management

Fixes are based on patch https://patchwork.ozlabs.org/patch/612058/ which is in Rafael's linux-next. - Patch [1] fixes WARN_ON in powernv_target_index() - Patch [2] Deleting any pending timer to saves an unnecessary irq call in powernv_target_index() Akshay Adiga (2): cpufreq: powernv: Move

[PATCH 09/20] X86_64, UV: Create per cpu info structs to replace per hub info structs

The major portion of the hub info is common to all cpus on that hub. This is step one of moving the per cpu hub info to a per node hub info struct. This patch creates the small per cpu info struct that will contain only information specific to each CPU. Signed-off-by: Mike Travis Reviewed-by:

Re: [PATCH 7/8] wbt: add general throttling mechanism

On 05/03/2016 09:22 AM, Jan Kara wrote: On Tue 03-05-16 08:23:27, Jens Axboe wrote: On 05/03/2016 03:34 AM, Jan Kara wrote: On Thu 28-04-16 12:53:50, Jens Axboe wrote: 2) As far as I can see in patch 8/8, you have plugged the throttling above the IO scheduler. When there are e.g. multiple

[PATCH 12/20] X86_64, UV: Allocate common per node hub info structs on local node

Allocate and setup per node hub info structs. CPU 0/Node 0 hub info is statically allocated to be accessible early in system startup. The remaining hub info structs are allocated on the node's local memory, and shared among the CPU's on that node. This leaves the small amount of info unique to

[PATCH 16/20] X86_64, UV: Support UV4 socket address changes

With the UV4 system architecture addressing changes, BIOS now provides this information via an EFI system table. This is the initial decoding of that system table. It also collects the sizing information for later allocation of dynamic conversion tables. Signed-off-by: Mike Travis

[PATCH 12/20] X86_64, UV: Allocate common per node hub info structs on local node

Allocate and setup per node hub info structs. CPU 0/Node 0 hub info is statically allocated to be accessible early in system startup. The remaining hub info structs are allocated on the node's local memory, and shared among the CPU's on that node. This leaves the small amount of info unique to

[PATCH 16/20] X86_64, UV: Support UV4 socket address changes

With the UV4 system architecture addressing changes, BIOS now provides this information via an EFI system table. This is the initial decoding of that system table. It also collects the sizing information for later allocation of dynamic conversion tables. Signed-off-by: Mike Travis Reviewed-by:

[PATCH net-next 4/5] treewide: replace dev->trans_start update with helper

Replace all trans_start updates with netif_trans_update helper. change was done via spatch: struct net_device *d; @@ - d->trans_start = jiffies + netif_trans_update(d) Compile tested only. Cc: user-mode-linux-de...@lists.sourceforge.net Cc: linux-xte...@linux-xtensa.org Cc:

[PATCH 18/20] X86_64, UV: Update physical address conversions for UV4

This patch builds support for the new conversions of physical addresses to and from sockets, pnodes and nodes in UV4. It is designed to be as efficient as possible as lookups are done inside an interrupt context in some cases. It will be further optimized when physical hardware is available to

[PATCH net-next 4/5] treewide: replace dev->trans_start update with helper

Replace all trans_start updates with netif_trans_update helper. change was done via spatch: struct net_device *d; @@ - d->trans_start = jiffies + netif_trans_update(d) Compile tested only. Cc: user-mode-linux-de...@lists.sourceforge.net Cc: linux-xte...@linux-xtensa.org Cc:

[PATCH 18/20] X86_64, UV: Update physical address conversions for UV4

This patch builds support for the new conversions of physical addresses to and from sockets, pnodes and nodes in UV4. It is designed to be as efficient as possible as lookups are done inside an interrupt context in some cases. It will be further optimized when physical hardware is available to

[PATCH 19/20] X86_64, UV: Remove Obsolete GRU MMR address translation

From: Dimitri Sivanich Use no-op messages in place of cross-partition interrupts when nacking a put message in the GRU. This allows us to remove MMR's as a destination from the GRU driver. Signed-off-by: Dimitri Sivanich Signed-off-by: Mike Travis

[PATCH 20/20] X86_64, UV: Fix incorrect nodes and pnodes for cpuless and memoryless nodes

From: Dimitri Sivanich This patch fixes the problem of incorrect nodes and pnodes being returned when referring to nodes that either have no cpus (AKA "headless") or no memory. Signed-off-by: Dimitri Sivanich Signed-off-by: Mike Travis

[PATCH 19/20] X86_64, UV: Remove Obsolete GRU MMR address translation

From: Dimitri Sivanich Use no-op messages in place of cross-partition interrupts when nacking a put message in the GRU. This allows us to remove MMR's as a destination from the GRU driver. Signed-off-by: Dimitri Sivanich Signed-off-by: Mike Travis Tested-by: John Estabrook Tested-by: Gary

[PATCH 20/20] X86_64, UV: Fix incorrect nodes and pnodes for cpuless and memoryless nodes

From: Dimitri Sivanich This patch fixes the problem of incorrect nodes and pnodes being returned when referring to nodes that either have no cpus (AKA "headless") or no memory. Signed-off-by: Dimitri Sivanich Signed-off-by: Mike Travis Tested-by: John Estabrook Tested-by: Gary Kroening

[PATCH 03/20] X86_64, UV: Add UV4 Specific Defines

Add UV4 specific defines to determine if current system type is a UV4 system. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer

[PATCH 05/20] X86_64, UV: Prep for UV4 MMR updates

Cleanup patch to rearrange code and modify some defines so the next patch, the new UV4 MMR definitions can be merged cleanly. * Clean up the M/N related address constants (M is # of address bits per blade, N is the # of blade selection bits per SSI/partition). * Fix the lookup of the alias

[PATCH 03/20] X86_64, UV: Add UV4 Specific Defines

Add UV4 specific defines to determine if current system type is a UV4 system. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer --- arch/x86/kernel/apic/x2apic_uv_x.c | 12 +--- 1 file changed, 9

[PATCH 05/20] X86_64, UV: Prep for UV4 MMR updates

Cleanup patch to rearrange code and modify some defines so the next patch, the new UV4 MMR definitions can be merged cleanly. * Clean up the M/N related address constants (M is # of address bits per blade, N is the # of blade selection bits per SSI/partition). * Fix the lookup of the alias

[PATCH 04/20] X86_64, UV: Add UV MMR Illegal Access Function

This new function is generated by the UV MMR generation script to identify MMR registers and fields that are not defined for a specific UV architecture. With this switch, the immediate panic can be replaced with a message and a bad return value allowing either hardware or the emulator to diagnose

[PATCH 04/20] X86_64, UV: Add UV MMR Illegal Access Function

This new function is generated by the UV MMR generation script to identify MMR registers and fields that are not defined for a specific UV architecture. With this switch, the immediate panic can be replaced with a message and a bad return value allowing either hardware or the emulator to diagnose

[PATCH 1/2] pinctrl: nomadik: hide nmk_gpio_get_mode when unused

nmk_gpio_get_mode is only used in one place, and that is conditionally compiled if DEBUG_FS is enabled. A recent cleanup has marked the definition 'static', which now leads to a warning: drivers/pinctrl/nomadik/pinctrl-nomadik.c:614:12: error: 'nmk_gpio_get_mode' defined but not used

[PATCH 1/2] pinctrl: nomadik: hide nmk_gpio_get_mode when unused

nmk_gpio_get_mode is only used in one place, and that is conditionally compiled if DEBUG_FS is enabled. A recent cleanup has marked the definition 'static', which now leads to a warning: drivers/pinctrl/nomadik/pinctrl-nomadik.c:614:12: error: 'nmk_gpio_get_mode' defined but not used

[PATCH 08/20] X86_64, UV: Update MMIOH setup function to work for both UV3 and UV4

Since UV3 and UV4 MMIOH regions are setup the same, we can use a common function to setup both. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan

[PATCH 08/20] X86_64, UV: Update MMIOH setup function to work for both UV3 and UV4

Since UV3 and UV4 MMIOH regions are setup the same, we can use a common function to setup both. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer --- arch/x86/kernel/apic/x2apic_uv_x.c |3 ++- 1 file

[PATCH 01/20] X86_64, UV: Add Initial UV4 definitions

Add preliminary UV4 defines. Signed-off-by: Mike Travis Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer --- arch/x86/include/asm/uv/uv_hub.h | 64 +++---

[PATCH 07/20] X86_64, UV: Clean up redunduncies after merge of UV4 MMR definitions

Clean up any redundancies caused by new UV4 MMR definitions superseding any previously definitions local to functions. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Reviewed-by: Andrew Banman Tested-by: John Estabrook

[PATCH 01/20] X86_64, UV: Add Initial UV4 definitions

Add preliminary UV4 defines. Signed-off-by: Mike Travis Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer --- arch/x86/include/asm/uv/uv_hub.h | 64 +++--- arch/x86/include/asm/uv/uv_mmrs.h | 22 + 2 files changed, 62

[PATCH 07/20] X86_64, UV: Clean up redunduncies after merge of UV4 MMR definitions

Clean up any redundancies caused by new UV4 MMR definitions superseding any previously definitions local to functions. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich Reviewed-by: Andrew Banman Tested-by: John Estabrook Tested-by: Gary Kroening Tested-by: Nathan Zimmer ---

[PATCH 02/20] X86_64, UV: Add UV Architecture Defines

Add defines to control which UV architectures are supported, and modify the 'if (is_uvX_*)' functions to return constant 0 for those not supported. This will help optimize code paths when support for specific UV arches is removed. Signed-off-by: Mike Travis Reviewed-by: Dimitri

[PATCH 02/20] X86_64, UV: Add UV Architecture Defines

Add defines to control which UV architectures are supported, and modify the 'if (is_uvX_*)' functions to return constant 0 for those not supported. This will help optimize code paths when support for specific UV arches is removed. Signed-off-by: Mike Travis Reviewed-by: Dimitri Sivanich

[PATCH 00/20] X86_64, UV: Update kernel for SGI UV4 support

This patch set primarily updates the Linux kernel to support the next generation SGI Ultraviolet system, UV4. This architecture change is a larger incremental change than previous UV updates because of a major change to the addressing scheme. Previous UV architectures used a fixed address width

[PATCH] phy: tegra-xusb: add pinctrl dependency

The newly added tegra xusb phy driver fails to link when CONFIG_PINCTRL is disabled, since that also leaves out the legacy probe function: ERROR: "tegra_xusb_padctl_legacy_probe" [drivers/phy/tegra/phy-tegra-xusb.ko] undefined! This adds a Kconfig dependency for it, depending on both

[PATCH 00/20] X86_64, UV: Update kernel for SGI UV4 support

This patch set primarily updates the Linux kernel to support the next generation SGI Ultraviolet system, UV4. This architecture change is a larger incremental change than previous UV updates because of a major change to the addressing scheme. Previous UV architectures used a fixed address width

[PATCH] phy: tegra-xusb: add pinctrl dependency

The newly added tegra xusb phy driver fails to link when CONFIG_PINCTRL is disabled, since that also leaves out the legacy probe function: ERROR: "tegra_xusb_padctl_legacy_probe" [drivers/phy/tegra/phy-tegra-xusb.ko] undefined! This adds a Kconfig dependency for it, depending on both

Re: [PATCH 4/6] soc/tegra: pmc: Register PMC child devices as platform device

On 02/05/16 13:17, Laxman Dewangan wrote: > Power Management Controller(PMC) of Tegra does the multiple chip > power related functionality for internal and IO interfacing. > Some of the functionalities are power gating of IP blocks, IO pads > voltage and power state configuration, system power

[PATCH 2/2] pinctrl: ns2: rename pinctrl_utils_dt_free_map

A conflict of two patches caused a build error when a function got renamed but a new user appeared in the other patch: drivers/pinctrl/bcm/pinctrl-ns2-mux.c:540:17: error: 'pinctrl_utils_dt_free_map' undeclared here (not in a function) .dt_free_map = pinctrl_utils_dt_free_map,

Re: [PATCH 4/6] soc/tegra: pmc: Register PMC child devices as platform device

On 02/05/16 13:17, Laxman Dewangan wrote: > Power Management Controller(PMC) of Tegra does the multiple chip > power related functionality for internal and IO interfacing. > Some of the functionalities are power gating of IP blocks, IO pads > voltage and power state configuration, system power

[PATCH 2/2] pinctrl: ns2: rename pinctrl_utils_dt_free_map

A conflict of two patches caused a build error when a function got renamed but a new user appeared in the other patch: drivers/pinctrl/bcm/pinctrl-ns2-mux.c:540:17: error: 'pinctrl_utils_dt_free_map' undeclared here (not in a function) .dt_free_map = pinctrl_utils_dt_free_map,

[PATCH] drm: sun4i: print DMA address correctly

The newly added sun4i drm driver prints a dma address using the %x format string, which cannot work when dma_addr_t is 64 bit, and gcc warns about this configuration: drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer': drm/sun4i/sun4i_backend.c:193:84: error: format '%x'

[PATCH] drm: sun4i: print DMA address correctly

The newly added sun4i drm driver prints a dma address using the %x format string, which cannot work when dma_addr_t is 64 bit, and gcc warns about this configuration: drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer': drm/sun4i/sun4i_backend.c:193:84: error: format '%x'

Re: [PATCH 7/8] wbt: add general throttling mechanism

On Tue 03-05-16 08:23:27, Jens Axboe wrote: > On 05/03/2016 03:34 AM, Jan Kara wrote: > >On Thu 28-04-16 12:53:50, Jens Axboe wrote: > >>>2) As far as I can see in patch 8/8, you have plugged the throttling above > >>>the IO scheduler. When there are e.g. multiple cgroups with different > >>>

Re: [PATCH 7/8] wbt: add general throttling mechanism

On Tue 03-05-16 08:23:27, Jens Axboe wrote: > On 05/03/2016 03:34 AM, Jan Kara wrote: > >On Thu 28-04-16 12:53:50, Jens Axboe wrote: > >>>2) As far as I can see in patch 8/8, you have plugged the throttling above > >>>the IO scheduler. When there are e.g. multiple cgroups with different > >>>

Re: [PATCH RESEND] rtsx_usb_ms: Use msleep_interruptible() in polling loop

On Tue, 2016-05-03 at 15:40 +0200, Oleg Nesterov wrote: > On 05/02, Andrew Morton wrote: > > > > > > On Mon, 02 May 2016 23:17:41 +0300 Oleksandr Natalenko wrote: > > > > > > > > rtsx_usb_ms creates a task that mostly sleeps, but tasks in > > > uninterruptible sleep still contribute to the

[PATCH] lightnvm: pass dma address to hardware rather than pointer

A recent change to lightnvm added code to pass a kernel pointer to the hardware, which gcc complained about: drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_rqtocmd': drivers/nvme/host/lightnvm.c:472:32: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

Re: [PATCH RESEND] rtsx_usb_ms: Use msleep_interruptible() in polling loop

On Tue, 2016-05-03 at 15:40 +0200, Oleg Nesterov wrote: > On 05/02, Andrew Morton wrote: > > > > > > On Mon, 02 May 2016 23:17:41 +0300 Oleksandr Natalenko wrote: > > > > > > > > rtsx_usb_ms creates a task that mostly sleeps, but tasks in > > > uninterruptible sleep still contribute to the

[PATCH] lightnvm: pass dma address to hardware rather than pointer

A recent change to lightnvm added code to pass a kernel pointer to the hardware, which gcc complained about: drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_rqtocmd': drivers/nvme/host/lightnvm.c:472:32: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

Re: [PATCH] gre6: add Kconfig dependency for NET_IPGRE_DEMUX

On Tue, May 3, 2016 at 8:19 AM, Arnd Bergmann wrote: > The ipv6 gre implementation was cleaned up to share more code > with the ipv4 version, but it can be enabled even when NET_IPGRE_DEMUX > is disabled, resulting in a link error: > > net/built-in.o: In function `gre_rcv': >

Re: [PATCH] gre6: add Kconfig dependency for NET_IPGRE_DEMUX

On Tue, May 3, 2016 at 8:19 AM, Arnd Bergmann wrote: > The ipv6 gre implementation was cleaned up to share more code > with the ipv4 version, but it can be enabled even when NET_IPGRE_DEMUX > is disabled, resulting in a link error: > > net/built-in.o: In function `gre_rcv': > :(.text+0x17f5d0):

[PATCH] gre6: add Kconfig dependency for NET_IPGRE_DEMUX

The ipv6 gre implementation was cleaned up to share more code with the ipv4 version, but it can be enabled even when NET_IPGRE_DEMUX is disabled, resulting in a link error: net/built-in.o: In function `gre_rcv': :(.text+0x17f5d0): undefined reference to `gre_parse_header' ERROR:

Re: [PATCH] arm64: tegra: fix compatible string for Tegra132 fuse node

On Tue, May 03, 2016 at 05:09:37PM +0800, Wei Ni wrote: > This patch changes the compatible of Tegra132 fuse node > to "nvidia,tegra132-efuse", instead of "nvidia,tegra1124-efuse". > Because the CONFIG_ARCH_TEGRA_124_SOC will not be enabled for > Tegra132, the fuse driver can't find the

[PATCH] gre6: add Kconfig dependency for NET_IPGRE_DEMUX

The ipv6 gre implementation was cleaned up to share more code with the ipv4 version, but it can be enabled even when NET_IPGRE_DEMUX is disabled, resulting in a link error: net/built-in.o: In function `gre_rcv': :(.text+0x17f5d0): undefined reference to `gre_parse_header' ERROR:

Re: [PATCH] arm64: tegra: fix compatible string for Tegra132 fuse node

On Tue, May 03, 2016 at 05:09:37PM +0800, Wei Ni wrote: > This patch changes the compatible of Tegra132 fuse node > to "nvidia,tegra132-efuse", instead of "nvidia,tegra1124-efuse". > Because the CONFIG_ARCH_TEGRA_124_SOC will not be enabled for > Tegra132, the fuse driver can't find the

Re: [PATCH v2] x86:sysfb_efi:efifb_set_system: fix miss valid address range in later BARs

On Mon, 02 May, at 03:11:20PM, Peter Jones wrote: > On Sun, May 01, 2016 at 12:21:05AM +0800, Wang YanQing wrote: > > We can't just break out when meet start is equal to zero, > > this will cause we miss valid address range in later BARs. > > > > On the other hand, it isn't enough to test start

Re: [PATCH v2] x86:sysfb_efi:efifb_set_system: fix miss valid address range in later BARs

On Mon, 02 May, at 03:11:20PM, Peter Jones wrote: > On Sun, May 01, 2016 at 12:21:05AM +0800, Wang YanQing wrote: > > We can't just break out when meet start is equal to zero, > > this will cause we miss valid address range in later BARs. > > > > On the other hand, it isn't enough to test start

[PATCH net-next 2/5] drivers: replace dev->trans_start accesses with dev_trans_start

a trans_start struct member exists twice: - in struct net_device (legacy) - in struct netdev_queue Instead of open-coding dev->trans_start usage to obtain the current trans_start value, use dev_trans_start() instead. This is not exactly the same, as dev_trans_start also considers the trans_start

[PATCH net-next 1/5] dmfe: kill DEVICE define

use net_device directly. Compile tested, objdiff shows no changes. Cc: linux-par...@vger.kernel.org Signed-off-by: Florian Westphal --- drivers/net/ethernet/dec/tulip/dmfe.c | 39 --- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git

[PATCH net-next 2/5] drivers: replace dev->trans_start accesses with dev_trans_start

a trans_start struct member exists twice: - in struct net_device (legacy) - in struct netdev_queue Instead of open-coding dev->trans_start usage to obtain the current trans_start value, use dev_trans_start() instead. This is not exactly the same, as dev_trans_start also considers the trans_start

[PATCH net-next 1/5] dmfe: kill DEVICE define

use net_device directly. Compile tested, objdiff shows no changes. Cc: linux-par...@vger.kernel.org Signed-off-by: Florian Westphal --- drivers/net/ethernet/dec/tulip/dmfe.c | 39 --- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git

[PATCH net-next 3/5] netdevice: add helper to update trans_start

trans_start exists twice: - as member of net_device (legacy) - as member of netdev_queue In order to get rid of the legacy case, add a helper for the dev->trans_update (this patch), then convert spots that do dev->trans_start = jiffies to use this helper (next patch). This would then allow us

[PATCH net-next 3/5] netdevice: add helper to update trans_start

trans_start exists twice: - as member of net_device (legacy) - as member of netdev_queue In order to get rid of the legacy case, add a helper for the dev->trans_update (this patch), then convert spots that do dev->trans_start = jiffies to use this helper (next patch). This would then allow us

[PATCH net-next 0/5] net: remove trans_start from struct net_device

We currently have two instances for trans_start, once in net_device and once in netdev_queue. This series removes trans_start from net_device. Updates to dev->trans_start are replaced with updates to netdev queue 0. This series is compile-tested only. Replacement is done in 3 steps: 1. Replace

[PATCH net-next 0/5] net: remove trans_start from struct net_device

We currently have two instances for trans_start, once in net_device and once in netdev_queue. This series removes trans_start from net_device. Updates to dev->trans_start are replaced with updates to netdev queue 0. This series is compile-tested only. Replacement is done in 3 steps: 1. Replace

[PATCH 3/3] HSI: omap-ssi: move omap_ssi_port_update_fclk

After the clk change support, the ssi omap ssi core driver now calls into the port driver to change fclk. This function was previously inside of an #ifdef, because it was only used when CONFIG_PM is enabled. Now it also gets used without power management support: drivers/hsi/built-in.o: In

[PATCH 3/3] HSI: omap-ssi: move omap_ssi_port_update_fclk

After the clk change support, the ssi omap ssi core driver now calls into the port driver to change fclk. This function was previously inside of an #ifdef, because it was only used when CONFIG_PM is enabled. Now it also gets used without power management support: drivers/hsi/built-in.o: In

[PATCH 2/3] HSI: omap-ssi: include pinctrl header files

The driver now uses some pinctrl functions, but fails to build if PINCTRL is disabled because the respective header files are only included indirectly: drivers/hsi/controllers/omap_ssi_core.c: In function 'ssi_clk_event': drivers/hsi/controllers/omap_ssi_core.c:317:4: error: implicit declaration

[PATCH 2/3] HSI: omap-ssi: include pinctrl header files

The driver now uses some pinctrl functions, but fails to build if PINCTRL is disabled because the respective header files are only included indirectly: drivers/hsi/controllers/omap_ssi_core.c: In function 'ssi_clk_event': drivers/hsi/controllers/omap_ssi_core.c:317:4: error: implicit declaration

Re: [PATCH] dmaengine: tegra: crash fix observed during dma client(UART) stress testing

On Tue, May 03, 2016 at 02:44:49PM +, Shardar Mohammed wrote: > Thanks for review. Please find my comments inline. > > > On 03/05/16 13:14, Shardar Shariff Md wrote: > > > During DMA client(UART) stress testing, observed below crash: > > > > > > [ 167.041591] Unable to handle kernel paging

[PATCH 1/3] HSI: omap-ssi: add COMMON_CLK dependency

Enabling the omap ssi driver without COMMON_CLK results in a build failure: drivers/hsi/controllers/omap_ssi_core.c: In function 'ssi_clk_event': drivers/hsi/controllers/omap_ssi_core.c:304:7: error: 'PRE_RATE_CHANGE' undeclared (first use in this function) This adds a Kconfig dependency to

Re: [PATCH] dmaengine: tegra: crash fix observed during dma client(UART) stress testing

On Tue, May 03, 2016 at 02:44:49PM +, Shardar Mohammed wrote: > Thanks for review. Please find my comments inline. > > > On 03/05/16 13:14, Shardar Shariff Md wrote: > > > During DMA client(UART) stress testing, observed below crash: > > > > > > [ 167.041591] Unable to handle kernel paging

[PATCH 1/3] HSI: omap-ssi: add COMMON_CLK dependency

Enabling the omap ssi driver without COMMON_CLK results in a build failure: drivers/hsi/controllers/omap_ssi_core.c: In function 'ssi_clk_event': drivers/hsi/controllers/omap_ssi_core.c:304:7: error: 'PRE_RATE_CHANGE' undeclared (first use in this function) This adds a Kconfig dependency to

[PATCH 5/7] powerpc/8xx: Don't use page table for linear memory space

Instead of using the first level page table to define mappings for the linear memory space, we can use direct mapping from the TLB handling routines. This has several advantages: * No need to read the tables at each TLB miss * No issue in 16k pages mode where the 1st level table maps 64 Mbytes

[PATCH 6/7] powerpc/8xx: Rework CONFIG_PIN_TLB handling

On recent kernels, with some debug options like for instance CONFIG_LOCKDEP, the BSS requires more than 8M memory, allthough the kernel code fits in the first 8M. Today, it is necessary to activate CONFIG_PIN_TLB to get more than 8M at startup, allthough pinning TLB is not necessary for that. We

[PATCH 5/7] powerpc/8xx: Don't use page table for linear memory space

Instead of using the first level page table to define mappings for the linear memory space, we can use direct mapping from the TLB handling routines. This has several advantages: * No need to read the tables at each TLB miss * No issue in 16k pages mode where the 1st level table maps 64 Mbytes

[PATCH 6/7] powerpc/8xx: Rework CONFIG_PIN_TLB handling

On recent kernels, with some debug options like for instance CONFIG_LOCKDEP, the BSS requires more than 8M memory, allthough the kernel code fits in the first 8M. Today, it is necessary to activate CONFIG_PIN_TLB to get more than 8M at startup, allthough pinning TLB is not necessary for that. We

[PATCH 2/7] powerpc/8xx: Map IMMR area with 512k page at a fixed address

Once the linear memory space has been mapped with 8Mb pages, as seen in the related commit, we get 11 millions DTLB missed during the reference 600s period. 77% of the misses are on user addresses and 23% are on kernel addresses (1 fourth for linear address space and 3 fourth for virtual address

[PATCH 2/7] powerpc/8xx: Map IMMR area with 512k page at a fixed address

Once the linear memory space has been mapped with 8Mb pages, as seen in the related commit, we get 11 millions DTLB missed during the reference 600s period. 77% of the misses are on user addresses and 23% are on kernel addresses (1 fourth for linear address space and 3 fourth for virtual address

[PATCH 0/3] HSI: omap-ssi: regressions against yesterday's linux-next

Hi Sebastian, One patch you added yesterday unfortunately caused (at least) three separate build problems with 32-bit ARM randconfig builds. These three patches should make it all work again. Arnd

[PATCH 0/3] HSI: omap-ssi: regressions against yesterday's linux-next

Hi Sebastian, One patch you added yesterday unfortunately caused (at least) three separate build problems with 32-bit ARM randconfig builds. These three patches should make it all work again. Arnd

Re: [PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

On 05/03/2016 03:05 AM, Baoquan He wrote: > I have a tiny concern about phys_pmd_init(), both phys_pud_init and > phys_pte_init name 2nd parameter as 'addr', phys_pmd_init use 'address'. > If this can be changed to make them look consistent completist would > have a good sleep from now on. Yes,

Re: [PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

On 05/03/2016 03:05 AM, Baoquan He wrote: > I have a tiny concern about phys_pmd_init(), both phys_pud_init and > phys_pte_init name 2nd parameter as 'addr', phys_pmd_init use 'address'. > If this can be changed to make them look consistent completist would > have a good sleep from now on. Yes,

Re: [PATCH] base: dd: don't remove driver_data in -EPROBE_DEFER case

On Tue, May 03, 2016 at 08:07:39AM -0700, Greg KH wrote: > On Tue, May 03, 2016 at 03:11:26PM +0200, Thierry Reding wrote: > > On Tue, Mar 08, 2016 at 11:15:22PM +0800, Yi Zhang wrote: > > > the driver_data may be used for sanity check, it fails the > > > probe() if driver_data is NULL after it is

Re: [PATCH] base: dd: don't remove driver_data in -EPROBE_DEFER case

On Tue, May 03, 2016 at 08:07:39AM -0700, Greg KH wrote: > On Tue, May 03, 2016 at 03:11:26PM +0200, Thierry Reding wrote: > > On Tue, Mar 08, 2016 at 11:15:22PM +0800, Yi Zhang wrote: > > > the driver_data may be used for sanity check, it fails the > > > probe() if driver_data is NULL after it is

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