(128 bytes).
This provides the ground work for the subsequent quirks for these
controllers.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/nvme/host/core.c | 25 +
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c | 9 ++---
include/linux/nvme.h | 1 +
4 files c
On Mon, 2019-07-15 at 12:28 +0300, Maxim Levitsky wrote:
>
> To be honest, the spec explicitly states that minimum submission queue entry
> size is 64
> and minimum completion entry size should be is 16 bytes for NVM command set:
>
> "Bits 3:0 define the required (i.e., minimum) Submission
On Mon, 2019-07-15 at 18:43 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2019-07-15 at 10:10 +0200, Christoph Hellwig wrote:
> > > + /*
> > > + * Apple 2018 and latter variant has a few issues
> > > + */
> > > + NVME_QUIRK_APPLE_2018
On Mon, 2019-07-15 at 10:10 +0200, Christoph Hellwig wrote:
> > + /*
> > +* Apple 2018 and latter variant has a few issues
> > +*/
> > + NVME_QUIRK_APPLE_2018 = (1 << 10),
>
> We try to have quirks for the actual issue, so this should be one quirk
> for the irq
.
Signed-off-by: Benjamin Herrenschmidt
---
I reworked Paul's patch to be less invasive in nvme_submit_cmd()
hot path, effectively only adding a shift with a value hopefully
coming from the same cache line as existing stuff.
It could probably be made even less by making sq_extra_shift be
instead
On Sun, 2019-07-14 at 15:09 +, Chocron, Jonathan wrote:
> > s/host bridge/Root Port/, if I understand correctly.
> >
>
> Ack.
>
> BTW, what is the main difference between the 2 terms, since they seem
> to be (mistakenly?) used interchangeably?
The host bridge is the parent of the root
On Thu, 2019-07-04 at 07:41 +0200, Greg KH wrote:
> On Thu, Jul 04, 2019 at 08:57:53AM +1000, Benjamin Herrenschmidt
> wrote:
> > On Wed, 2019-07-03 at 21:37 +0200, Greg KH wrote:
> > > Ok, I guess I have to take this patch, as the other one is so bad
> > > :)
> &g
On Thu, 2019-07-04 at 07:40 +0200, Greg KH wrote:
> On Thu, Jul 04, 2019 at 08:57:13AM +1000, Benjamin Herrenschmidt
> wrote:
> > On Wed, 2019-07-03 at 21:36 +0200, Greg KH wrote:
> > >
> > > > -static struct kobject *get
On Wed, 2019-07-03 at 19:49 +0200, Greg KH wrote:
> > +
> > + if (tx_sts & UART_SDMA0_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA0_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[0]));
> > + } else if (tx_sts & UART_SDMA1_INT) {
> >
On Wed, 2019-07-03 at 21:37 +0200, Greg KH wrote:
> Ok, I guess I have to take this patch, as the other one is so bad :)
>
> But, I need a very large comment here saying why we are poking around in
> a kref and why we need to do this, at the expense of anything else.
>
> So can you respin this
On Wed, 2019-07-03 at 21:36 +0200, Greg KH wrote:
>
> > -static struct kobject *get_device_parent(struct device *dev,
> > -struct device *parent)
> > +/**
> > + * __get_device_parent() - Get the parent device kobject.
> > + * @dev: Pointer to the device
On Wed, 2019-07-03 at 03:39 +, Joel Stanley wrote:
> Hello Greg,
>
> We've not had a MAINAINERS entry for drivers/fsi, so this fixes that. It names
> Jeremy and I as maintainers, so if it works for you we will send pull requests
> to you each cycle.
Ack. I no longer work for IBM and thus
Munchun, is this what your patch fixes ?
On Mon, 2019-07-01 at 16:27 -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 726e41097920a73e4c7c33385dcc0debb1281e18
> Author: Benjamin Herrenschmidt
> Date: Tue Jul 10 00:29:10 2018 +
>
> drivers: c
On Tue, 2019-06-25 at 23:06 +0800, Muchun Song wrote:
> Benjamin Herrenschmidt 于2019年6月19日周三
> 上午5:51写道：
> >
> > On Tue, 2019-06-18 at 18:13 +0200, Greg KH wrote:
> > >
> > > Again, I am totally confused and do not see a patch in an emai
On Wed, 2019-06-19 at 22:32 +, Tao Ren wrote:
> Thank you for the quick response, Brendan.
>
> Aspeed I2C bus frequency is defined by 3 parameters
> (base_clk_divisor, clk_high_width, clk_low_width), and I choose
> base_clk_divisor because it controls all the Aspeed I2C timings (such
> as
On Wed, 2019-06-19 at 22:32 +1000, Michael Ellerman wrote:
> Christoph Hellwig writes:
> > Any chance this could get picked up to fix the regression?
>
> Was hoping Ben would Ack it. He's still powermac maintainer :)
>
> I guess he OK'ed it in the other thread, will add it to my queue.
Yeah
On Tue, 2019-06-18 at 18:13 +0200, Greg KH wrote:
>
> Again, I am totally confused and do not see a patch in an email that
> I
> can apply...
>
> Someone needs to get people to agree here...
I think he was hoping you would chose which solution you prefered here
:-) His original or the one I
On Tue, 2019-06-18 at 21:40 +0800, Muchun Song wrote:
> Ping guys ? I think this is worth fixing.
I agree :-)
My opinion hasn't changed though, the right fix isn't making guesses
based on the refcount but solve the actual race which is the mutex
being dropped between looking for the object
On Mon, 2019-06-17 at 08:53 -0500, Bjorn Helgaas wrote:
> On Fri, May 31, 2019 at 11:12:16AM -0600, Logan Gunthorpe wrote:
> > One odd quirk of PLX switches is that their upstream bridge port has
> > 256K of space allocated behind its BAR0 (most other bridge
> > implementations do not report any
On Wed, 2019-06-12 at 14:41 -0500, Larry Finger wrote:
> On 6/12/19 1:55 AM, Christoph Hellwig wrote:
> >
> > Ooops, yes. But I think we could just enable ZONE_DMA on 32-bit
> > powerpc. Crude enablement hack below:
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index
On Wed, 2019-06-12 at 13:00 +0200, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 07:42:42AM -0300, Mauro Carvalho Chehab wrote:
> > That's said, from the admin PoV, it makes sense to have a single
> > daemon that collect errors from all error sources and take the
> > needed actions.
>
> Doing
On Wed, 2019-06-12 at 12:42 +0200, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 06:29:26PM +1000, Benjamin Herrenschmidt wrote:
> > I tend to disagree here. We've been down that rabbit hole in the past
> > and we (Linux in general) are trying to move away from that sort o
On Wed, 2019-06-12 at 14:25 +0200, Borislav Petkov wrote:
> > But for the main case that really needs to be in the kernel, which is
> > DRAM, the recovery can usually be contained to the MC driver anyway.
>
> Right, if that is enough to handle the error properly.
>
> The memory-failure.c example
On Wed, 2019-06-12 at 15:16 +1000, Benjamin Herrenschmidt wrote:
> pci_msi_create_irq_domain -> pci_msi_domain_update_chip_ops will
> set those two already since the driver sets MSI_FLAG_USE_DEF_CHIP_OPS
>
> Signed-off-by: Benjamin Herrenschmidt
> ---
>
> [UNTESTE
On Thu, 2019-06-13 at 10:22 +0100, Marc Zyngier wrote:
>
> It looks to me that masking at the PCI level is rather superfluous as
> long as the MSI controller HW has the capability to mask the interrupt
> on a per MSI basis. After all, most non MSI-X endpoint lack support
> for masking of
On Wed, 2019-06-12 at 08:42 -0300, Mauro Carvalho Chehab wrote:
> > Yes, we do have different error reporting facilities but I still
> > think
> > that concentrating all the error information needed in order to do
> > proper recovery action is the better approach here. And make that
> > part
> >
On Wed, 2019-06-12 at 05:48 +0200, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 08:25:52AM +1000, Benjamin Herrenschmidt wrote:
> > Yes, we would be in a world of pain already if tracepoints couldn't
> > handle concurrency :-)
>
> Right, lockless buffer and the
On Wed, 2019-06-12 at 09:25 +0300, Oded Gabbay wrote:
>
> > You can't. Your device is broken. Devices that don't support DMAing to
> > the full 64-bit deserve to be added to the trash pile.
> >
>
> Hmm... right know they are added to customers data-centers but what do I know
> ;)
Well, some
On Wed, 2019-06-12 at 15:45 +1000, Oliver O'Halloran wrote:
>
> Also, are you sure about the MSI thing? The IODA3 spec says the only
> important bits for a 64bit MSI are bits 61:60 (to hit the window) and
> the lower bits that determine what IVE to use. Everything in between
> is ignored so ORing
pci_msi_create_irq_domain -> pci_msi_domain_update_chip_ops will
set those two already since the driver sets MSI_FLAG_USE_DEF_CHIP_OPS
Signed-off-by: Benjamin Herrenschmidt
---
[UNTESTED]
Just something I noticed while browsing through those drivers in
search of ways to factor some of the c
On Tue, 2019-06-11 at 20:52 -0500, Larry Finger wrote:
> On 6/11/19 5:46 PM, Benjamin Herrenschmidt wrote:
> > On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:
> > > b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
> > > 0x3fff,
> > &
On Tue, 2019-06-11 at 20:22 +0300, Oded Gabbay wrote:
>
> > So, to summarize:
> > If I call pci_set_dma_mask with 48, then it fails on POWER9. However,
> > in runtime, I don't know if its POWER9 or not, so upon failure I will
> > call it again with 32, which makes our device pretty much unusable.
On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:
> b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
> 0x3fff,
> min_mask = 0x5000/0x5000, dma bits = 0x1f
Ugh ? A mask with holes in it ? That's very wrong... That min_mask is
bogus.
Ben.
On Tue, 2019-06-11 at 13:56 +0200, Borislav Petkov wrote:
> On Tue, Jun 11, 2019 at 05:21:39PM +1000, Benjamin Herrenschmidt wrote:
> > So looking again ... all the registration/removal of edac devices seem
> > to already be protected by mutexes, so that's not a problem.
> &
On Tue, 2019-06-11 at 09:54 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt
> wrote:
> > Ah stupid me ... it's dma_set_mask that failed, since it has no
> > idea
> > that the calling driver is limited to lowmem.
> >
On Tue, 2019-06-11 at 15:50 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2019-06-08 at 11:05 +0200, Borislav Petkov wrote:
> > On Sat, Jun 08, 2019 at 10:16:11AM +1000, Benjamin Herrenschmidt wrote:
> > > Those IP blocks don't need any SW coordination at runtime. The drivers
On Tue, 2019-06-11 at 16:58 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> > On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> > wrote:
> > > The reason I think it sort-of-mostly-worked is that to get m
On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> wrote:
> > The reason I think it sort-of-mostly-worked is that to get more
> > than
> > 1GB of RAM, those machines use CONFIG_HIGHMEM. And *m
On Mon, 2019-06-10 at 13:44 -0500, Larry Finger wrote:
> On 6/7/19 11:21 PM, Benjamin Herrenschmidt wrote:
> >
> > > Please try the attached patch. I'm not really pleased with it and I will
> > > continue to determine why the fallback to a 30-bit mask fails, but at
; > GICv2m, where hw irq is encoded in the MSI message data.
> > In addition, the Graviton flavor of GICv2m is used along GICv3 (and not
> > GICv2).
> >
> > Signed-off-by: Zeev Zilberman
> > Signed-off-by: Benjamin Herrenschmidt
>
> There seem to be some confu
On Sat, 2019-06-08 at 11:05 +0200, Borislav Petkov wrote:
> On Sat, Jun 08, 2019 at 10:16:11AM +1000, Benjamin Herrenschmidt wrote:
> > Those IP blocks don't need any SW coordination at runtime. The drivers
> > don't share data nor communicate with each other. There is absolultel
> Please try the attached patch. I'm not really pleased with it and I will
> continue to determine why the fallback to a 30-bit mask fails, but at least
> this
> one works for me.
Your patch only makes sense if the device is indeed capable of
addressing 31-bits.
So either the driver is
On Fri, 2019-06-07 at 16:11 +0100, James Morse wrote:
> I'm coming at this from somewhere else. This stuff has to be considered all
> the way
> through the system. Just because each component supports error detection,
> doesn't mean you
> aren't going to get silent corruption. Likewise if
On Thu, 2019-06-06 at 11:33 +0100, James Morse wrote:
> > Disagree. The various drivers don't depend on each other.
> > I think we should keep the drivers separated as they are distinct and
> > independent IP blocks.
>
> But they don't exist in isolation, they both depend on the
>
On Thu, 2019-06-06 at 20:56 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2019-06-06 at 12:31 +0300, Aaro Koskinen wrote:
> > Hi,
> >
> > On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt
> > wrote:
> > > On Thu, 2019-06-06 at 01:50 +0
On Thu, 2019-06-06 at 12:31 +0300, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote:
> > > Hi,
> > >
> > > When upgrading from
On Thu, 2019-06-06 at 08:05 +0100, Marc Zyngier wrote:
>
> > I disagree Marc. This is a rather bad error which indicates that the
> > device-tree is probably incorrect (or the HW was wired in a way that
> > cannot work).
>
> But surely that's something you'll spot pretty quickly.
Not really. A
On Thu, 2019-06-06 at 16:47 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2019-06-06 at 08:37 +0200, Greg KH wrote:
> > On Thu, Jun 06, 2019 at 07:55:43AM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2019-06-05 at 09:59 +0200, Greg KH wrote:
> > > >
On Thu, 2019-06-06 at 08:37 +0200, Greg KH wrote:
> On Thu, Jun 06, 2019 at 07:55:43AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2019-06-05 at 09:59 +0200, Greg KH wrote:
> > >
> > > > +struct irq_domain *al_fic_wire_get_domain(struct al_fic *fic);
&g
On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote:
> Hi,
>
> When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
> not work anymore:
>
> [ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14
> (2005-04-18 02:36:27)
> [ 42.184837] b43legacy-phy0
On Wed, 2019-06-05 at 16:12 +0100, Marc Zyngier wrote:
> > Those error messages are control path messages. if we return the same
> > error value from here and from the previous error, how can we
> > differentiate between the two error cases by looking at the log?
> >
> > Having informative
On Wed, 2019-06-05 at 17:59 +0300, Talel Shenhar wrote:
>
../..
> +- compatible: should be "amazon,al-fic"
> +- reg: physical base address and size of the registers
> +- interrupt-controller: identifies the node as an interrupt controller
> +- #interrupt-cells: must be 2.
> +-
On Wed, 2019-06-05 at 13:22 +0100, Marc Zyngier wrote:
>
> > +* This is generally fixed depending on what pieces of HW it's wired up
> > +* to.
> > +*
> > +* We configure it based on the sensitivity of the first source
> > +* being setup, and reject any subsequent attempt at
On Wed, 2019-06-05 at 09:59 +0200, Greg KH wrote:
>
> > +struct irq_domain *al_fic_wire_get_domain(struct al_fic *fic);
> > +
> > +struct al_fic *al_fic_wire_init(struct device_node *node,
> > + void __iomem *base,
> > + const char *name,
> > +
PM, Greg KH wrote:
> > On Sat, May 04, 2019 at 10:47:07PM +0800, Muchun Song wrote:
> > > Benjamin Herrenschmidt 于2019年5月2日周四
> > > 下午2:25写道：
> > >
> > > > > > The basic idea yes, the whole bool *locked is horrid
> > > > > &g
On Sun, 2019-04-28 at 22:49 +0800, Muchun Song wrote:
> Hi Greg and Rafael:
>
>
> Benjamin Herrenschmidt 于2019年4月28日周日
> 下午6:10写道：
> >
> > The basic idea yes, the whole bool *locked is horrid though.
> > Wouldn't it
> > work to have a get_d
On Thu, 2019-04-25 at 23:44 +0800, Muchun Song wrote:
> I agree with you that the looking up of the glue dir and creation of its child
> should be protected by the same lock of gdp_mutex. So, do you agree with
> the fix of the following code snippet?
The basic idea yes, the whole bool *locked is
On Tue, 2019-04-23 at 22:32 +0800, Muchun Song wrote:
> There is a race condition between removing glue directory and adding a new
> device under the glue directory. It can be reproduced in following test:
>
.../...
> In order to avoid this happening, we we should not call kobject_del() on
>
On Fri, 2019-04-12 at 14:17 +0100, Will Deacon wrote:
>
> +the same CPU thread to a particular device will arrive in program
> +order.
> +
> + 2. A writeX() by a CPU thread to the peripheral will first wait for the
> +completion of all prior writes to memory either
On Thu, 2019-04-11 at 15:34 -0700, Linus Torvalds wrote:
> On Thu, Apr 11, 2019 at 3:13 PM Benjamin Herrenschmidt
> wrote:
> >
> > Minor nit... I would have said "All readX() and writeX() accesses
> > _from
> > the same CPU_ to the same peripheral... and then
On Fri, 2019-04-05 at 14:59 +0100, Will Deacon wrote:
> + 1. All readX() and writeX() accesses to the same peripheral are ordered
> +with respect to each other. For example, this ensures that MMIO
> register
> + writes by the CPU to a particular device will arrive in program
ladimir Aerov
> Reviewed-by: David Woodhouse
Late to the party, sorry :-) That kernel.crashing.org email is on its
last legs...
Reviewed-by: Benjamin Herrenschmidt
> ---
>
> --v2:
> - Fix commit message comments (incl. using AMZN0001 instead of
> PNP0C02)
> - U
On Mon, 2019-02-11 at 14:34 -0800, Linus Torvalds wrote:
> On Mon, Feb 11, 2019 at 9:30 AM Will Deacon wrote:
> > +
> > + 1. All readX() and writeX() accesses to the same peripheral are
> > ordered
> > +with respect to each other. For example, this ensures that MMIO
> > register
> >
On Mon, 2019-02-11 at 07:26 +0100, Christophe Leroy wrote:
>
> Le 11/02/2019 à 01:21, Benjamin Herrenschmidt a écrit :
> > On Fri, 2019-02-08 at 12:52 +, Christophe Leroy wrote:
> > > /*
> > > + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include
On Fri, 2019-02-08 at 14:51 +, Mark Cave-Ayland wrote:
>
> Indeed, but there are still some questions to be asked here:
>
> 1) Why were these bits removed from the original bitmask in the first place
> without
> it being documented in the commit message?
>
> 2) Is this the right fix? I'm
On Fri, 2019-02-08 at 12:52 +, Christophe Leroy wrote:
> /*
> + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE.
> + */
> +.macro __LOAD_MSR_KERNEL r, x
> +.if \x >= 0x8000
> + lis \r, (\x)@h
> + ori \r, \r, (\x)@l
> +.else
> + li \r, (\x)
> +.endif
> +.endm
>
On Wed, 2019-01-16 at 07:35 +, Koenig, Christian wrote:
> No, but you answer the wrong question.
>
> See we don't want to have different mappings of cached and non-cached on
> the CPU, but rather want to know if a snooped DMA from the PCIe counts
> as cached access as well.
>
> As far as I
On Wed, 2019-01-16 at 08:47 +0100, Ard Biesheuvel wrote:
> > As far as I know on x86 it doesn't, so when you have an un-cached page
> > you can still access it with a snooping DMA read/write operation and
> > don't cause trouble.
> >
>
> I think it is the other way around. The question is, on an
On Wed, 2019-01-16 at 07:35 +, Koenig, Christian wrote:
> No, but you answer the wrong question.
>
> See we don't want to have different mappings of cached and non-cached on
> the CPU, but rather want to know if a snooped DMA from the PCIe counts
> as cached access as well.
>
> As far as I
On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote:
> > > As far as I know Power doesn't really supports un-cached memory at all,
> > > except for a very very old and odd configuration with AGP.
> >
> > Hopefully Michael/Ben can elaborate here, but I was under the (possibly
> > mistaken)
On Wed, 2019-01-09 at 15:53 +1100, Alexey Kardashevskiy wrote:
> "A PCI completion timeout occurred for an outstanding PCI-E transaction"
> it is.
>
> This is how I bind the device to vfio:
>
> echo vfio-pci > '/sys/bus/pci/devices/:01:00.0/driver_override'
> echo vfio-pci >
On Wed, 2019-01-09 at 17:32 +1100, Alexey Kardashevskiy wrote:
> I have just moved the "Mellanox Technologies MT27700 Family
> [ConnectX-4]" from garrison to firestone machine and there it does not
> produce an EEH, with the same kernel and skiboot (both upstream + my
> debug). Hm. I cannot really
On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
>
> > In a very cryptic way that requires manual parsing using non-public
> > docs sadly but yes. From the look of it, it's a completion timeout.
> >
> > Looks to me like we don't get a response to a config space access
> > during the
On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote:
>
> > Interesting. I've investigated this further, though I don't have as
> > many new clues as I'd like. The problem occurs reliably, at least on
> > one particular type of machine (a POWER8 "Garrison" with ConnectX-4).
> > I don't yet
On Fri, 2019-01-04 at 10:26 +0800, Jia-Ju Bai wrote:
>
> On 2019/1/4 8:47, Benjamin Herrenschmidt wrote:
> > On Wed, 2018-12-26 at 21:56 +0800, Jia-Ju Bai wrote:
> > > In drivers/fsi/fsi-sbefifo.c, the functions sbefifo_user_release(),
> > > sbefifo_user_read(
On Wed, 2018-12-26 at 21:56 +0800, Jia-Ju Bai wrote:
> In drivers/fsi/fsi-sbefifo.c, the functions sbefifo_user_release(),
> sbefifo_user_read() and sbefifo_user_write() may be concurrently executed.
So after refreshing my mind, looking at the code and talking with Al, I
really dont' see what
On Thu, 2019-01-03 at 14:27 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2019-01-02 at 09:34 +, David Howells wrote:
> > Jia-Ju Bai wrote:
> >
> > > + mutex_lock(>file_lock);
> > > sbefifo_release_command(user);
> > > free_page((unsign
On Wed, 2019-01-02 at 09:34 +, David Howells wrote:
> Jia-Ju Bai wrote:
>
> > + mutex_lock(>file_lock);
> > sbefifo_release_command(user);
> > free_page((unsigned long)user->cmd_page);
> > + mutex_unlock(>file_lock);
>
> It shouldn't be necessary to do the free_page() call
On Mon, 2018-10-15 at 12:34 +1100, Alexey Kardashevskiy wrote:
> On 10/10/2018 00:24, Christoph Hellwig wrote:
> > This code has been unused since it was merged and is in the way of
> > cleaning up the DMA code, thus remove it.
> >
> > This effectively reverts commit 5d2aa710 ("powerpc/powernv:
into account.
This looks like it will be usable if/when we switch powerpc to
dma/direct.c
Acked-by: Benjamin Herrenschmidt
---
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/dma-direct.h | 1 +
> kernel/dma/direct.c| 21 ++---
> 2 files changed, 19
On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote:
> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the
> kernel starts but it doesn't find any hard disks (partitions). That
> means this is also the bad commit for the P5020 board.
What are the disks hanging off ?
On Mon, 2018-12-10 at 20:33 +0100, Christoph Hellwig wrote:
> On Mon, Dec 10, 2018 at 05:04:46PM +, Rui Salvaterra wrote:
> > Hi, Christoph and Ben,
> >
> > It just came to my mind (and this is most likely a stupid question,
> > but still)… Is there any possibility of these changes having an
On Tue, 2018-11-27 at 08:42 +0100, Christoph Hellwig wrote:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.
So I had to cleanup some dust but it works on G5 with and without iommu
and 32-bit powermacs at least.
We're doing more tests, hopefully mpe can dig out some
On Tue, 2018-11-27 at 08:42 +0100, Christoph Hellwig wrote:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.
I completely missed your posting of V4 ! I was wondering what was
taking you so long :)
I'll give it a spin & send acks over the next 2 or 3 days.
Cheers,
Hi Greg !
Here are two very minor fixes for FSI. One from Arnd is a Kconfig fixup
and has been rusting away in my tree for a while (I had forgotten about
it). The other one just removes a duplicate #include, courtesy of
Brajeswar Ghosh.
The following changes since commit
Hi Greg !
Here are two very minor fixes for FSI. One from Arnd is a Kconfig fixup
and has been rusting away in my tree for a while (I had forgotten about
it). The other one just removes a duplicate #include, courtesy of
Brajeswar Ghosh.
The following changes since commit
On Sat, 2018-11-24 at 13:51 +0530, Brajeswar Ghosh wrote:
> On Fri, Nov 16, 2018 at 4:17 PM Brajeswar Ghosh
> wrote:
> > Remove linux/cdev.h which is included more than once
> >
> > Signed-off-by: Brajeswar Ghosh
>
> Any comment on this patch?
Ah sorry, I missed it. Yeah it's fine. I will
On Sat, 2018-11-24 at 13:51 +0530, Brajeswar Ghosh wrote:
> On Fri, Nov 16, 2018 at 4:17 PM Brajeswar Ghosh
> wrote:
> > Remove linux/cdev.h which is included more than once
> >
> > Signed-off-by: Brajeswar Ghosh
>
> Any comment on this patch?
Ah sorry, I missed it. Yeah it's fine. I will
On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
>
> > It's not a dmaengine driver. It's a serial UART driver that happens to
> > use a dedicated DMA engine.
>
> Then I see no reason for it to use dmaengine APIs. The framework allows
> people to share a controller for many clients, but if you
On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
>
> > It's not a dmaengine driver. It's a serial UART driver that happens to
> > use a dedicated DMA engine.
>
> Then I see no reason for it to use dmaengine APIs. The framework allows
> people to share a controller for many clients, but if you
On Wed, 2018-10-17 at 11:35 +0530, Vinod wrote:
> On 17-10-18, 09:41, sudheer.v wrote:
>
> Please add the change log describing the driver and its features
>
> > Signed-off-by: sudheer.v
>
>
> > ---
> > drivers/tty/serial/8250/8250_aspeed_uart_dma.c | 1594
> >
> >
On Wed, 2018-10-17 at 11:35 +0530, Vinod wrote:
> On 17-10-18, 09:41, sudheer.v wrote:
>
> Please add the change log describing the driver and its features
>
> > Signed-off-by: sudheer.v
>
>
> > ---
> > drivers/tty/serial/8250/8250_aspeed_uart_dma.c | 1594
> >
> >
On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > I'm not sure this is entirely right.
> >
> > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > fail if you
On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > I'm not sure this is entirely right.
> >
> > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > fail if you
On Sun, 2018-09-02 at 19:52 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
> wrote:
> >
> > The comment actually does talk about it, although the comment also
> > claims that the cs read would use load_unaligned_zeropad(), which it
> > no longer does (now it only
On Sun, 2018-09-02 at 19:52 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
> wrote:
> >
> > The comment actually does talk about it, although the comment also
> > claims that the cs read would use load_unaligned_zeropad(), which it
> > no longer does (now it only
On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> wrote:
> >
> > Still, I can potentially see an issue with DEBUG_PAGEALLOC
>
> An unmapped page isn't a problem. That's what the whole
> load_unaligned_
On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> wrote:
> >
> > Still, I can potentially see an issue with DEBUG_PAGEALLOC
>
> An unmapped page isn't a problem. That's what the whole
> load_unaligned_
On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> [ Adding a few new people the the cc.
>
> The issue is the worry about software-speculative accesses (ie
> things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
> speculation now) accessing past RAM into possibly contiguous
On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> [ Adding a few new people the the cc.
>
> The issue is the worry about software-speculative accesses (ie
> things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
> speculation now) accessing past RAM into possibly contiguous
101 - 200 of 5350 matches
Mail list logo
