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)
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
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
> > ---
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
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
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
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
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
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
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
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
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
> > > ---
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
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/
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
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
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
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
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
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
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.
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
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
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()
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
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
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
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
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
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
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
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?
> > >
> > >
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
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
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
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
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
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
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;
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
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
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
> >
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
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
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
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:
>
>
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`
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
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
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.
>
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
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
>
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.
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
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:
> >
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
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
> ---
>
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
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
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.
> >
>
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
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
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
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 +---
>
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
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
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
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
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
.
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
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
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
> > >
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
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
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
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
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
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
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
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
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
>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
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
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
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
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
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
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
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
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.
.
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
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
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
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.
> >
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
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
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) {
> > +
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.
.
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
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 - 100 of 5350 matches
Mail list logo
