On Wed, 2021-04-14 at 13:50 +, David Laight wrote:
> From: Niklas Schnelle
> > Sent: 14 April 2021 13:35
> >
> > On Tue, 2021-04-13 at 14:12 +, David Laight wrote:
> > > From: Arnd Bergmann
> > > > Sent: 13 April 2021 14:40
> > > >
> > > > On Tue, Apr 13, 2021 at 3:06 PM David Laight
>
From: Niklas Schnelle
> Sent: 14 April 2021 13:35
>
> On Tue, 2021-04-13 at 14:12 +, David Laight wrote:
> > From: Arnd Bergmann
> > > Sent: 13 April 2021 14:40
> > >
> > > On Tue, Apr 13, 2021 at 3:06 PM David Laight
> > > wrote:
> > > > From: Arnd Bergmann
> > > > > Sent: 13 April 2021
On Tue, 2021-04-13 at 14:12 +, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 13 April 2021 14:40
> >
> > On Tue, Apr 13, 2021 at 3:06 PM David Laight
> > wrote:
> > > From: Arnd Bergmann
> > > > Sent: 13 April 2021 13:58
> > > ...
> > > > The remaining ones (csky, m68k, sparc32) need
From: Arnd Bergmann
> Sent: 13 April 2021 14:40
>
> On Tue, Apr 13, 2021 at 3:06 PM David Laight wrote:
> >
> > From: Arnd Bergmann
> > > Sent: 13 April 2021 13:58
> > ...
> > > The remaining ones (csky, m68k, sparc32) need to be inspected
> > > manually to see if they currently support PCI I/O
On Tue, Apr 13, 2021 at 9:40 PM Arnd Bergmann wrote:
>
> On Tue, Apr 13, 2021 at 3:06 PM David Laight wrote:
> >
> > From: Arnd Bergmann
> > > Sent: 13 April 2021 13:58
> > ...
> > > The remaining ones (csky, m68k, sparc32) need to be inspected
> > > manually to see if they currently support PCI
On Tue, Apr 13, 2021 at 3:06 PM David Laight wrote:
>
> From: Arnd Bergmann
> > Sent: 13 April 2021 13:58
> ...
> > The remaining ones (csky, m68k, sparc32) need to be inspected
> > manually to see if they currently support PCI I/O space but in
> > fact use address zero as the base (with large
From: Arnd Bergmann
> Sent: 13 April 2021 13:58
...
> The remaining ones (csky, m68k, sparc32) need to be inspected
> manually to see if they currently support PCI I/O space but in
> fact use address zero as the base (with large resources) or they
> should also turn the operations into a NOP.
I'd
On Tue, Apr 13, 2021 at 2:38 PM Niklas Schnelle wrote:
> On Tue, 2021-04-13 at 14:26 +0200, Arnd Bergmann wrote:
> > I think the real underlying problem is that '0' is a particularly bad
> > default value,
> > we should not have used this one in asm-generic, or maybe have left it as
> > mandatory
From: Arnd Bergmann
> Sent: 13 April 2021 13:27
>
> On Tue, Apr 13, 2021 at 1:54 PM Niklas Schnelle
> wrote:
> >
> > When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
> > in calls to the readX/writeX primitives. While mathematically obvious
> > this triggers clang's
On Tue, 2021-04-13 at 14:26 +0200, Arnd Bergmann wrote:
> On Tue, Apr 13, 2021 at 1:54 PM Niklas Schnelle
> wrote:
> > When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
> > in calls to the readX/writeX primitives. While mathematically obvious
> > this triggers clang's
On Tue, Apr 13, 2021 at 1:54 PM Niklas Schnelle wrote:
>
> When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
> in calls to the readX/writeX primitives. While mathematically obvious
> this triggers clang's -Wnull-pointer-arithmetic warning.
Indeed, this is an annoying
When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
in calls to the readX/writeX primitives. While mathematically obvious
this triggers clang's -Wnull-pointer-arithmetic warning.
An additional complication is that PCI_IOBASE is explicitly typed as
"void __iomem *" which causes
12 matches
Mail list logo
