On Sun, 8 May 2022, I wrote:
>
> That suggests to me that we need a "bool CONFIG_WARINGS_INTO_ERRORS" to
> control -Werror, which could be disabled for .config files (like make
> allmodconfig) where it is not helping.
>
I just noticed that we already have CONFIG_WERROR. So perhaps
Hi Arnd,
On Sat, 7 May 2022, Arnd Bergmann wrote:
> On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote:
> > On Fri, 6 May 2022, Niklas Schnelle wrote:
> > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > > >
> > > > > I mooted a s390
On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote:
> On Fri, 6 May 2022, Niklas Schnelle wrote:
> > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> > > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> > > >
> > > > I mooted a s390 inb() implementation like "return ~0" because that's
> > > > what
On Fri, 6 May 2022, Niklas Schnelle wrote:
> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> >
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> >
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > > > On
Hi Geert,
> > Sane access would require a single CPU instruction to read or write from
> > the configuration space. To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space. Such amount of address space seems
Hi David
On Fri, May 6, 2022 at 4:05 PM David Laight wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> >
Hi Maciej,
On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > > It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need
On Fri, 6 May 2022, David Laight wrote:
> > It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture. Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> >
On Fri, 6 May 2022, Geert Uytterhoeven wrote:
> A lng time ago, it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(),
From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
>
> > > The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO. Thank
On Fri, 6 May 2022, Arnd Bergmann wrote:
> > So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument? Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> Not sure. My best guess is that it would actually work as you'd
On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> >
> > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the
On Fri, 6 May 2022, David Laight wrote:
> > The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO. Thank you for your explanation.
>
> Actually I think x86 was the
On Fri, May 6, 2022 at 2:56 PM David Laight wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase. So
On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390
From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architecture
On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390
On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> > I think I'm missing something here. IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> >
> > (It has
On Fri, 6 May 2022, Arnd Bergmann wrote:
> > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase. So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
>
On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
> I think I'm missing something here. IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
> (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
>
On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
>
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
>
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
On Thu, 5 May 2022, Arnd Bergmann wrote:
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't. That makes me think
> > s390 could do something similar.
>
> No, this is actually the current situation, and it makes absolutely
On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what
On Thu, 5 May 2022, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what
On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > >
> > > The main goal is to avoid c), which is what happens on s390, but
> > > can also happen elsewhere.
On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> >
> > The main goal is to avoid c), which is what happens on s390, but
> > can also happen elsewhere. Catching b) would be nice as well,
> > but is much harder to do from generic
On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future
On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Port access. In a future patch
On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas wrote:
>
> On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> > of the I/O accessor
On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can
On Fri, 29 Apr 2022, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for
> I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
> of the I/O accessor functions inb()/outb() and friends on architectures
> which can not meaningfully
We introduce a new HAS_IOPORT Kconfig option to indicate support for
I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390 or
where such
33 matches
Mail list logo
