On Fri, 15 Sep 2023, Thomas Gleixner wrote:
> >> Patches 2-74 switch all uart port locking call sites to use the new
> >> wrappers. These patches were automatically generated using coccinelle.
> >
> > Hmm, no need to do this for drivers/tty/serial/zs.c?
>
> zs.c does not use port lock at all.
On Thu, 14 Sep 2023, John Ogness wrote:
> Patches 2-74 switch all uart port locking call sites to use the new
> wrappers. These patches were automatically generated using coccinelle.
Hmm, no need to do this for drivers/tty/serial/zs.c?
Maciej
On Fri, 16 Jun 2023, Bjorn Helgaas wrote:
> I agree that as I rearranged it, the workaround doesn't apply in all
> cases simultaneously. Maybe not ideal, but maybe not terrible either.
> Looking at it again, maybe it would have made more sense to move the
> pcie_wait_for_link_delay() change to
On Thu, 15 Jun 2023, Bjorn Helgaas wrote:
> > If doing it this way, which I actually like, I think it would be a little
> > bit better performance- and style-wise if this was written as:
> >
> > if (pci_is_pcie(dev)) {
> > bridge = pci_upstream_bridge(dev);
> >
On Wed, 14 Jun 2023, Bjorn Helgaas wrote:
> > This is v9 of the change to work around a PCIe link training phenomenon
> > where a pair of devices both capable of operating at a link speed above
> > 2.5GT/s seems unable to negotiate the link speed and continues training
> > indefinitely with
On Thu, 4 May 2023, Bjorn Helgaas wrote:
> We talked about reusing pcie_retrain_link() earlier. IIRC that didn't
> work: ASPM needs to use PCI_EXP_LNKSTA_LT because not all devices
> support PCI_EXP_LNKSTA_DLLLA, and you need PCI_EXP_LNKSTA_DLLLA
> because the erratum makes PCI_EXP_LNKSTA_LT
ort their data
link being up.
Signed-off-by: Maciej W. Rozycki
Link:
https://lore.kernel.org/r/alpine.deb.2.21.2203022037020.56...@angie.orcam.me.uk/
Link: https://source.denx.de/u-boot/u-boot/-/commit/a398a51ccc68
---
Changes from v8:
- Rename `pcie_downstream_link_retrain' to `pcie_failed_link_retr
Request failed link recovery with any upstream bridge where a device has
not come back after reset within PCI_RESET_WAIT time. Reset the polling
interval if recovery succeeded, otherwise continue as usual.
Signed-off-by: Maciej W. Rozycki
---
New change in v9, factored out from 7/7:
- Remove
This now fails unconditionally and will be always optimised away, but
provides for quirks to implement recovery for failed links detected in
device probing and device hot plug events.
Signed-off-by: Maciej W. Rozycki
---
New change in v9, factored out from 7/7:
- Rename
time.
Signed-off-by: Maciej W. Rozycki
---
New change in v9.
---
drivers/pci/pci.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
linux-pcie-wait-for-link-delay-status.diff
Index: linux-macro/drivers/pci/pci.c
for the device requested.
Signed-off-by: Maciej W. Rozycki
---
New change in v9.
---
drivers/pci/pci.c | 28
drivers/pci/pci.h |2 +-
drivers/pci/pcie/aspm.c |2 +-
3 files changed, 22 insertions(+), 10 deletions(-)
linux-pcie-retrain-link-use
Move code polling for the Link Training bit to clear into a function of
its own.
Signed-off-by: Maciej W. Rozycki
---
New change in v9.
---
drivers/pci/pci.c | 37 -
1 file changed, 24 insertions(+), 13 deletions(-)
linux-pcie-wait-for-link-status.diff
-by: Maciej W. Rozycki
---
New change in v9.
---
drivers/pci/pci.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
linux-pcie-retrain-link-lnkctl-lnksta.diff
Index: linux-macro/drivers/pci/pci.c
site accordingly. Document the interface.
Signed-off-by: Maciej W. Rozycki
---
There's a missing full stop added in a comment in the course of the move,
not worth mentioning in the change description IMHO and not worth its own
change either. This comment will go away in a subsequent change anyway
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
No change from v8.
Changes from v7
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with a PPC64LE configuration.
No change from v8.
Changes from v7:
- Reorder
Determine whether Data Link Layer Link Active Reporting is available
ahead of calling any fixups so that the cached value can be used there
and later on.
Signed-off-by: Maciej W. Rozycki
---
No change from v8.
Changes from v7:
- Reorder from 3/7.
Changes from v6:
- Regenerate against 6.3
Make `quirk_enable_clear_retrain_link' `pci_fixup_early' so that any later
fixups can rely on `clear_retrain_link' to have been already initialised.
Signed-off-by: Maciej W. Rozycki
---
No change from v8.
Changes from v7:
- Reorder from 2/7.
No change from v6.
No change from v5.
New change
Convert LINK_RETRAIN_TIMEOUT from jiffies to milliseconds, accordingly
rename to PCIE_LINK_RETRAIN_TIMEOUT_MS, and make available via "pci.h"
for PCI drivers to use. Use in `pcie_wait_for_link_delay'.
Signed-off-by: Maciej W. Rozycki
---
Changes from v8:
- Convert LINK_RETRAIN_TI
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
Reviewed-by: Lukas Wunner
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
No change
Hi,
This is v9 of the change to work around a PCIe link training phenomenon
where a pair of devices both capable of operating at a link speed above
2.5GT/s seems unable to negotiate the link speed and continues training
indefinitely with the Link Training bit switching on and off repeatedly
On Mon, 6 Mar 2023, Alexandre Ghiti wrote:
> diff --git a/arch/alpha/include/uapi/asm/setup.h
> b/arch/alpha/include/uapi/asm/setup.h
> deleted file mode 100644
> index 9b3b5ba39b1d..
> --- a/arch/alpha/include/uapi/asm/setup.h
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -/*
On Sun, 7 May 2023, Maciej W. Rozycki wrote:
> > We're going to land this series this cycle, come hell or high water.
>
> Thank you for coming back to me and for your promise. I'll strive to
> address your concerns next weekend.
>
> Unfortunately a PDU in my remo
On Thu, 4 May 2023, Bjorn Helgaas wrote:
> On Thu, Apr 06, 2023 at 01:21:31AM +0100, Maciej W. Rozycki wrote:
> > Attempt to handle cases such as with a downstream port of the ASMedia
> > ASM2824 PCIe switch where link training never completes and the link
> > continues swi
ort their data
link being up.
Signed-off-by: Maciej W. Rozycki
Link:
https://lore.kernel.org/r/alpine.deb.2.21.2203022037020.56...@angie.orcam.me.uk/
Link: https://source.denx.de/u-boot/u-boot/-/commit/a398a51ccc68
---
No changes from v7.
Changes from v6:
- Regenerate against 6.3-rc5.
- Shor
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
Changes from v7:
- Reorder from 5/7
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with a PPC64LE configuration.
Changes from v7:
- Reorder from 4/7.
No change
Determine whether Data Link Layer Link Active Reporting is available
ahead of calling any fixups so that the cached value can be used there
and later on.
Signed-off-by: Maciej W. Rozycki
---
Changes from v7:
- Reorder from 3/7.
Changes from v6:
- Regenerate against 6.3-rc5.
New change
Make `quirk_enable_clear_retrain_link' `pci_fixup_early' so that any later
fixups can rely on `clear_retrain_link' to have been already initialised.
Signed-off-by: Maciej W. Rozycki
---
Changes from v7:
- Reorder from 2/7.
No change from v6.
No change from v5.
New change in v5.
---
drivers
Rename LINK_RETRAIN_TIMEOUT to PCIE_LINK_RETRAIN_TIMEOUT and make it
available via "pci.h" for PCI drivers to use.
Signed-off-by: Maciej W. Rozycki
---
Changes from v7:
- Reorder from 1/7.
No change from v6.
No change from v5.
New change in v5.
---
drivers/pci/pci.h |2 +
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
Reviewed-by: Lukas Wunner
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
Changes
Hi,
This is v8 of the change to work around a PCIe link training phenomenon
where a pair of devices both capable of operating at a link speed above
2.5GT/s seems unable to negotiate the link speed and continues training
indefinitely with the Link Training bit switching on and off repeatedly
Make `quirk_enable_clear_retrain_link' `pci_fixup_early' so that any later
fixups can rely on `clear_retrain_link' to have been already initialised.
Signed-off-by: Maciej W. Rozycki
---
No change from v6.
No change from v5.
New change in v5.
---
drivers/pci/quirks.c |6 +++---
1 file
Determine whether Data Link Layer Link Active Reporting is available
ahead of calling any fixups so that the cached value can be used there
and later on.
Signed-off-by: Maciej W. Rozycki
---
Changes from v6:
- Regenerate against 6.3-rc5.
New change in v6.
---
drivers/pci/probe.c |6
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with a PPC64LE configuration.
No change from v6.
New change in v6.
---
arch
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
No change from v6.
New change in v6
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
Changes from v6:
- Regenerate
ort their data
link being up.
Signed-off-by: Maciej W. Rozycki
Link:
https://lore.kernel.org/r/alpine.deb.2.21.2203022037020.56...@angie.orcam.me.uk/
Link: https://source.denx.de/u-boot/u-boot/-/commit/a398a51ccc68
---
Changes from v6:
- Regenerate against 6.3-rc5.
- Shorten the lore.kernel.org arch
Rename LINK_RETRAIN_TIMEOUT to PCIE_LINK_RETRAIN_TIMEOUT and make it
available via "pci.h" for PCI drivers to use.
Signed-off-by: Maciej W. Rozycki
---
No change from v6.
No change from v5.
New change in v5.
---
drivers/pci/pci.h |2 ++
drivers/pci/pcie/aspm.c |4 +--
Hi,
This is v7 of the change to work around a PCIe link training phenomenon
where a pair of devices both capable of operating at a link speed above
2.5GT/s seems unable to negotiate the link speed and continues training
indefinitely with the Link Training bit switching on and off repeatedly
On Sun, 5 Feb 2023, Maciej W. Rozycki wrote:
> This is v6 of the change to work around a PCIe link training phenomenon
> where a pair of devices both capable of operating at a link speed above
> 2.5GT/s seems unable to negotiate the link speed and continues training
>
ort their data
link being up.
Signed-off-by: Maciej W. Rozycki
Link:
https://lore.kernel.org/lkml/alpine.deb.2.21.2203022037020.56...@angie.orcam.me.uk/
Link: https://source.denx.de/u-boot/u-boot/-/commit/a398a51ccc68
---
Changes from v5:
- Move from a quirk into PCI core and call at device probing,
Determine whether Data Link Layer Link Active Reporting is available
ahead of calling any fixups so that the cached value can be used there
and later on.
Signed-off-by: Maciej W. Rozycki
---
New change in v6.
---
drivers/pci/probe.c |6 +-
1 file changed, 5 insertions(+), 1 deletion
Hi,
This is v6 of the change to work around a PCIe link training phenomenon
where a pair of devices both capable of operating at a link speed above
2.5GT/s seems unable to negotiate the link speed and continues training
indefinitely with the Link Training bit switching on and off repeatedly
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
New change in v6.
---
drivers/pci
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with PPC64LE and x86-64
configurations.
New change in v6.
---
drivers/net
Use `link_active_reporting' to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.
Signed-off-by: Maciej W. Rozycki
---
NB this has been compile-tested only with a PPC64LE configuration.
New change in v6.
---
arch/powerpc/kernel
Make `quirk_enable_clear_retrain_link' `pci_fixup_early' so that any later
fixups can rely on `clear_retrain_link' to have been already initialised.
Signed-off-by: Maciej W. Rozycki
---
No change from v5.
New change in v5.
---
drivers/pci/quirks.c |6 +++---
1 file changed, 3 insertions
Rename LINK_RETRAIN_TIMEOUT to PCIE_LINK_RETRAIN_TIMEOUT and make it
available via "pci.h" for PCI drivers to use.
Signed-off-by: Maciej W. Rozycki
---
No change from v5.
New change in v5.
---
drivers/pci/pci.h |2 ++
drivers/pci/pcie/aspm.c |4 +---
2 files changed, 3
On Mon, 6 Jun 2022, Arnd Bergmann wrote:
> This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix
> 64-bit system enumeration error for Buslogic"), 8 years later.
>
> The fact that this was found at all is an indication that there are
> users, and it seems that Maciej, Matt and
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
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.
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(),
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, 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, 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 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 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
On Sat, 20 Mar 2021, Maciej W. Rozycki wrote:
> > been scheduled for removal for a while. Finally kill it off so that we
> > can start cleaning up various bits of cruft it forced on the block layer.
>
> You need to adjust Documentation/admin-guide/kernel-parameters.txt too,
On Thu, 18 Mar 2021, Christoph Hellwig wrote:
> The legay ide driver has been replace with libata startin in 2003 and has
s/legay/legacy/;s/replace/replaced/;s/startin/startin/ (though I'd say
"back in" instead in the latter case).
> been scheduled for removal for a while. Finally kill it
On Thu, 18 Mar 2021, Christoph Hellwig wrote:
> we've been trying to get rid of the legacy ide driver for a while now,
> and finally scheduled a removal for 2021, which is three month old now.
Hmm, there's still a regression in that pata_legacy unconditionally pokes
at random I/O port
of the driver could be improved I suppose though:
scsi host0: pata_platform
ata1: PATA max PIO0 mmio cmd 0x100b3e00 ctl 0x100b7ec0 irq 36
(PIO3 is actually hardwired; it's an odd interface and people reported
issues with it, but I have never had any myself be it with IDE or libata).
Acked-by
On Wed, 7 Aug 2019, Christoph Hellwig wrote:
> Mips uses the KSEG1 kernel memory segment to map dma coherent
> allocations for non-coherent devices as uncacheable, and does not have
> any kind of special support for DMA_ATTR_WRITE_COMBINE in the allocation
> path. Thus supporting
On Sat, 27 Apr 2019, Enrico Weigelt, metux IT consult wrote:
> diff --git a/drivers/tty/serial/sb1250-duart.c
> b/drivers/tty/serial/sb1250-duart.c
> index 329aced..655961c 100644
> --- a/drivers/tty/serial/sb1250-duart.c
> +++ b/drivers/tty/serial/sb1250-duart.c
> @@ -663,7 +663,6 @@ static
On Mon, 29 Apr 2019, Greg KH wrote:
> > >> drivers/tty/serial/dz.c | 8
> > >
> > > Do you have this hardware to test any of these changes with?
> >
> > Unfortunately not :(
>
> Then I can take the "basic" types of patches for the driver (like this
> one), but not any others, sorry.
On Sat, 16 Mar 2019, Enrico Weigelt, metux IT consult wrote:
> > No, it's just that those systems do not allow those devices to be
> > removed because they are probably not on a removable bus.
>
> Ok, devices (hw) might not be removable - that also the case for uarts
> builtin some SoCs, or the
On Thu, 7 Jan 2016, Brian Norris wrote:
> > Perhaps most uses of -Werror without some CONFIG_ guard
> > should be removed or replaced by some other mechanism.
>
> +1000. I'd personally like to see all one-off uses of -Werror removed.
>
> > $ git grep -E "=\s*\-Werror" | grep -v CONFIG
> > [...]
On Thu, 28 Jan 2016, Leonid Yegoshin wrote:
> In http://patchwork.linux-mips.org/patch/10505/ the very last mesg exchange
> is:
[...]
> ... and that stops forever...
Thanks for the reminder -- last June was very hectic, I travelled a lot
and I lost the discussion from my radar. Apologies for
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
> > So you need to build a different kernel for some types of MIPS systems?
> > Or do you do boot-time rewriting, like a number of other arches do?
>
> I don't know. I would like to have responses. Ralf asked Maciej about old
> systems and that came
On Wed, 27 Jan 2016, Ralf Baechle wrote:
> > So you need to build a different kernel for some types of MIPS systems?
>
> Yes. We can't really do without. Classic MIPS code is not relocatable
> without the complexity of PIC code as used by ELF DSOs - and their
> performanc penalty. Plus we
On Sun, 5 Apr 2015, Joe Perches wrote:
drivers/tty/serial/dz.c | 2 +-
drivers/tty/serial/zs.c | 2 +-
For these verified that the change works correctly, thanks for your work.
Acked-by: Maciej W. Rozycki ma...@linux-mips.org
Maciej
On Wed, 1 Sep 2010, Grant Likely wrote:
I've been looking at the phylib code, and specifically at the use of
the ERR_PTR() pattern. I'm personally not a big fan of ERR_PTR()
because the compiler cannot type check the result and it runs
completely counter to the pattern if (!ptr) than is
On Thu, 2 Sep 2010, David Miller wrote:
Arguably using a union here would make things cleaner and any reasonable
ABI will place small unions used as arguments or return values in
registers, but I'm not sure if the cost of the rewrite is worth the
Well, sparc 32-bit's ABI for one is
On Wed, 25 Feb 2009, Alessandro Zummo wrote:
I didn't know NTP was broken with RTC class drivers?
So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic
for
now? ;-)
broken here means that the kernel won't save the time to the hardware
rtc every 11 minutes as
74 matches
Mail list logo
