Re: [PATCH] powerpc: Fix all occurences of "the the"

2022-05-19 Thread Brian W Hart
On Thu, May 19, 2022 at 12:26:29AM +1000, Michael Ellerman wrote: > Rather than waiting for the bots to fix these one-by-one, fix all > occurences of "the the" throughout arch/powerpc. > > Signed-off-by: Michael Ellerman > --- > arch/powerpc/boot/wrapper | 2 +- >

Re: [PATCH net] ibmvnic fix NULL tx_pools and rx_tools issue at do_reset

2020-08-25 Thread Brian W Hart
On Mon, Aug 24, 2020 at 07:49:23PM -0400, Dany Madden wrote: > From: Mingming Cao > > At the time of do_reset, ibmvnic tries to re-initalize the tx_pools > and rx_pools to avoid re-allocating the long term buffer. However > there is a window inside do_reset that the tx_pools and > rx_pools were

[PATCH] powerpc/powernv: update dev-dma_mask in pci_set_dma_mask() path

2014-07-31 Thread Brian W Hart
-off-by: Brian W. Hart ha...@linux.vnet.ibm.com --- I assume the failure to set dma_mask in this path was just an oversight. With this change everything still seems to work fine on my powernv setup, and dev-dma_mask now carries the appropriate value after pci_set_dma_mask(dev, DMA_BIT_MASK(64

Re: [PATCH V2] powerpc: Fail remap_4k_pfn() if PFN doesn't fit inside PTE

2014-07-10 Thread Brian W Hart
On Thu, Jul 10, 2014 at 02:12:19PM +0530, Madhusudanan Kandasamy wrote: V2 : Rewritten to avoid helper function as suggested by Stephen Rothwell. remap_4k_pfn() silently truncates upper bits of input 4K PFN if it cannot be contained in PTE. This leads invalid memory mapping and could result in

Re: [PATCH 1/1] powerpc: crtsaveres.o needed only when -Os flag is enabled

2014-04-29 Thread Brian W Hart
. as for a distro install where the kernel headers are provided by package, rather than being manually prepared from the sources). Tested-by: Brian W Hart ha...@linux.vnet.ibm.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

Re: [PATCH 2/2] Fix coding style errors

2014-01-31 Thread Brian W Hart
On Mon, Jan 27, 2014 at 09:07:34PM -0600, Brandon Stewart wrote: I corrected several coding errors. Signed-off-by: Brandon Stewart stewar...@gmail.com --- drivers/macintosh/adb.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/macintosh/adb.c

Re: [PATCH] powernv: eeh: fix possible buffer overrun in ioda_eeh_phb_diag()

2013-12-20 Thread Brian W Hart
On Fri, Dec 20, 2013 at 09:59:37AM +0800, Gavin Shan wrote: On Fri, Dec 20, 2013 at 09:35:39AM +0800, Gavin Shan wrote: On Thu, Dec 19, 2013 at 05:14:07PM -0600, Brian W Hart wrote: PHB diagnostic buffer may be smaller than PAGE_SIZE, especially when PAGE_SIZE 4KB. I think you're talking

Re: [PATCH] powernv: eeh: add buffer for P7IOC hub error data

2013-12-20 Thread Brian W Hart
On Fri, Dec 20, 2013 at 09:45:04AM +0800, Gavin Shan wrote: On Thu, Dec 19, 2013 at 05:18:53PM -0600, Brian W Hart wrote: Prevent ioda_eeh_hub_diag() from clobbering itself when called by supplying a buffer for P7IOC hub diagnostic data. Take care to inform OPAL of the correct size

[PATCH v2] powernv: eeh: add buffer for P7IOC hub error data

2013-12-20 Thread Brian W Hart
V2: Replace driver-global 'hub_diag' with a per-PHB hub diag structure. Prevent ioda_eeh_hub_diag() from clobbering itself when called by supplying a per-PHB buffer for P7IOC hub diagnostic data. Take care to inform OPAL of the correct size for the buffer. Signed-off-by: Brian W Hart ha

[PATCH] powernv: eeh: fix possible buffer overrun in ioda_eeh_phb_diag()

2013-12-19 Thread Brian W Hart
PHB diagnostic buffer may be smaller than PAGE_SIZE, especially when PAGE_SIZE 4KB. Signed-off-by: Brian W Hart ha...@linux.vnet.ibm.com --- arch/powerpc/platforms/powernv/eeh-ioda.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powernv/eeh

[PATCH] powernv: eeh: add buffer for P7IOC hub error data

2013-12-19 Thread Brian W Hart
Prevent ioda_eeh_hub_diag() from clobbering itself when called by supplying a buffer for P7IOC hub diagnostic data. Take care to inform OPAL of the correct size for the buffer. Signed-off-by: Brian W Hart ha...@linux.vnet.ibm.com --- I hope I've understood this correctly. It looks to me like