Re: [PATCH net-next v4 2/2] of: net: fix of_get_mac_addr_nvmem() for non-platform devices

2021-04-15 Thread Benjamin Herrenschmidt
On Mon, 2021-04-12 at 19:47 +0200, Michael Walle wrote: > > /** > * of_get_phy_mode - Get phy mode for given device_node > @@ -59,15 +60,39 @@ static int of_get_mac_addr(struct device_node *np, const > char *name, u8 *addr) > static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)

Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue

2020-10-26 Thread Benjamin Herrenschmidt
On Fri, 2020-10-23 at 13:08 +, Dylan Hung wrote: > The issue was found on our test chip (ast2600 version A0) which is > just for testing and won't be mass-produced. This HW bug has been > fixed on ast2600 A1 and later versions. > > To verify the HW fix, I run overnight iperf and kvm tests on

Re: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible

2020-10-22 Thread Benjamin Herrenschmidt
On Wed, 2020-10-21 at 14:40 +0200, Arnd Bergmann wrote: > On Wed, Oct 21, 2020 at 12:39 PM Joel Stanley wrote: > > > > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c > > b/drivers/net/ethernet/faraday/ftgmac100.c > > index 331d4bdd4a67..15cdfeb135b0 100644 > > ---

Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue

2020-10-22 Thread Benjamin Herrenschmidt
Oct 21, 2020 at 12:10 AM Benjamin Herrenschmidt > > wrote: > > > On Tue, 2020-10-20 at 21:49 +0200, Arnd Bergmann wrote: > > > > On Tue, Oct 20, 2020 at 11:37 AM Dylan Hung > > > > wrote: > > > > > > +1 @first is system memory fr

Re: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible

2020-10-22 Thread Benjamin Herrenschmidt
On Wed, 2020-10-21 at 08:18 +, David Laight wrote: > From: Benjamin Herrenschmidt > > Sent: 21 October 2020 01:00 > > > > On Wed, 2020-10-21 at 08:36 +1030, Joel Stanley wrote: > > > We must ensure the tx descriptor updates are visible before

Re: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible

2020-10-20 Thread Benjamin Herrenschmidt
On Wed, 2020-10-21 at 08:36 +1030, Joel Stanley wrote: > We must ensure the tx descriptor updates are visible before updating > the tx pointer. > > This resolves the tx hangs observed on the 2600 when running iperf: To clarify the comment here. This doesn't ensure they are visible to the

Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue

2020-10-20 Thread Benjamin Herrenschmidt
On Tue, 2020-10-20 at 21:49 +0200, Arnd Bergmann wrote: > On Tue, Oct 20, 2020 at 11:37 AM Dylan Hung wrote: > > > +1 @first is system memory from dma_alloc_coherent(), right? > > > > > > You shouldn't have to do this. Is coherent DMA memory broken on your > > > platform? > > > > It is about

Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue

2020-10-20 Thread Benjamin Herrenschmidt
On Tue, 2020-10-20 at 13:15 +, David Laight wrote: > That rather depends where the data is 'stuck'. > > An old sparc cpu would flush the cpu store buffer before the read. > But a modern x86 cpu will satisfy the read from the store buffer > for cached data. > > If the write is 'posted' on a

Re: [PATCH 1/4] ftgmac100: Fix race issue on TX descriptor[0]

2020-10-20 Thread Benjamin Herrenschmidt
On Tue, 2020-10-20 at 04:13 +, Joel Stanley wrote: > On Mon, 19 Oct 2020 at 23:20, Benjamin Herrenschmidt > wrote: > > > > On Mon, 2020-10-19 at 16:57 +0800, Dylan Hung wrote: > > > These rules must be followed when accessing the TX descriptor: > > > &g

Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue

2020-10-20 Thread Benjamin Herrenschmidt
On Mon, 2020-10-19 at 19:57 -0700, Jakub Kicinski wrote: > > I suspect the problem is that the HW (and yes this would be a HW bug) > > doesn't order the CPU -> memory and the CPU -> MMIO path. > > > > What I think happens is that the store to txde0 is potentially still in > > a buffer somewhere

Re: [PATCH v1 1/2] net: ftgmac100: move phy connect out from ftgmac100_setup_mdio

2020-10-19 Thread Benjamin Herrenschmidt
On Thu, 2020-10-15 at 15:49 +0300, Ivan Mikhaylov wrote: > Split MDIO registration and PHY connect into ftgmac100_setup_mdio and > ftgmac100_mii_probe. Please keep me CCod on ftgmac100 patches. > Signed-off-by: Ivan Mikhaylov Acked-by: Benjamin Herrenschmidt > --- > drive

Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue

2020-10-19 Thread Benjamin Herrenschmidt
On Mon, 2020-10-19 at 12:00 -0700, Jakub Kicinski wrote: > On Mon, 19 Oct 2020 08:57:03 + Joel Stanley wrote: > > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c > > > b/drivers/net/ethernet/faraday/ftgmac100.c > > > index 00024dd41147..9a99a87f29f3 100644 > > > ---

Re: [PATCH 1/4] ftgmac100: Fix race issue on TX descriptor[0]

2020-10-19 Thread Benjamin Herrenschmidt
On Mon, 2020-10-19 at 16:57 +0800, Dylan Hung wrote: > These rules must be followed when accessing the TX descriptor: > > 1. A TX descriptor is "cleanable" only when its value is non-zero > and the owner bit is set to "software" Can you elaborate ? What is the point of that change ? The owner

Re: [PATCH 4/4] ftgmac100: Restart MAC HW once

2020-10-19 Thread Benjamin Herrenschmidt
ned-off-by: Dylan Hung > Signed-off-by: Joel Stanley Acked-by: Benjamin Herrenschmidt > --- > drivers/net/ethernet/faraday/ftgmac100.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c > b/drivers/net/ethernet/faraday/

Re: [PATCH 3/4] ftgmac100: Add a dummy read to ensure running sequence

2020-10-19 Thread Benjamin Herrenschmidt
On Mon, 2020-10-19 at 16:57 +0800, Dylan Hung wrote: > On the AST2600 care must be taken to ensure writes appear correctly when > modifying the interrupt reglated registers. > > Add a function to perform a read after all writes to the IER and ISR > registers. You need to elaborate here. MMIO

Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.

2020-09-07 Thread Benjamin Herrenschmidt
On Mon, 2020-09-07 at 09:55 +0200, Daniel Vetter wrote: > On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote: > > Linux Kernel Mentee: Remove Legacy Power Management. > > > > The original goal of the patch series is to upgrade the power > > management > > framework of radeonfb fbdev

Re: [PATCH] arm64: Enable PCI write-combine resources under sysfs

2020-09-01 Thread Benjamin Herrenschmidt
On Tue, 2020-09-01 at 13:37 -0500, Bjorn Helgaas wrote: > On Mon, Aug 31, 2020 at 03:18:27PM +, Clint Sbisa wrote: > > Using write-combine is crucial for performance of PCI devices where > > significant amounts of transactions go over PCI BARs. > > > > arm64 supports write-combine PCI

Re: [PATCH 1/2] fsi/sbefifo: Clean up correct FIFO when receiving reset request from SBE

2020-07-26 Thread Benjamin Herrenschmidt
On Fri, 2020-07-24 at 16:45 +0930, Joel Stanley wrote: > From: Joachim Fenkes > > When the SBE requests a reset via the down FIFO, that is also the > FIFO we should go and reset ;) Is it ? I no longer work for IBM and dont have access to any of the documentation here but I had vague memories

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-23 Thread Benjamin Herrenschmidt
On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote: > > works fine with huge pages, what is your problem there ? You rely on > > punching small-page size holes in there ? > > > > ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel > mapping in the direct mapping as it sets

Re: [PATCH] usb: gadget: net2280: fix memory leak on probe error handling paths

2020-07-22 Thread Benjamin Herrenschmidt
On Wed, 2020-07-22 at 22:56 +0300, Evgeny Novikov wrote: > Hi Alan, > > I have neither an appropriate hardware nor an experience to deal with > issues that you mentioned. Our framework does not allow to detect > them as well at the moment. At last, it seems that rather many > drivers can suffer

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-21 Thread Benjamin Herrenschmidt
On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote: > > Why ? Branch distance limits ? You can't use trampolines ? > > Nothing fundamental, it's just that we don't have a large code model in the C > compiler. As a result all the global symbols are resolved as 32-bit > PC-relative accesses.

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-21 Thread Benjamin Herrenschmidt
On Tue, 2020-07-21 at 12:05 -0700, Palmer Dabbelt wrote: > > * We waste vmalloc space on 32-bit systems, where there isn't a lot of it. > * On 64-bit systems the VA space around the kernel is precious because it's > the > only place we can place text (modules, BPF, whatever). Why ? Branch

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

2020-07-21 Thread Benjamin Herrenschmidt
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: > > > I guess I don't understand why this is necessary at all. > > > Specifically: why > > > can't we just relocate the kernel within the linear map? That would > > > let the > > > bootloader put the kernel wherever it wants, modulo the

Re: [PATCH] powerpc/64: Fix an out of date comment about MMIO ordering

2020-07-16 Thread Benjamin Herrenschmidt
On Thu, 2020-07-16 at 12:38 -0700, Palmer Dabbelt wrote: > From: Palmer Dabbelt > > This primitive has been renamed, but because it was spelled incorrectly in the > first place it must have escaped the fixup patch. As far as I can tell this > logic is still correct: smp_mb__after_spinlock()

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-15 Thread Benjamin Herrenschmidt
On Wed, 2020-07-15 at 17:12 -0500, Bjorn Helgaas wrote: > > I've 'played' with PCIe error handling - without much success. > > What might be useful is for a driver that has just read ~0u to > > be able to ask 'has there been an error signalled for this device?'. > > In many cases a driver will

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-15 Thread Benjamin Herrenschmidt
On Wed, 2020-07-15 at 08:47 +0200, Arnd Bergmann wrote: > drivers/misc/cardreader/rts5261.c: retval = > rtsx_pci_write_config_dword(pcr, PCR_SETTING_REG2, lval); > > That last one is interesting because I think this is a case in which > we > actually want to check for errors, as the driver

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Benjamin Herrenschmidt
On Tue, 2020-07-14 at 18:46 -0500, Bjorn Helgaas wrote: > Yes. I have no problem with that. There are a few cases where it's > important to check for errors, e.g., we read a status register and do > something based on a bit being set. A failure will return all bits > set, and we may do the

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Benjamin Herrenschmidt
On Tue, 2020-07-14 at 23:02 +0200, Kjetil Oftedal wrote: > > > > > For b), it might be nice to also change other aspects of the > > > interface, e.g. passing a pci_host_bridge pointer plus bus number > > > instead of a pci_bus pointer, or having the callback in the > > > pci_host_bridge

Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-14 Thread Benjamin Herrenschmidt
On Tue, 2020-07-14 at 13:45 -0500, Bjorn Helgaas wrote: > > > fail for valid arguments on a valid pci_device* ? > > I really like this idea. > > pci_write_config_*() has one return value, and only 100ish of 2500 > callers check for errors. It's sometimes possible for config > accessors to

Re: [PATCH v1 6/6] console: Fix trivia typo 'change' -> 'chance'

2020-06-18 Thread Benjamin Herrenschmidt
On Thu, 2020-06-18 at 19:47 +0300, Andy Shevchenko wrote: > I bet the word 'chance' has to be used in 'had a chance to be called', > but, alas, I'm not native speaker... Yup, typo :) > Signed-off-by: Andy Shevchenko > Acked-by: Benjamin Herrenschmidt > --- > kernel/p

Re: [PATCH v1 5/6] console: Propagate error code from console ->setup()

2020-06-18 Thread Benjamin Herrenschmidt
On Thu, 2020-06-18 at 19:47 +0300, Andy Shevchenko wrote: > Since console ->setup() hook returns meaningful error codes, > propagate it to the caller of try_enable_new_console(). > > Signed-off-by: Andy Shevchenko > Acked-by: Benjamin Herrenschmidt > ---A > ke

Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq

2020-06-08 Thread Benjamin Herrenschmidt
On Mon, 2020-06-08 at 15:48 +0200, Thomas Gleixner wrote: > "Herrenschmidt, Benjamin" writes: > > On Wed, 2020-06-03 at 16:16 +0100, Marc Zyngier wrote: > > > > My original patch should certain check activated and not disabled. > > > > With that do you still have reservations Marc? > > > > > >

Re: [GIT PULL] x86/mm changes for v5.8

2020-06-02 Thread Benjamin Herrenschmidt
On Tue, 2020-06-02 at 09:33 +0200, Ingo Molnar wrote: > Or rather, we should ask a higher level question as well, maybe we > should not do this feature at all? Well, it does solve a real issue in some circumstances and there was a reasonable discussion about this on the list that lead to it

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

2020-05-31 Thread Benjamin Herrenschmidt
On Thu, 2020-05-28 at 15:12 +0200, Greg KH wrote: > So at runtime, after all is booted and up and going, you just ripped > cores out from under someone's feet? :) > > And the code really handles writing to that value while the module is > already loaded and up and running? At a quick glance, it

Re: [PATCH v3 01/18] nitro_enclaves: Add ioctl interface definition

2020-05-31 Thread Benjamin Herrenschmidt
On Wed, 2020-05-27 at 09:49 +0100, Stefan Hajnoczi wrote: > > What about feature bits or a API version number field? If you add > features to the NE driver, how will userspace detect them? > > Even if you intend to always compile userspace against the exact kernel > headers that the program will

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

2020-05-31 Thread Benjamin Herrenschmidt
On Wed, 2020-05-27 at 00:24 +0200, Greg KH wrote: > > Would you want random users to get the ability to hot unplug CPUs from your > > system? At unlimited quantity? I don't :). > > A random user, no, but one with admin rights, why not? They can do that > already today on your system, this isn't

Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface

2020-05-31 Thread Benjamin Herrenschmidt
On Wed, 2020-05-27 at 00:21 +0200, Greg KH wrote: > > There are a couple of data structures with more than one member and multiple > > field sizes. And for the ones that are not, gathered as feedback from > > previous rounds of review that should consider adding a "flags" field in > > there for

Re: [PATCH v3 04/18] nitro_enclaves: Init PCI device driver

2020-05-31 Thread Benjamin Herrenschmidt
On Tue, 2020-05-26 at 21:35 +0300, Paraschiv, Andra-Irina wrote: > This was needed to have an identifier for the overall NE logic - PCI > dev, ioctl and misc dev. > > The ioctl and misc dev logic has pr_* logs, but I can update them to > dev_* with misc dev, then remove this prefix. Or #define

Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface

2020-05-31 Thread Benjamin Herrenschmidt
On Tue, 2020-05-26 at 20:01 +0300, Paraschiv, Andra-Irina wrote: > > On 26/05/2020 09:44, Greg KH wrote: > > On Tue, May 26, 2020 at 01:13:18AM +0300, Andra Paraschiv wrote: > > > +struct enclave_get_slot_req { > > > + /* Context ID (CID) for the enclave vsock device. */ > > > + u64 enclave_cid;

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

2020-05-31 Thread Benjamin Herrenschmidt
On Tue, 2020-05-26 at 14:44 +0200, Alexander Graf wrote: > So I really don't think an ioctl would be a great user experience. Same > for a sysfs file - although that's probably slightly better than the ioctl. What would be wrong with a sysfs file ? Another way to approach that makes sense from

Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

2020-05-31 Thread Benjamin Herrenschmidt
On Tue, 2020-05-26 at 08:51 +0200, Greg KH wrote: > > And get them to sign off on it too, showing they agree with the design > decisions here :) Isn't it generally frowned upon to publish a patch with internal sign- off's on it already ? Or do you mean for us to publicly sign off once we have

Re: [PATCH] net: bmac: Fix stack corruption panic in bmac_probe()

2020-05-19 Thread Benjamin Herrenschmidt
On Tue, 2020-05-19 at 08:59 +0800, Jeremy Kerr wrote: > Hi Stan, > > > The new kernel compiled and booted with no errors, with these > > STACKPROTECTOR options in .config (the last two revealed the bug): > > > > CONFIG_HAVE_STACKPROTECTOR=y > > CONFIG_CC_HAS_STACKPROTECTOR_NONE=y > >

Re: [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path

2020-05-13 Thread Benjamin Herrenschmidt
On Wed, 2020-05-13 at 16:37 +0200, Petr Mladek wrote: > The only common rules are: > >+ The last console on the command line should always be the > preferred one when defined. > >+ Consoles defined by the device (SPCR, device tree) are used > when there is no commandline. With

Re: [PATCH v0 linux master] i2c/busses: Avoid i2c interrupt status clear race condition.

2020-04-30 Thread Benjamin Herrenschmidt
On Wed, 2020-04-29 at 11:03 +0200, Wolfram Sang wrote: > > And is there maybe a Fixes: tag for it? > > [Ryan Chen] Yes it is a fix patch. > > I meant this (from submitting-patches.rst): It fixes the original implementation of the driver basically. It's just a classic posted-write fix. The write

Re: [PATCH v0 linux master] i2c/busses: Avoid i2c interrupt status clear race condition.

2020-04-30 Thread Benjamin Herrenschmidt
the driver need have read after write > clear at i2c ISR. > > Signed-off-by: ryan_chen Acked-by: Benjamin Herrenschmidt -- > --- > drivers/i2c/busses/i2c-aspeed.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-aspee

Re: [PATCH v5 3/5] drivers/soc/litex: add LiteX SoC Controller driver

2020-04-28 Thread Benjamin Herrenschmidt
On Mon, 2020-04-27 at 11:13 +0200, Mateusz Holenko wrote: > As Gabriel Somlo suggested to me, I could still use > readl/writel/ioread/iowrite() standard functions providing memory > barriers *and* have values in CPU native endianness by using the > following constructs: > >

Re: [PATCH v5 3/5] drivers/soc/litex: add LiteX SoC Controller driver

2020-04-28 Thread Benjamin Herrenschmidt
On Sat, 2020-04-25 at 13:42 +0200, Mateusz Holenko wrote: > From: Pawel Czarnecki > > This commit adds driver for the FPGA-based LiteX SoC > Controller from LiteX SoC builder. Sorry for jumping in late, Joel only just pointed me to this :) > + * The purpose of `litex_set_reg`/`litex_get_reg`

Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500

2019-10-19 Thread Benjamin Herrenschmidt
On Sat, 2019-10-19 at 01:31 +, Vijay Khemka wrote: > Thanks Ben, > I will try to add some trace and test whatever possible and test it. > As we > don't have tcpdump into our image and I have limited understanding of > networking stack so if you get some time to verify ipv6, it will be > really

Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500

2019-10-18 Thread Benjamin Herrenschmidt
On Fri, 2019-10-18 at 22:50 +, Vijay Khemka wrote: > I don't have much understanding of IP Stack but I went through code details > and > you are right and found that it should fallback to SW calculation for IPV6 > but it doesn't > happen because ftgmac100_hard_start_xmit checks for

Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500

2019-10-17 Thread Benjamin Herrenschmidt
On Fri, 2019-10-18 at 00:06 +, Vijay Khemka wrote: > > > This is not a matter of unsupported csum, it is broken hw csum. > > That's why we disable hw checksum. My guess is once we disable > > Hw checksum, it will use sw checksum. So I am just disabling hw > > Checksum. >

Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500

2019-10-17 Thread Benjamin Herrenschmidt
On Fri, 2019-10-18 at 10:14 +1100, Benjamin Herrenschmidt wrote: > > I don't understand what you are saying. You reported a problem with > IPV6 checksums generation. The HW doesn't support it. What's "not a > matter of unsupported csum" ? > > Your patch use

Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500

2019-10-17 Thread Benjamin Herrenschmidt
On Thu, 2019-10-17 at 22:01 +, Vijay Khemka wrote: > > ´╗┐On 10/16/19, 6:29 PM, "Benjamin Herrenschmidt" > wrote: > > On Fri, 2019-10-11 at 14:30 -0700, Vijay Khemka wrote: > > HW checksum generation is not working for AST2500, specially with >

Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500

2019-10-16 Thread Benjamin Herrenschmidt
On Fri, 2019-10-11 at 14:30 -0700, Vijay Khemka wrote: > HW checksum generation is not working for AST2500, specially with > IPV6 > over NCSI. All TCP packets with IPv6 get dropped. By disabling this > it works perfectly fine with IPV6. As it works for IPV4 so enabled > hw checksum back for IPV4.

Re: [PATCH] ftgmac100: Disable HW checksum generation on AST2500

2019-10-10 Thread Benjamin Herrenschmidt
On Thu, 2019-10-10 at 19:15 +, Vijay Khemka wrote: > Any news on this ? AST2400 has no HW checksum logic in HW, AST2500 > should work for IPV4 fine, we should only selectively disable it for > IPV6. > > Ben, I have already sent v2 for this with requested change which only disable

Re: [PATCH 1/3] dt-bindings: net: ftgmac100: Document AST2600 compatible

2019-10-09 Thread Benjamin Herrenschmidt
On Wed, 2019-10-09 at 15:25 +1030, Andrew Jeffery wrote: > > On Wed, 9 Oct 2019, at 15:19, Andrew Jeffery wrote: > > > > > > On Wed, 9 Oct 2019, at 15:08, Benjamin Herrenschmidt wrote: > > > On Tue, 2019-10-08 at 22:21 +1030, Andrew Jeffery wrote: > >

Re: [PATCH] ftgmac100: Disable HW checksum generation on AST2500

2019-10-09 Thread Benjamin Herrenschmidt
providing it with well formed traffic. Cheers, Ben. > Oskar. > > On Wed, Oct 9, 2019 at 12:38 AM Benjamin Herrenschmidt < > b...@kernel.crashing.org> wrote: > > On Wed, 2019-09-11 at 14:48 +, Joel Stanley wrote: > > > Hi Ben, > > > > > > On Tue, 10 Se

Re: [PATCH 1/3] dt-bindings: net: ftgmac100: Document AST2600 compatible

2019-10-08 Thread Benjamin Herrenschmidt
On Tue, 2019-10-08 at 22:21 +1030, Andrew Jeffery wrote: > The AST2600 contains an FTGMAC100-compatible MAC, although it no- > longer > contains an MDIO controller. How do you talk to the PHY then ? Cheers, Ben. > Signed-off-by: Andrew Jeffery > --- >

Re: [PATCH] ftgmac100: Disable HW checksum generation on AST2500

2019-10-08 Thread Benjamin Herrenschmidt
On Wed, 2019-09-11 at 14:48 +, Joel Stanley wrote: > Hi Ben, > > On Tue, 10 Sep 2019 at 22:05, Florian Fainelli > wrote: > > > > On 9/10/19 2:37 PM, Vijay Khemka wrote: > > > HW checksum generation is not working for AST2500, specially with > > > IPV6 > > > over NCSI. All TCP packets with

Re: [PATCH] powerpc/time: use feature fixup in __USE_RTC() instead of cpu feature.

2019-08-26 Thread Benjamin Herrenschmidt
On Mon, 2019-08-26 at 21:41 +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > sched_clock(), used by printk(), calls __USE_RTC() to know > > whether to use realtime clock or timebase. > > > > __USE_RTC() uses cpu_has_feature() which is initialised by > > machine_init(). Before

Re: [PATCH v4 2/4] nvme-pci: Add support for variable IO SQ element size

2019-08-22 Thread Benjamin Herrenschmidt
On Thu, 2019-08-22 at 19:52 -0700, Sagi Grimberg wrote: > > > I'll fix it. Note that I'm going to take it out of the tree soon > > > because it will have conflicts with Jens for-5.4/block, so we > > > will send it to Jens after the initial merge window, after he > > > rebases off of Linus. > > >

Re: [PATCH v4 2/4] nvme-pci: Add support for variable IO SQ element size

2019-08-22 Thread Benjamin Herrenschmidt
On Thu, 2019-08-22 at 11:02 -0700, Sagi Grimberg wrote: > > > > I'll fix it. Note that I'm going to take it out of the tree soon > because it will have conflicts with Jens for-5.4/block, so we > will send it to Jens after the initial merge window, after he > rebases off of Linus. Conflicts too

Re: [PATCH v4 2/4] nvme-pci: Add support for variable IO SQ element size

2019-08-21 Thread Benjamin Herrenschmidt
On Thu, 2019-08-22 at 02:28 +0200, Christoph Hellwig wrote: > On Wed, Aug 07, 2019 at 05:51:20PM +1000, Benjamin Herrenschmidt > wrote: > > +#define NVME_NVM_ADMSQES 6 > > #define NVME_NVM_IOSQES6 > > #define NVME_NVM_IOCQES4 > > The NVM

Re: [PATCH] powerpc/vdso32: inline __get_datapage()

2019-08-20 Thread Benjamin Herrenschmidt
On Fri, 2019-08-16 at 14:48 +, Christophe Leroy wrote: > __get_datapage() is only a few instructions to retrieve the > address of the page where the kernel stores data to the VDSO. > > By inlining this function into its users, a bl/blr pair and > a mflr/mtlr pair is avoided, plus a few reg

Re: [PATCH] fsi: scom: Don't abort operations for minor errors

2019-08-20 Thread Benjamin Herrenschmidt
scom engine to perform operations, so the driver should continue > under these conditions. > Also, don't do a PIB reset for these conditions, since it won't help. > > Signed-off-by: Eddie James Acked-by: Benjamin Herrenschmidt > --- > drivers/fsi/fsi-scom.c | 8 +--- >

Re: [PATCH v2 05/12] powerpc/mm: rework io-workaround invocation.

2019-08-20 Thread Benjamin Herrenschmidt
On Wed, 2019-08-21 at 00:28 +0200, Christoph Hellwig wrote: > On Tue, Aug 20, 2019 at 02:07:13PM +, Christophe Leroy wrote: > > ppc_md.ioremap() is only used for I/O workaround on CELL platform, > > so indirect function call can be avoided. > > > > This patch reworks the io-workaround and

[PATCH v4 1/4] nvme-pci: Pass the queue to SQ_SIZE/CQ_SIZE macros

2019-08-07 Thread Benjamin Herrenschmidt
This will make it easier to handle variable queue entry sizes later. No functional change. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christoph Hellwig Reviewed-by: Minwoo Im --- drivers/nvme/host/pci.c | 30 +++--- 1 file changed, 15 insertions(+), 15

[PATCH v4 0/4] nvme-pci: Support for Apple 201+ (T2 chip)

2019-08-07 Thread Benjamin Herrenschmidt
This series combines the original series and an updated version of the shared tags patch, and is rebased on nvme-5.4. This adds support for the controller found in recent Apple machines which is basically a SW emulated NVME controller in the T2 chip. The original reverse engineering work was

[PATCH v4 4/4] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-08-07 Thread Benjamin Herrenschmidt
seem to not like when tags go beyond the IO queue depth, ie 128 tags. This adds a quirk that marks tags 0..31 of the IO queue reserved Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Ming Lei Acked-by: Keith Busch --- drivers/nvme/host/nvme.h | 5 + drivers/nvme/host/pci.c | 31

[PATCH v4 2/4] nvme-pci: Add support for variable IO SQ element size

2019-08-07 Thread Benjamin Herrenschmidt
The size of a submission queue element should always be 6 (64 bytes) by spec. However some controllers such as Apple's are not properly implementing the standard and require a different size. This provides the ground work for the subsequent quirks for these controllers. Signed-off-by: Benjamin

[PATCH v4 3/4] nvme-pci: Add support for Apple 2018+ models

2019-08-07 Thread Benjamin Herrenschmidt
. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Minwoo Im --- drivers/nvme/host/nvme.h | 10 ++ drivers/nvme/host/pci.c | 21 - 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h index 8dc010ca30e5

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-08-05 Thread Benjamin Herrenschmidt
On Mon, 2019-08-05 at 13:07 -0700, Sagi Grimberg wrote: > > > > > > Ping ? I had another look today and I don't feel like mucking around > > > > > > with all the AQ size logic, AEN magic tag etc... just for that sake > > > > > > of > > > > > > that Apple gunk. I'm happy to have it give up IO

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-08-05 Thread Benjamin Herrenschmidt
On Mon, 2019-08-05 at 11:27 -0700, Sagi Grimberg wrote: > > > Ping ? I had another look today and I don't feel like mucking > > > around > > > with all the AQ size logic, AEN magic tag etc... just for that > > > sake of > > > that Apple gunk. I'm happy to have it give up IO tags, it doesn't > > >

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-08-05 Thread Benjamin Herrenschmidt
On Mon, 2019-08-05 at 07:49 -0600, Keith Busch wrote: > > Ping ? I had another look today and I don't feel like mucking around > > with all the AQ size logic, AEN magic tag etc... just for that sake of > > that Apple gunk. I'm happy to have it give up IO tags, it doesn't seem > > to make much of a

Re: WARNING in kernfs_new_node

2019-08-05 Thread Benjamin Herrenschmidt
d9060c60 > > The bug was bisected to: > > commit 726e41097920a73e4c7c33385dcc0debb1281e18 > Author: Benjamin Herrenschmidt > Date: Tue Jul 10 00:29:10 2018 + > > drivers: core: Remove glue dirs from sysfs earlier > > bisection log: > https://syzkaller.appspot.com/x/bisect

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-08-05 Thread Benjamin Herrenschmidt
On Tue, 2019-07-30 at 13:28 -0700, Benjamin Herrenschmidt wrote: > > One problem is that we've an nvme parameter, io_queue_depth, that a user > > could set to something less than 32, and then you won't be able to do > > any IO. I'd recommend enforce the admin queue to QD1

Re: [PATCH] drivers/macintosh/smu.c: Mark expected switch fall-through

2019-07-30 Thread Benjamin Herrenschmidt
On Tue, 2019-07-30 at 10:07 -0700, Kees Cook wrote: > > > Why do we think it's an expected fall through? I can't really > > convince > > myself from the surrounding code that it's definitely intentional. > > Yeah, good question. Just now when I went looking for who > used

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-30 Thread Benjamin Herrenschmidt
On Tue, 2019-07-30 at 09:30 -0600, Keith Busch wrote: > On Fri, Jul 19, 2019 at 03:31:02PM +1000, Benjamin Herrenschmidt wrote: > > From 8dcba2ef5b1466b023b88b4eca463b30de78d9eb Mon Sep 17 00:00:00 2001 > > From: Benjamin Herrenschmidt > > Date: Fri, 19 Jul 2019 15:03

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-30 Thread Benjamin Herrenschmidt
On Tue, 2019-07-30 at 09:30 -0600, Keith Busch wrote: > On Fri, Jul 19, 2019 at 03:31:02PM +1000, Benjamin Herrenschmidt wrote: > > From 8dcba2ef5b1466b023b88b4eca463b30de78d9eb Mon Sep 17 00:00:00 2001 > > From: Benjamin Herrenschmidt > > Date: Fri, 19 Jul 2019 15:03

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-22 Thread Benjamin Herrenschmidt
On Fri, 2019-07-19 at 23:51 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2019-07-19 at 14:28 +0200, Christoph Hellwig wrote: > > Yikes, that things looks worse and worse. I think at this point > > we'll > > have to defer the support to 5.4 unfortunately as it is gett

Re: [PATCH v2 6/8] PCI: al: Add support for DW based driver type

2019-07-21 Thread Benjamin Herrenschmidt
On Sun, 2019-07-21 at 15:08 +, Chocron, Jonathan wrote: > > Please sort the variables following the reverse tree order. > > > > Done. > > I'd think that it would make sense to group variables which have a > common characteristic (e.g. resources read from the DT), even if it > mildly breaks

Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-19 Thread Benjamin Herrenschmidt
On Fri, 2019-07-19 at 14:28 +0200, Christoph Hellwig wrote: > Yikes, that things looks worse and worse. I think at this point > we'll > have to defer the support to 5.4 unfortunately as it is getting more > and more involved.. Well, at least v3 of that patch, thanks to Damien's idea, isn't

[PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-18 Thread Benjamin Herrenschmidt
>From 8dcba2ef5b1466b023b88b4eca463b30de78d9eb Mon Sep 17 00:00:00 2001 From: Benjamin Herrenschmidt Date: Fri, 19 Jul 2019 15:03:06 +1000 Subject: Another issue with the Apple T2 based 2018 controllers seem to be that they blow up (and shut the machine down) if there's a tag collision betw

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-18 Thread Benjamin Herrenschmidt
On Fri, 2019-07-19 at 05:01 +, Damien Le Moal wrote: > > I suppose that would work and be simpler. I honestly don't know much > > about the block layer and tag allocation so I stayed away from it :-) > > > > I'll dig, but a hint would be welcome :) > > Uuuh.. Never played with the tag

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-18 Thread Benjamin Herrenschmidt
On Fri, 2019-07-19 at 14:49 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2019-07-19 at 04:43 +, Damien Le Moal wrote: > > On 2019/07/19 13:37, Benjamin Herrenschmidt wrote: > > > Another issue with the Apple T2 based 2018 controllers seem to be > > > that they bl

Re: [PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-18 Thread Benjamin Herrenschmidt
On Fri, 2019-07-19 at 04:43 +, Damien Le Moal wrote: > On 2019/07/19 13:37, Benjamin Herrenschmidt wrote: > > Another issue with the Apple T2 based 2018 controllers seem to be > > that they blow up (and shut the machine down) if there's a tag > > collision between the I

[PATCH v2] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-18 Thread Benjamin Herrenschmidt
but better safe than sorry) and reduces the size of the IO queue Signed-off-by: Benjamin Herrenschmidt --- Note: One thing I noticed is how we have nvme_completion as volatile. I don't think we really need that, it's forcing the compiler to constantly reload things which makes no sense once we have

Re: [PATCH] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-18 Thread Benjamin Herrenschmidt
On Thu, 2019-07-18 at 17:11 +1000, Benjamin Herrenschmidt wrote: > Another issue with the Apple T2 based 2018 controllers seem to be > that they blow up (and shut the machine down) if there's a tag > collision between the IO queue and the Admin queue. > > This adds a quirk t

[PATCH] nvme-pci: Support shared tags across queues for Apple 2018 controllers

2019-07-18 Thread Benjamin Herrenschmidt
the number of IO queues to 1 since the code wouldn't otherwise make sense (the device supports only one queue anyway but better safe than sorry). The bug is typically triggered by tag collisions between SMART commands from smartd and IO commands, often at boot time. Signed-off-by: Benjamin Herrenschmidt

Re: [PATCH v2 2/3] nvme-pci: Add support for variable IO SQ element size

2019-07-17 Thread Benjamin Herrenschmidt
On Wed, 2019-07-17 at 20:51 +0900, Minwoo Im wrote: > - struct nvme_command *sq_cmds; > > + void *sq_cmds; > > It would be great if it can remain the existing data type for the > SQEs... But I'm fine with this also. > > It looks good to me. I changed it on purpose so we aren't tempted to

Re: [PATCH v2 3/3] nvme-pci: Add support for Apple 2018+ models

2019-07-16 Thread Benjamin Herrenschmidt
On Wed, 2019-07-17 at 06:50 +0200, Christoph Hellwig wrote: > > # Conflicts: > > # drivers/nvme/host/core.c > > I thought you were going to fix this up :) Haha yeah I was ... > But I can do that and this version of the series looks fine to me. Thanks ! Cheers, Ben.

[PATCH v2 3/3] nvme-pci: Add support for Apple 2018+ models

2019-07-16 Thread Benjamin Herrenschmidt
. Signed-off-by: Benjamin Herrenschmidt # Conflicts: # drivers/nvme/host/core.c --- drivers/nvme/host/nvme.h | 10 ++ drivers/nvme/host/pci.c | 21 - 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h

[PATCH v2 1/3] nvme-pci: Pass the queue to SQ_SIZE/CQ_SIZE macros

2019-07-16 Thread Benjamin Herrenschmidt
This will make it easier to handle variable queue entry sizes later. No functional change. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christoph Hellwig --- drivers/nvme/host/pci.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git

[PATCH v2 2/3] nvme-pci: Add support for variable IO SQ element size

2019-07-16 Thread Benjamin Herrenschmidt
The size of a submission queue element should always be 6 (64 bytes) by spec. However some controllers such as Apple's are not properly implementing the standard and require a different size. This provides the ground work for the subsequent quirks for these controllers. Signed-off-by: Benjamin

Re: [PATCH 2/3] nvme: Retrieve the required IO queue entry size from the controller

2019-07-16 Thread Benjamin Herrenschmidt
On Tue, 2019-07-16 at 14:05 +0200, Christoph Hellwig wrote: > On Tue, Jul 16, 2019 at 08:58:28PM +1000, Benjamin Herrenschmidt wrote: > > The main risk is if existing controllers return crap in SQES and we try > > to then use that crap. The rest should essentially be NOPs. > >

Re: [PATCH 2/3] nvme: Retrieve the required IO queue entry size from the controller

2019-07-16 Thread Benjamin Herrenschmidt
On Tue, 2019-07-16 at 11:33 +0200, Christoph Hellwig wrote: > > >So back to the version > > > you circulated to me in private mail that just sets q->sqes and has a > > > comment that this is magic for The Apple controller. If/when we get > > > standardized large SQE support we'll need to

Re: [PATCH 3/3] nvme: Add support for Apple 2018+ models

2019-07-16 Thread Benjamin Herrenschmidt
On Tue, 2019-07-16 at 08:06 +0200, Christoph Hellwig wrote: > > > /* > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > > index 54b35ea4af88..ab2358137419 100644 > > --- a/drivers/nvme/host/pci.c > > +++ b/drivers/nvme/host/pci.c > > @@ -2080,6 +2080,9 @@ static int

Re: [PATCH 2/3] nvme: Retrieve the required IO queue entry size from the controller

2019-07-16 Thread Benjamin Herrenschmidt
On Tue, 2019-07-16 at 08:04 +0200, Christoph Hellwig wrote: > > > > + /* > > +* If our IO queue size isn't the default, update the setting > > +* in CC:IOSQES. > > +*/ > > + if (ctrl->iosqes != NVME_NVM_IOSQES) { > > +

Re: [PATCH 1/3] nvme: Pass the queue to SQ_SIZE/CQ_SIZE macros

2019-07-15 Thread Benjamin Herrenschmidt
On Tue, 2019-07-16 at 10:46 +1000, Benjamin Herrenschmidt wrote: > # Conflicts: > # drivers/nvme/host/pci.c > --- Oops :-) You can strip that or should I resend ? I'll wait for comments/reviews regardless. Cheers, Ben.

[PATCH 3/3] nvme: Add support for Apple 2018+ models

2019-07-15 Thread Benjamin Herrenschmidt
. Signed-off-by: Benjamin Herrenschmidt --- drivers/nvme/host/core.c | 5 - drivers/nvme/host/nvme.h | 10 ++ drivers/nvme/host/pci.c | 6 ++ 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 716ebe87a2b8

[PATCH 1/3] nvme: Pass the queue to SQ_SIZE/CQ_SIZE macros

2019-07-15 Thread Benjamin Herrenschmidt
This will make it easier to handle variable queue entry sizes later. No functional change. Signed-off-by: Benjamin Herrenschmidt # Conflicts: # drivers/nvme/host/pci.c --- drivers/nvme/host/pci.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff

  1   2   3   4   5   6   7   8   9   10   >