ev_byte_channel_send() assumes that its third argument is a 16 byte array.
Some places where it is called it may not be (or we can't easily tell
if it is). Newer compilers have started producing warnings about this,
so make sure we actually pass a 16 byte array.
There may be more elegant
KASAN support on Book3S is a bit tricky to get right:
- It would be good to support inline instrumentation so as to be able to
catch stack issues that cannot be caught with outline mode.
- Inline instrumentation requires a fixed offset.
- Book3S runs code in real mode after booting. Most
kasan is already implied by the directory name, we don't need to
repeat it.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
arch/powerpc/mm/kasan/Makefile | 2 +-
arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} | 0
2 files changed, 1 insertion(+), 1
KASAN is supported on 32-bit powerpc and the docs should reflect this.
Suggested-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
Documentation/dev-tools/kasan.rst | 3 ++-
Documentation/powerpc/kasan.txt | 12
2 files changed, 14
powerpc has a variable number of PTRS_PER_*, set at runtime based
on the MMU that the kernel is booted under.
This means the PTRS_PER_* are no longer constants, and therefore
breaks the build.
Define default MAX_PTRS_PER_*s in the same style as MAX_PTRS_PER_P4D.
As KASAN is the only user at the
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
This provides full inline instrumentation on radix, but does require
that you be able to specify the amount of physically contiguous memory
on the system at compile time.
Hi Krzysztof,
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the
> address so they can be converted to a "const" version for
On Thu, Sep 26, 2019 at 6:50 PM Shengjiu Wang wrote:
>
> When set the runtime hardware parameters, we may need to query
> the capability of DMA to complete the parameters.
>
> This patch is to Extract this operation from
> dmaengine_pcm_set_runtime_hwparams function to a separate function
>
https://bugzilla.kernel.org/show_bug.cgi?id=206049
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Hi Heiner, thank you for the quick answer.
> > Hi all,
> >
> > With the introduction of the following patch, we are facing an issue with
> the activation of the Freescale network device (ucc_geth driver) on our
> kmeter1 board based on a MPC8360:
>
> +Li as ucc_geth maintainer
>
> Can you
On Tue, Dec 10, 2019 at 12:49:03PM +0530, Balamuruhan S wrote:
> This patch adds emulation support for divde, divdeu instructions,
> * Divide Doubleword Extended (divde[.])
> * Divide Doubleword Extended Unsigned (divdeu[.])
>
> Signed-off-by: Balamuruhan S
> ---
>
On Wed, Jan 8, 2020 at 7:12 AM YueHaibing wrote:
>
> drivers/soc/fsl/qe/gpio.c: In function qe_pin_request:
> drivers/soc/fsl/qe/gpio.c:163:26: warning: variable mm_gc set but not used
> [-Wunused-but-set-variable]
>
> commit 1e714e54b5ca ("powerpc: qe_lib-gpio: use gpiochip data pointer")
>
From: Christophe Leroy
> Sent: 08 January 2020 08:49
...
> And as pointed by Arnd, the volatile is really only necessary for the
> dereference itself, should the arch use dereferencing.
I've had trouble with some versions of gcc and reading of 'volatile unsigned
char *'.
It tended to follow the
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
> some architectures void *__iomem address argument is a pointer to const,
> on some not.
>
> Implementations of ioreadX() do not modify the memory under the
On 1/8/20 1:05 PM, Krzysztof Kozlowski wrote:
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a
On 9/1/20 1:11 am, Frederic Barrat wrote:
It took me a while to parse exactly what you're doing here.
- In pnv_ioda_setup_dev_PE(), we take a reference on the pci_dev, this
is to protect a pointer in the pci_dn structure, but not to protect
the pointer in the pci_dev structure (which doesn't
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
some architectures void *__iomem address argument is a pointer to const,
on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
Hi,
Changes since v1
https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-k...@kernel.org/
1. Constify also ioreadX_rep() and mmio_insX(),
2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability,
3. Add Geert's review,
4. Re-order patches so all optional
On 2020-01-08 12:13 p.m., Dan Williams wrote:
> On Wed, Jan 8, 2020 at 11:08 AM David Hildenbrand wrote:
>>
>>
>>
>>> Am 08.01.2020 um 20:00 schrieb Dan Williams :
>>>
>>> On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote:
> On 2020-01-08 5:28 a.m., David Hildenbrand
On 08.01.2020 12:53, Matteo Ghidoni wrote:
> Hi Heiner, thank you for the quick answer.
>
>>> Hi all,
>>>
>>> With the introduction of the following patch, we are facing an issue with
>> the activation of the Freescale network device (ucc_geth driver) on our
>> kmeter1 board based on a MPC8360:
On Wed, Jan 8, 2020 at 11:08 AM David Hildenbrand wrote:
>
>
>
> > Am 08.01.2020 um 20:00 schrieb Dan Williams :
> >
> > On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote:
> >>
> >>
> >>
> >>> On 2020-01-08 5:28 a.m., David Hildenbrand wrote:
> >>> On 07.01.20 21:59, Logan Gunthorpe wrote:
>
> Am 08.01.2020 um 20:00 schrieb Dan Williams :
>
> On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote:
>>
>>
>>
>>> On 2020-01-08 5:28 a.m., David Hildenbrand wrote:
>>> On 07.01.20 21:59, Logan Gunthorpe wrote:
The mhp_restrictions struct really doesn't specify anything
On Wed, Jan 8, 2020 at 9:17 AM Logan Gunthorpe wrote:
>
>
>
> On 2020-01-08 5:28 a.m., David Hildenbrand wrote:
> > On 07.01.20 21:59, Logan Gunthorpe wrote:
> >> The mhp_restrictions struct really doesn't specify anything resembling
> >> a restriction anymore so rename it to be mhp_modifiers.
>
On 2020-01-08 5:43 a.m., David Hildenbrand wrote:
> On 07.01.20 21:59, Logan Gunthorpe wrote:
>> In prepartion to support a pgprot_t argument for arch_add_memory().
>>
>> Cc: Heiko Carstens
>> Cc: Vasily Gorbik
>> Cc: Christian Borntraeger
>> Signed-off-by: Logan Gunthorpe
>> ---
>>
On 2020-01-08 5:42 a.m., Michal Hocko wrote:
> On Tue 07-01-20 13:59:58, Logan Gunthorpe wrote:
>> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
>> struct page mappings for IO memory. At present, these mappings are created
>> with PAGE_KERNEL which implies setting the
On 2020-01-08 5:39 a.m., David Hildenbrand wrote:
> On 07.01.20 21:59, Logan Gunthorpe wrote:
>> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
>> struct page mappings for IO memory. At present, these mappings are created
>> with PAGE_KERNEL which implies setting the
On 2020-01-08 5:28 a.m., David Hildenbrand wrote:
> On 07.01.20 21:59, Logan Gunthorpe wrote:
>> The mhp_restrictions struct really doesn't specify anything resembling
>> a restriction anymore so rename it to be mhp_modifiers.
>
> I wonder if something like "mhp_params" would be even better.
Le 24/12/2019 à 06:55, Russell Currey a écrit :
With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
W+X page at boot by default. This can be tested with
CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
kernel log during boot.
powerpc doesn't implement
On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
>
> Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
> processes. For backward compatibility reasons access to perf_events
> subsystem remains open for CAP_SYS_ADMIN privileged processes but
> CAP_SYS_ADMIN usage
Le 08/01/2020 à 08:33, Andrew Donnellan a écrit :
On 22/11/19 12:49 am, Frederic Barrat wrote:
The pci_dn structure used to store a pointer to the struct pci_dev, so
taking a reference on the device was required. However, the pci_dev
pointer was later removed from the pci_dn structure, but
Greeting's
Kernel Oops on my powerpc system when unloading driver mpt3sas.
Thanks Oliver for bisecting it to commit 3acac06 ("dma-mapping: merge
the generic remapping helpers into dma-direct")
Christoph, could you please have a look
Kernel version : latest mainline and next kernel
System :
drivers/soc/fsl/qe/gpio.c: In function qe_pin_request:
drivers/soc/fsl/qe/gpio.c:163:26: warning: variable mm_gc set but not used
[-Wunused-but-set-variable]
commit 1e714e54b5ca ("powerpc: qe_lib-gpio: use gpiochip data pointer")
left behind this unused variable.
Reported-by: Hulk Robot
Le 24/12/2019 à 06:55, Russell Currey a écrit :
The set_memory_{ro/rw/nx/x}() functions are required for STRICT_MODULE_RWX,
and are generally useful primitives to have. This implementation is
designed to be completely generic across powerpc's many MMUs.
It's possible that this could be
On 07.01.20 21:59, Logan Gunthorpe wrote:
> In prepartion to support a pgprot_t argument for arch_add_memory().
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> Signed-off-by: Logan Gunthorpe
> ---
> arch/s390/include/asm/pgtable.h | 3 ++-
> arch/s390/mm/extmem.c
On Tue 07-01-20 13:59:58, Logan Gunthorpe wrote:
> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
> struct page mappings for IO memory. At present, these mappings are created
> with PAGE_KERNEL which implies setting the PAT bits to be WB. However, on
> x86, an mtrr
On 07.01.20 21:59, Logan Gunthorpe wrote:
> devm_memremap_pages() is currently used by the PCI P2PDMA code to create
> struct page mappings for IO memory. At present, these mappings are created
> with PAGE_KERNEL which implies setting the PAT bits to be WB. However, on
> x86, an mtrr register will
On 07.01.20 21:59, Logan Gunthorpe wrote:
> The mhp_restrictions struct really doesn't specify anything resembling
> a restriction anymore so rename it to be mhp_modifiers.
I wonder if something like "mhp_params" would be even better. It's
essentially just a way to avoid changing call chains
On 07.01.20 21:59, Logan Gunthorpe wrote:
> This variable is not used anywhere and should therefore be removed
> from the structure.
>
> Signed-off-by: Logan Gunthorpe
> ---
> include/linux/memory_hotplug.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On Wed, Jan 8, 2020 at 10:15 AM Krzysztof Kozlowski wrote:
> > The __force-cast that removes the __iomem here also means that
> > the 'volatile' keyword could be dropped from the argument list,
> > as it has no real effect any more, but then there are a few drivers
> > that mark their iomem
On Wed, Dec 11, 2019 at 09:39:07PM +0530, Sourabh Jain wrote:
> As the number of FADump sysfs files increases it is hard to manage all of
> them inside /sys/kernel directory. It's better to have all the FADump
> related sysfs files in a dedicated directory /sys/kernel/fadump. But in
> order to
On 10/12/19 12:49 pm, Balamuruhan S wrote:
> Hi All,
>
> This patchset adds support to emulate divde, divde., divdeu and divdeu.
> instructions and testcases for it.
>
LGTM.
Reviewed-by: Sandipan Das
Many of the performance moniroting unit (PMU) SPRs are
exposed in the sysfs. This may not be a desirable since
"perf" API is the primary interface to program PMU and
collect counter data in the system. But that said, we
cant remove these sysfs files since we dont whether
anyone/anything is using
On Wed, Jan 08, 2020 at 09:44:36AM +0100, Arnd Bergmann wrote:
> On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy
> wrote:
> > Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > > wrote:
> > > I'll add to this one also changes to
On Wed, Jan 08, 2020 at 09:10:06AM +0100, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
> > The ioreadX() helpers have inconsistent interface. On some architectures
> > void *__iomem address argument is a pointer to const, on some not.
>
At several places pmd pointer is retrieved through the same action:
pmd = pmd_offset(pud_offset(pgd_offset(mm, addr), addr), addr);
or
pmd = pmd_offset(pud_offset(pgd_offset_k(addr), addr), addr);
Refactor this by implementing two helpers pmd_ptr() and pmd_ptr_k()
This will
Hi Geert,
Le 08/01/2020 à 09:43, Geert Uytterhoeven a écrit :
Hi Christophe,
On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote:
Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote:
On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven
On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy wrote:
> Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > wrote:
> > I'll add to this one also changes to ioreadX_rep() and add another
> > patch for volatile for reads and writes. I
Hi Christophe,
On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote:
> Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > wrote:
> >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven
> >> wrote:
> >>> On Tue, Jan 7, 2020 at 5:53 PM
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.5-rc5 next-20200106]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base'
Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote:
Hi Krzysztof,
On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote:
On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
The ioread8/16/32() and others have inconsistent
On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote:
>
> Hi Krzysztof,
>
> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven
> wrote:
> > On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
> > > The ioread8/16/32() and others have inconsistent interface among the
> > > architectures:
On Wed, 8 Jan 2020 at 09:08, Geert Uytterhoeven wrote:
>
> Hi Krzysztof,
>
> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
> > The ioread8/16/32() and others have inconsistent interface among the
> > architectures: some taking address as const, some not.
> >
> > It seems there is
Hi Krzysztof,
On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote:
> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
> > The ioread8/16/32() and others have inconsistent interface among the
> > architectures: some taking address as const, some not.
> >
> > It seems there is
Hi Krzysztof,
On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
>
Hi Krzysztof,
On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
> The ioread8/16/32() and others have inconsistent interface among the
> architectures: some taking address as const, some not.
>
> It seems there is nothing really stopping all of them to take
> pointer to const.
Shouldn't
63 matches
Mail list logo
