Re: [PATCH v4 1/2] dma-mapping: move dma configuration to bus infrastructure

On Mon, Apr 30, 2018 at 12:41:24PM +0200, Thierry Reding wrote: > On Sat, Apr 28, 2018 at 08:21:58AM +0530, Nipun Gupta wrote: > [...] > > diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c > > index 88a3558..a9ec99d 100644 > > --- a/drivers/gpu/host1x/bus.c > > +++

Re: [PATCH v4 1/2] dma-mapping: move dma configuration to bus infrastructure

This still fails to apply against either 4.17-rc3 or current Linus master for me. Please resend against it, and mention the tree it is against. Also please resend it in a separate email thread (all your patches were replies to the previous ones) and include a cover letter.

Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

On Tue, Apr 10, 2018 at 02:20:41PM -0500, Bjorn Helgaas wrote: > I assume you'll merge this via some non-PCI tree. Let me know if you > need anything else from me. I'll take it through the dma-mapping tree, so you should be fine.

Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

Can you resend your changes against Linux 4.17-rc2? There are a lot of conflicts as-is.

Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

> --- a/drivers/dma/qcom/hidma_mgmt.c > +++ b/drivers/dma/qcom/hidma_mgmt.c > @@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct > device_node *np) > } > of_node_get(child); > new_pdev->dev.of_node = child; > -

Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

> +static int amba_dma_configure(struct device *dev) > +{ > + return dma_common_configure(dev); > +} So it turns out we only end with two callers of dma_common_configure after this series. Based ont hat I'm tempted with the suggestion from Robin to just have amba call platform_dma_configure,

Re: [PATCH 00/16] remove eight obsolete architectures

On Thu, Mar 15, 2018 at 11:42:25AM +0100, Arnd Bergmann wrote: > Is anyone producing a chip that includes enough of the Privileged ISA spec > to have things like system calls, but not the MMU parts? Various SiFive SOCs seem to support M and U mode, but no S mode or iommu. That should be enough

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

On Tue, Sep 26, 2017 at 03:26:51PM +0800, AceLan Kao wrote: > Ath9k is an old driver for old chips, and they work fine with legacy INTx. > But some new platforms are using it, so I think we should list those > new platforms which blocks INTx in the driver. And unless they are broken and need a

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

On Tue, Sep 26, 2017 at 02:41:35PM +0800, AceLan Kao wrote: > Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI > for WLAN device. So adding a quirk to list those machines and set > use_msi automatically. > Adding Dell Inspiron 24-3460 to the quirk. Huh? Using MSI should

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

On Wed, Aug 30, 2017 at 03:46:34PM +0200, Rafael J. Wysocki wrote: > 3689d3d69072 ACPI: device property: Switch to use new generic UUID API > > in my linux-next branch. Isn't it this one? Yes, that should be it. Somehow my linux-next tree seems to be a mess through or my git log skills aren't

Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

Thanks, applied to the uuid for-next tree.

Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API

On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote: > > >> > Cc: "Rafael J. Wysocki" > > >> > Cc: Mika Westerberg > > >> > > >> Acked-by: Mika Westerberg > > > > > > OK > > > > > > Andy, do you

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote: > Yep! There are so many conflicts that would be better just to push > through your tree. > > I have just sent a v2 of this patch separately. Greg, did you pick that patch up?

Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

On Tue, Jul 25, 2017 at 01:40:06PM +0300, Andy Shevchenko wrote: > Christoph, can we apply this one at least to move things forward? Id be happy to pick this up for 4.14. Does everyone involved agree that the uuid tree is the right one?

Re: [PATCH v1 5/6] uuid: Kill uapi/uuid.h

> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c > index 29d6699d5a06..1c68709123aa 100644 > --- a/scripts/mod/file2alias.c > +++ b/scripts/mod/file2alias.c > @@ -36,7 +36,7 @@ typedef uint16_t__u16; > typedef unsigned char__u8; > typedef struct { > __u8

Re: [PATCH v1 4/6] vmbus: Switch to use new generic UUID API

On Wed, Jul 19, 2017 at 09:28:55PM +0300, Andy Shevchenko wrote: > There are new types and helpers that are supposed to be used in new code. > > As a preparation to get rid of legacy types and API functions do > the conversion here. Can you split the uapi changes into a separate patch? I'd love