Re: PowerPC agpmode issues

On Thu, Aug 25, 2016 at 5:09 AM, Mike wrote: > Any improvement on your ends? Seems -1 is now the quirk. But does your > trackpads work? Did an update after getting a new and the latest released > powerbook up. Also found an interesting interface which can replace our ide

Re: PowerPC agpmode issues

Any improvement on your ends? Seems -1 is now the quirk. But does your trackpads work? Did an update after getting a new and the latest released powerbook up. Also found an interesting interface which can replace our ide drives, intended for ipod classics, but it can fit in the bay and has msata

Re: [PATCH] powerpc/ptrace: Fix cppcheck issue in gpr32_set_common/gpr32_get_common.

Simon Guo writes: > I think keeping tm_active argument for "ifndef CONFIG_PPC_TRANSACTIONAL_MEM" > case (with __maybe_unused prefix) will be somehow strange -- Whatever > value is provided in the caller function for tm_active, programmer might be > puzzled and cost

[RFC PATCH] powerpc: fsl_pci: fix inbound ATMU entries for systems with >4G RAM

For systems with >4G of RAM, the current implementation adds a second inbound PCIe window starting at 128G this leaves all memory from 4G to 128G inaccessible to inbound PCIe transactions. The according errors can be observed by using the EDAC driver for MPC85XX. This patch changes this behaviour

Re: [RFC PATCH] powerpc: fsl_pci: fix inbound ATMU entries for systems with >4G RAM

On 08/24/2016 02:48 PM, Tillmann Heidsieck wrote: > For systems with >4G of RAM, the current implementation adds a second > inbound PCIe window starting at 128G this leaves all memory from 4G to > 128G inaccessible to inbound PCIe transactions. The second inbound window is at 256G, and it maps

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

On Wed, Aug 24, 2016 at 08:55:55AM +0200, Daniel Vetter wrote: > On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez wrote: > > Thou shalt not make firmware calls early on init or probe. <-- snip --> > > There are 4 offenders at this time: > > > > mcgrof@ergon ~/linux-next

[PATCH] powerpc/powernv/pci: Use kmalloc_array() in two functions

From: Markus Elfring Date: Wed, 24 Aug 2016 22:26:37 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus reuse the corresponding function "kmalloc_array". This issue was detected

Re: [PATCH] ALSA: snd-aoa: enable sound on PowerBook G4 12"

Hi, On Wed, Aug 24, 2016 at 09:43:23PM +0200, Johannes Berg wrote: > On Wed, 2016-08-24 at 20:57 +0300, Aaro Koskinen wrote: > > Enable sound on PowerBook G4 12". > > Looks good to me, I assume you tested it and it works :) Yes, I have this laptop in use. A.

Re: [PATCH] ALSA: snd-aoa: enable sound on PowerBook G4 12"

On Wed, 2016-08-24 at 20:57 +0300, Aaro Koskinen wrote: > Enable sound on PowerBook G4 12". Looks good to me, I assume you tested it and it works :) johannes > Signed-off-by: Aaro Koskinen > --- >  sound/aoa/fabrics/layout.c   | 8 >  

[PATCH] ALSA: snd-aoa: enable sound on PowerBook G4 12"

Enable sound on PowerBook G4 12". Signed-off-by: Aaro Koskinen --- sound/aoa/fabrics/layout.c | 8 sound/aoa/soundbus/i2sbus/core.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c

Re: [PATCH 3/3] net: fs_enet: make rx_copybreak value configurable

On 08/24/2016 03:36 AM, Christophe Leroy wrote: > Measurement shows that on a MPC8xx running at 132MHz, the optimal > limit is 112: > * 114 bytes packets are processed in 147 TB ticks with higher copybreak > * 114 bytes packets are processed in 148 TB ticks with lower copybreak > * 128 bytes

Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start

On 08/24/2016 04:48 PM, Balbir Singh wrote: > > > On 25/08/16 00:44, Daniel Lezcano wrote: >> On 08/19/2016 12:26 AM, Gautham R. Shenoy wrote: >>> From: "Gautham R. Shenoy" >>> >>> Currently all the idle states registered by a cpu-idle driver are >>> enabled by default.

Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start

On 25/08/16 00:44, Daniel Lezcano wrote: > On 08/19/2016 12:26 AM, Gautham R. Shenoy wrote: >> From: "Gautham R. Shenoy" >> >> Currently all the idle states registered by a cpu-idle driver are >> enabled by default. This patch adds a mechanism which allows the >> driver

Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start

On 08/19/2016 12:26 AM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > Currently all the idle states registered by a cpu-idle driver are > enabled by default. This patch adds a mechanism which allows the > driver to hint if an idle-state should start in a

[PATCH -next] ibmvnic: convert to use simple_open()

From: Wei Yongjun Remove an open coded simple_open() function and replace file operations references to the function with simple_open() instead. Generated by: scripts/coccinelle/api/simple_open.cocci Signed-off-by: Wei Yongjun ---

[PATCH -next] ibmvnic: fix error return code in ibmvnic_probe()

From: Wei Yongjun Fix to return error code -ENOMEM from the dma_map_single error handling case instead of 0, as done elsewhere in this function. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Wei Yongjun ---

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

Le 24/08/2016 à 15:07, Eric Dumazet a écrit : On Wed, 2016-08-24 at 12:36 +0200, Christophe Leroy wrote: Initially, a NAPI TX routine has been implemented separately from NAPI RX, as done on the freescale/gianfar driver. By merging NAPI RX and NAPI TX, we reduce the amount of TX completion

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

On Wed, 2016-08-24 at 06:07 -0700, Eric Dumazet wrote: > I am afraid you could live lock here on SMP. > > You should make sure you do not loop forever, not assuming cpu is faster > than NIC. You are protected by the tx_lock spinlock, but this is fragile as you could very well remove this

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

On Wed, 2016-08-24 at 12:36 +0200, Christophe Leroy wrote: > Initially, a NAPI TX routine has been implemented separately from > NAPI RX, as done on the freescale/gianfar driver. > > By merging NAPI RX and NAPI TX, we reduce the amount of TX completion > interrupts. > > Handling of the budget in

[PATCH 3/3] net: fs_enet: make rx_copybreak value configurable

Measurement shows that on a MPC8xx running at 132MHz, the optimal limit is 112: * 114 bytes packets are processed in 147 TB ticks with higher copybreak * 114 bytes packets are processed in 148 TB ticks with lower copybreak * 128 bytes packets are processed in 154 TB ticks with higher copybreak *

[PATCH 2/3] net: fs_enet: don't unmap DMA when packet len is below copybreak

When the length of the packet is below the defined copybreak limit, the received packet is copied into a newly allocated skb in order to reuse the skb. This is only interesting if it allow us to avoid a new DMA mapping. We shall therefore not DMA unmap and remap the skb->data. Instead, we

[PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

Initially, a NAPI TX routine has been implemented separately from NAPI RX, as done on the freescale/gianfar driver. By merging NAPI RX and NAPI TX, we reduce the amount of TX completion interrupts. Handling of the budget in association with TX interrupts is based on indications provided at

[PATCH 0/3] Optimisation of fs_enet ethernet driver

This set optimises the freescale fs_enet ethernet driver: 1/ Merge of RX and TX NAPI functions in order to limit the amount of interrupts 2/ Do not unmap DMA when packets len is below copybreak, otherwise there is no benefit in copying the skb instead of allocating a new one 3/ Make copybreak

[PATCH 4/4] powerpc/mm: Update the HID bit when switching from radix to hash

Power9 DD1 requires to update the hid0 register when switching from hash to radix. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/reg.h | 3 +++ arch/powerpc/mm/hash_utils_64.c | 25 + arch/powerpc/mm/pgtable-radix.c | 28

[PATCH 3/4] powerpc/mm/radix: Use different pte update sequence for different POWER9 revs

POWER9 DD1 requires pte to be marked invalid (V=0) before updating it with the new value. This makes this distinction for the different revisions. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/book3s/32/pgtable.h | 3 +-

[PATCH 2/4] powerpc/mm/radix: Use different RTS encoding for different POWER9 revs

POWER9 DD1 uses RTS - 28 for the RTS value but other revisions use RTS - 31. This makes this distinction for the different revisions Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/book3s/64/radix.h | 13 + 1 file changed, 9

[PATCH 1/4] powerpc/book3s: Add a cpu table entry for different POWER9 revs

Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/cputable.h | 4 +++- arch/powerpc/kernel/cputable.c | 19 +++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/cputable.h

Re: [PATCH v3 2/5] firmware: annotate thou shalt not request fw on init or probe

On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote: [snip] > --- > Documentation/firmware_class/README| 20 > drivers/base/Kconfig | 2 +- > .../request_firmware-avoid-init-probe-init.cocci | 130 > + > 3

Re: [PATCH] powerpc/ptrace: Fix cppcheck issue in gpr32_set_common/gpr32_get_common.

Hi Daniel, On Wed, Aug 24, 2016 at 12:21:23PM +1000, Daniel Axtens wrote: > Hi Simon, > > > The ckpt_regs usage in gpr32_set_common/gpr32_get_common() > > will lead to cppcheck error. > > > > [arch/powerpc/kernel/ptrace.c:2062]: (error) Uninitialized variable: > > ckpt_regs > >

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez wrote: > Thou shalt not make firmware calls early on init or probe. > > systemd already ripped support out for the usermode helper > a while ago, there are still users that require the usermode helper, > however systemd's use