Re: patch "driver core: platform: Initialize dma_parms for platform devices" added to char-misc-testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 26 Mar 2020 at 15:58, <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
>
> This is a note to let you know that I've just added the patch titled
>
>     driver core: platform: Initialize dma_parms for platform devices
>
> to my char-misc git tree which can be found at
>     git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
> in the char-misc-testing branch.
>
> The patch will show up in the next release of the linux-next tree
> (usually sometime within the next 24 hours during the week.)
>
> The patch will be merged to the char-misc-next branch sometime soon,
> after it passes testing, and the merge window is open.
>
> If you have any questions about this process, please let me know.

Greg, would you mind dropping this one and the other patch for the amba bus?

I just sent out a new version (v2), addressing an issue for the
platform device when used for OF based platforms.

If you prefer to not rebase/drop patches from your branch, I can send
an incremental change on top instead, whatever you prefer.

Kind regards
Uffe

>
>
> From 7c8978c0837d40c302f5e90d24c298d9ca9fc097 Mon Sep 17 00:00:00 2001
> From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> Date: Wed, 25 Mar 2020 12:34:06 +0100
> Subject: driver core: platform: Initialize dma_parms for platform devices
>
> It's currently the platform driver's responsibility to initialize the
> pointer, dma_parms, for its corresponding struct device. The benefit with
> this approach allows us to avoid the initialization and to not waste memory
> for the struct device_dma_parameters, as this can be decided on a case by
> case basis.
>
> However, it has turned out that this approach is not very practical.  Not
> only does it lead to open coding, but also to real errors. In principle
> callers of dma_set_max_seg_size() doesn't check the error code, but just
> assumes it succeeds.
>
> For these reasons, let's do the initialization from the common platform bus
> at the device registration point. This also follows the way the PCI devices
> are being managed, see pci_device_add().
>
> Cc: <stable@xxxxxxxxxxxxxxx>
> Suggested-by: Christoph Hellwig <hch@xxxxxx>
> Tested-by: Ludovic Barre <ludovic.barre@xxxxxx>
> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> Acked-by: Arnd Bergmann <arnd@xxxxxxxx>
> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> Link: https://lore.kernel.org/r/20200325113407.26996-2-ulf.hansson@xxxxxxxxxx
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> ---
>  drivers/base/platform.c         | 1 +
>  include/linux/platform_device.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b5ce7b085795..46abbfb52655 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -512,6 +512,7 @@ int platform_device_add(struct platform_device *pdev)
>                 pdev->dev.parent = &platform_bus;
>
>         pdev->dev.bus = &platform_bus_type;
> +       pdev->dev.dma_parms = &pdev->dma_parms;
>
>         switch (pdev->id) {
>         default:
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 041bfa412aa0..81900b3cbe37 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -25,6 +25,7 @@ struct platform_device {
>         bool            id_auto;
>         struct device   dev;
>         u64             platform_dma_mask;
> +       struct device_dma_parameters dma_parms;
>         u32             num_resources;
>         struct resource *resource;
>
> --
> 2.26.0
>
>



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux