Re: [PATCH v2] staging: mt7621-dma: Add braces around else branches
Hi Kiberly,
Thanks for adding all the emails in CC.
I would encourage you for your next patch to distinguish between CC and TO.
You should send your patch TO important maintainers in the get_maintainers.pl
list (as default, to all of them). If there is someone you really want to look
into the patch, then add him/her in TO as well.
Put the rest (people and mailing lists) in CC. Why? Some people filter their
mails so that they can concentrate on the mails they got send directly and look
on mails they are in CC with lower priority (maybe not at all, because there are
too much?). So it is important to have the maintainers in the TO list and not
in CC.
Keep up the good work :)
Matthias
On 24/10/2018 06:56, Kimberly Brown wrote:
> Add braces around else branches in conditional statements that include
> branches with multiple statements. This style complies with the Linux
> kernel coding style and improves consistency and readability. Issues found by
> checkpatch.
>
> Signed-off-by: Kimberly Brown
> Reviewed-by: Matthias Brugger
> ---
> Changes in v2:
> - Added people and mailing lists from get_maintainer.pl to the CC list
> - Added Reviewed-by line
>
> drivers/staging/mt7621-dma/mtk-hsdma.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c
> b/drivers/staging/mt7621-dma/mtk-hsdma.c
> index df6ebf41bdea..35556f024aa1 100644
> --- a/drivers/staging/mt7621-dma/mtk-hsdma.c
> +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c
> @@ -418,8 +418,9 @@ static void mtk_hsdma_chan_done(struct mtk_hsdam_engine
> *hsdma,
> vchan_cookie_complete(&desc->vdesc);
> chan_issued = gdma_next_desc(chan);
> }
> - } else
> + } else {
> dev_dbg(hsdma->ddev.dev, "no desc to complete\n");
> + }
>
> if (chan_issued)
> set_bit(chan->id, &hsdma->chan_issued);
> @@ -456,8 +457,9 @@ static void mtk_hsdma_issue_pending(struct dma_chan *c)
> if (gdma_next_desc(chan)) {
> set_bit(chan->id, &hsdma->chan_issued);
> tasklet_schedule(&hsdma->task);
> - } else
> + } else {
> dev_dbg(hsdma->ddev.dev, "no desc to issue\n");
> + }
> }
> spin_unlock_bh(&chan->vchan.lock);
> }
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 13/03/2019 13:24, Armando Miraglia wrote:
> Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that the
> file contained style issues. This change attempts to address such style
> problems.
>
> Signed-off-by: Armando Miraglia
Reviewed-by: Matthias Brugger
Apart from fixing styling issues it would be usefull to see if we can add
support for mt7621 to drivers/spi/spi-mt65xx.c
Not sure if that is something you want to work on :)
Regards,
Matthias
> ---
> NOTE: resend this patch to include all mainteners listed by get_mantainers.pl.
> drivers/staging/mt7621-spi/spi-mt7621.c | 27 +
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
> b/drivers/staging/mt7621-spi/spi-mt7621.c
> index b509f9fe3346..03d53845f8c5 100644
> --- a/drivers/staging/mt7621-spi/spi-mt7621.c
> +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
> @@ -52,14 +52,14 @@
> #define MT7621_LSB_FIRST BIT(3)
>
> struct mt7621_spi {
> - struct spi_master *master;
> - void __iomem*base;
> - unsigned intsys_freq;
> - unsigned intspeed;
> - struct clk *clk;
> - int pending_write;
> -
> - struct mt7621_spi_ops *ops;
> + struct spi_master *master;
> + void __iomem *base;
> + unsigned int sys_freq;
> + unsigned int speed;
> + struct clk *clk;
> + int pending_write;
> +
> + struct mt7621_spi_ops *ops;
> };
>
> static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device *spi)
> @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
> struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
>
> if ((spi->max_speed_hz == 0) ||
> - (spi->max_speed_hz > (rs->sys_freq / 2)))
> + (spi->max_speed_hz > (rs->sys_freq / 2)))
> spi->max_speed_hz = (rs->sys_freq / 2);
>
> if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
> @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
> }
>
> static const struct of_device_id mt7621_spi_match[] = {
> - { .compatible = "ralink,mt7621-spi" },
> + {.compatible = "ralink,mt7621-spi"},
> {},
> };
> +
> MODULE_DEVICE_TABLE(of, mt7621_spi_match);
>
> static int mt7621_spi_probe(struct platform_device *pdev)
> @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
>
> static struct platform_driver mt7621_spi_driver = {
> .driver = {
> - .name = DRIVER_NAME,
> - .of_match_table = mt7621_spi_match,
> - },
> +.name = DRIVER_NAME,
> +.of_match_table = mt7621_spi_match,
> +},
> .probe = mt7621_spi_probe,
> .remove = mt7621_spi_remove,
> };
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 13/03/2019 17:34, Chuanhong Guo wrote: > Hi! > On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger > wrote: >> >> >> >> On 13/03/2019 13:24, Armando Miraglia wrote: >> [...] >> Apart from fixing styling issues it would be usefull to see if we can add >> support for mt7621 to drivers/spi/spi-mt65xx.c > It's impossible. They are completely different IPs. Thanks for the info. Do you know the status of the rest of the drivers in staging? Best regards, Matthias ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 13/03/2019 13:34, Dan Carpenter wrote:
> On Wed, Mar 13, 2019 at 01:24:04PM +0100, Armando Miraglia wrote:
>> Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that
>> the
>> file contained style issues. This change attempts to address such style
>> problems.
>>
>
> Don't run lindent. I think checkpatch.pl has a --fix option that might
> be better, but once the code is merged then our standard become much
> higher for follow up patches.
>
>> Signed-off-by: Armando Miraglia
>> ---
>> NOTE: resend this patch to include all mainteners listed by
>> get_mantainers.pl.
>> drivers/staging/mt7621-spi/spi-mt7621.c | 27 +
>> 1 file changed, 14 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
>> b/drivers/staging/mt7621-spi/spi-mt7621.c
>> index b509f9fe3346..03d53845f8c5 100644
>> --- a/drivers/staging/mt7621-spi/spi-mt7621.c
>> +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
>> @@ -52,14 +52,14 @@
>> #define MT7621_LSB_FIRSTBIT(3)
>>
>> struct mt7621_spi {
>> -struct spi_master *master;
>> -void __iomem*base;
>> -unsigned intsys_freq;
>> -unsigned intspeed;
>> -struct clk *clk;
>> -int pending_write;
>> -
>> -struct mt7621_spi_ops *ops;
>> +struct spi_master *master;
>> +void __iomem *base;
>> +unsigned int sys_freq;
>> +unsigned int speed;
>> +struct clk *clk;
>> +int pending_write;
>> +
>> +struct mt7621_spi_ops *ops;
>
> The original is fine. I don't encourage people to do fancy indenting
> with their local variable declarations inside functions but for a struct
> the declarations aren't going to change a lot so people can get fancy
> if they want.
>
> The problem with a local is if you need to add a new variable then you
> have to re-indent a bunch of unrelated lines or have one out of
> alignment line. Most people know this intuitively so they don't get
> fancy.
>
>> };
>>
>> static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device
>> *spi)
>> @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
>> struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
>>
>> if ((spi->max_speed_hz == 0) ||
>> -(spi->max_speed_hz > (rs->sys_freq / 2)))
>> +(spi->max_speed_hz > (rs->sys_freq / 2)))
>
> Yeah. Lindent is correct here.
>
>> spi->max_speed_hz = (rs->sys_freq / 2);
>>
>> if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
>> @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
>> }
>>
>> static const struct of_device_id mt7621_spi_match[] = {
>> -{ .compatible = "ralink,mt7621-spi" },
>> +{.compatible = "ralink,mt7621-spi"},
>
> The original was better.
>
>> {},
>> };
>> +
>> MODULE_DEVICE_TABLE(of, mt7621_spi_match);
>
> No need for a blank. These are closely related.
>
>>
>> static int mt7621_spi_probe(struct platform_device *pdev)
>> @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
>>
>> static struct platform_driver mt7621_spi_driver = {
>> .driver = {
>> -.name = DRIVER_NAME,
>> -.of_match_table = mt7621_spi_match,
>> -},
>> + .name = DRIVER_NAME,
>> + .of_match_table = mt7621_spi_match,
>> + },
>
> The new indenting is very wrong.
>
Fair enough, I was too fast providing my Reviewed-by tag :-/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 14/03/2019 12:37, Armando Miraglia wrote: > Absolutely! Please don't top post :) > > Cheers, > A. > > On Thu, Mar 14, 2019 at 12:36 PM Stefan Roese wrote: [...] >> >> Would it be possible for you to wait a bit with this minor cleanup? >> As I'm preparing a patch to move this driver out of staging right >> now. You can definitely follow-up with your cleanup, once this move >> is done. Otherwise the move might be delayed even more. >> Hm but shouldn't style issues be a criteria for not accepting a move out of staging? I think so. You could add Armandos patch in your series or rebase your series against Greg's tree, once he took the clean-up. Normally Greg is incredibly fast :) Regards, Matthias ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 14/03/2019 14:24, Stefan Roese wrote: > On 14.03.19 14:14, Matthias Brugger wrote: >> >> >> On 14/03/2019 12:37, Armando Miraglia wrote: >>> Absolutely! >> >> Please don't top post :) >> >>> >>> Cheers, >>> A. >>> >>> On Thu, Mar 14, 2019 at 12:36 PM Stefan Roese wrote: >> [...] >>>> >>>> Would it be possible for you to wait a bit with this minor cleanup? >>>> As I'm preparing a patch to move this driver out of staging right >>>> now. You can definitely follow-up with your cleanup, once this move >>>> is done. Otherwise the move might be delayed even more. >>>> >> >> Hm but shouldn't style issues be a criteria for not accepting a move out of >> staging? > > I would agree, if those style issues where non trivial. In the end we > are talking about one non-optimal identation now.> Fair enough, anyway I'm not the person to decide on that :) Regards, Matthias >> I think so. You could add Armandos patch in your series or rebase your >> series against Greg's tree, once he took the clean-up. Normally Greg is >> incredibly fast :) > > I should have included the history here to make this more clean. I've > started pulling this driver out of staging a few weeks ago: > > https://patchwork.kernel.org/patch/10790537/ > ... > > Here you find Greg's comment, that the style patches should be merged > first before the move out of staging. This is what I worked on after > this first patch series: > > https://patchwork.kernel.org/patch/10792455/ > ... > > Now these 9 style issue patches from me have been merged and I would > like to proceed with the driver move. > > Thanks, > Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Are people from linux-mediatek also interested in Mediatek MIPS SoCs? [Was: [PATCH] staging: mt7621-dts: add dt node for 2nd/3rd uart on mt7621]
On 06/02/2020 08:53, Chuanhong Guo wrote: > On Tue, Feb 4, 2020 at 6:37 PM Dan Carpenter wrote: >> >> On Tue, Feb 04, 2020 at 05:59:21PM +0800, Chuanhong Guo wrote: >>> Hi! >>> >>> On Tue, Feb 4, 2020 at 5:47 PM Dan Carpenter >>> wrote: >>>> >>>> Please use ./scripts/get_maintainer.pl to pick the CC list and resend. >>>> >>>> The MAINTAINERS file says Matthias Brugger is supposed to be CC'd and >>>> a couple other email lists. >>> >>> According to get_maintainer.pl, Matthias Brugger is the maintainer of >>> Mediatek ARM SoC: >>> >>> Matthias Brugger (maintainer:ARM/Mediatek SoC >>> support) >>> linux-arm-ker...@lists.infradead.org (moderated list:ARM/Mediatek SoC >>> support) >>> linux-media...@lists.infradead.org (moderated list:ARM/Mediatek SoC support) >>> >>> I specifically removed the above 3 addresses because they are all for >>> Mediatek ARM chips >>> while mt7621 is a mips chip and belongs to ralink target under >>> /arch/mips/mach-ralink. >>> Code contribution for mt7621 goes through linux-mips instead of >>> linux-arm or linux-mediatek, >> >> I would have thought that we would still CC linux-mediatek? >> >>> >>> I thinks this is an incorrect setup of get_maintainer.pl and should be >>> corrected. >> >> We could ask him... >> >> It's always easiest to fix MAINTAINERS instead of remembering all the >> exceptions and rules. > > Hi Matthias and other folks on linux-mediatek: > > I noticed that get_maintainers.pl reports "ARM/Mediatek SoC support" > e-mail addreses for MTK MIPS SoCs (mt7620/mt7621/mt76x8) because of > "mt[678]" name match in MAINTAINERS file. > This is confusing because these MIPS SoCs clearly don't fall into > "ARM" category. Is this an incorrect match or is it intentional? If > it's intentional I think we should remove the confusing ARM prefix, > and if it's incorrect we may need to figure out how to exclude > mt7620/mt7621/mt76x8 from "ARM/Mediatek SoC support". > That's a good question. I think it's an accident as I don't have good knowledge of the MIPS architecture. Also I try to track the upstream support for MIPS as well: https://mtk.bcnfs.org/doku.php?id=linux_mainline_effort Regards, Matthias ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/3][v4] staging: fsl-mc: move bus driver out of staging
On 19/05/17 15:13, laurentiu.tu...@nxp.com wrote:
From: Stuart Yoder
Move the source files out of staging into their final locations:
-include files in drivers/staging/fsl-mc/include go to include/linux/fsl
-irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
This driver has as compatible "arm,gic-v3-its". I wonder if this is
correct and if it should be moved like this out of staging.
Regards,
Matthias
-source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
-README.txt, providing and overview of DPAA goes to
Documentation/dpaa2/overview.txt
Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
Update dpaa2_eth and dpio staging drivers.
Signed-off-by: Stuart Yoder
Signed-off-by: Laurentiu Tudor
[Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
---
Notes:
-v4
-rebased
-update existing dpaa2 drivers to work with the bus out of staging
-v3
-no changes
-v2
-updated MAINTAINERS with new location
.../README.txt => Documentation/dpaa2/overview.txt| 0
MAINTAINERS | 2 +-
drivers/bus/Kconfig | 2 ++
drivers/bus/Makefile | 3 +++
drivers/bus/fsl-mc/Kconfig| 17 +
drivers/bus/fsl-mc/Makefile | 19 +++
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h | 0
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c | 6 +++---
.../{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h| 0
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c| 4 ++--
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h| 0
.../{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h| 0
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c| 6 +++---
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h | 0
.../{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c | 4 ++--
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c | 6 +++---
.../fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c | 6 +++---
.../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c | 6 +++---
.../{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-msi.c | 5 +++--
.../fsl-mc/bus => bus/fsl-mc}/fsl-mc-private.h| 2 +-
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-io.c| 5 +++--
drivers/{staging/fsl-mc/bus => bus/fsl-mc}/mc-sys.c | 6 +++---
drivers/irqchip/Makefile | 1 +
.../bus => irqchip}/irq-gic-v3-its-fsl-mc-msi.c | 3 +--
drivers/staging/fsl-dpaa2/ethernet/README | 2 +-
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c| 4 ++--
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h| 2 +-
drivers/staging/fsl-dpaa2/ethernet/dpni.c | 4 ++--
drivers/staging/fsl-mc/TODO | 18 --
drivers/staging/fsl-mc/bus/Kconfig| 10 --
drivers/staging/fsl-mc/bus/Makefile | 15 +--
drivers/staging/fsl-mc/bus/dpcon.c| 8
drivers/staging/fsl-mc/bus/dpio/dpio-driver.c | 2 +-
drivers/staging/fsl-mc/bus/dpio/dpio-service.c| 2 +-
drivers/staging/fsl-mc/bus/dpio/dpio.c| 4 ++--
.../fsl-mc/include => include/linux/fsl}/dpbp.h | 0
.../fsl-mc/bus => include/linux/fsl}/dpcon-cmd.h | 0
.../fsl-mc/include => include/linux/fsl}/dpmng.h | 0
.../fsl-mc/include => include/linux/fsl}/dprc.h | 1 -
.../fsl-mc/include => include/linux/fsl}/mc-bus.h | 2 +-
.../fsl-mc/include => include/linux/fsl}/mc-cmd.h | 0
.../fsl-mc/include => include/linux/fsl}/mc-sys.h | 0
.../staging/fsl-mc/include => include/linux/fsl}/mc.h | 2 +-
43 files changed, 90 insertions(+), 89 deletions(-)
rename drivers/staging/fsl-mc/README.txt => Documentation/dpaa2/overview.txt
(100%)
create mode 100644 drivers/bus/fsl-mc/Kconfig
create mode 100644 drivers/bus/fsl-mc/Makefile
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp-cmd.h (100%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpbp.c (98%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp-cmd.h (100%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.c (98%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmcp.h (100%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng-cmd.h (100%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dpmng.c (96%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-cmd.h (100%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc-driver.c (99%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/dprc.c (99%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-allocator.c (99%)
rename drivers/{staging/fsl-mc/bus => bus/fsl-mc}/fsl-mc-bus.c (99%)
rename drivers/
[PATCH 6/6] Revert "staging: fsl-mc: Do not allow building as a module"
From: Matthias Brugger
This reverts commit ("staging: fsl-mc: Do not allow building as
a module")
Signed-off-by: Matthias Brugger
---
drivers/staging/fsl-mc/bus/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fsl-mc/bus/Kconfig
b/drivers/staging/fsl-mc/bus/Kconfig
index 1f95933..c498ac6 100644
--- a/drivers/staging/fsl-mc/bus/Kconfig
+++ b/drivers/staging/fsl-mc/bus/Kconfig
@@ -7,7 +7,7 @@
#
config FSL_MC_BUS
- bool "Freescale Management Complex (MC) bus driver"
+ tristate "Freescale Management Complex (MC) bus driver"
depends on OF && ARM64
select GENERIC_MSI_IRQ_DOMAIN
help
--
2.6.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/6] of/irq: Export of_msi_get_domain
From: Matthias Brugger Export of_mis_get_domain to enable it for users from outside. Signed-off-by: Matthias Brugger --- drivers/of/irq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/of/irq.c b/drivers/of/irq.c index e7bfc17..9f8cd6a 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -750,6 +750,7 @@ struct irq_domain *of_msi_get_domain(struct device *dev, return NULL; } +EXPORT_SYMBOL_GPL(of_msi_get_domain); /** * of_msi_configure - Set the msi_domain field of a device -- 2.6.6 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure
From: Matthias Brugger
The fsl-mc driver can't be build as a module because it uses msi_*
functions directly. Port the driver to use the platform_msi_*
infrastructure instead, to allow it to be build as a module.
Signed-off-by: Matthias Brugger
---
.../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 5 +-
drivers/staging/fsl-mc/bus/mc-allocator.c | 9 +-
drivers/staging/fsl-mc/bus/mc-msi.c| 169 +
drivers/staging/fsl-mc/include/mc-sys.h| 3 +
4 files changed, 14 insertions(+), 172 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index 720e2b0..0eecb7e 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -25,7 +25,6 @@ static struct irq_chip its_msi_irq_chip = {
.irq_mask = irq_chip_mask_parent,
.irq_unmask = irq_chip_unmask_parent,
.irq_eoi = irq_chip_eoi_parent,
- .irq_set_affinity = msi_domain_set_affinity
};
static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
@@ -86,7 +85,7 @@ int __init its_fsl_mc_msi_init(void)
continue;
}
- mc_msi_domain = fsl_mc_msi_create_irq_domain(
+ mc_msi_domain = platform_msi_create_irq_domain(
of_node_to_fwnode(np),
&its_fsl_mc_msi_domain_info,
parent);
@@ -113,7 +112,7 @@ void its_fsl_mc_msi_cleanup(void)
np = of_find_matching_node(np, its_device_id)) {
struct irq_domain *mc_msi_domain = irq_find_matching_host(
np,
- DOMAIN_BUS_FSL_MC_MSI);
+
DOMAIN_BUS_PLATFORM_MSI);
if (!of_property_read_bool(np, "msi-controller"))
continue;
diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index 86f8543..b469c5a 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -487,7 +487,8 @@ int fsl_mc_populate_irq_pool(struct fsl_mc_bus *mc_bus,
irq_count > FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS))
return -EINVAL;
- error = fsl_mc_msi_domain_alloc_irqs(&mc_bus_dev->dev, irq_count);
+ error = platform_msi_domain_alloc_irqs(&mc_bus_dev->dev, irq_count,
+ fsl_mc_msi_write_msg);
if (error < 0)
return error;
@@ -514,7 +515,7 @@ int fsl_mc_populate_irq_pool(struct fsl_mc_bus *mc_bus,
}
for_each_msi_entry(msi_desc, &mc_bus_dev->dev) {
- mc_dev_irq = &irq_resources[msi_desc->fsl_mc.msi_index];
+ mc_dev_irq = &irq_resources[msi_desc->platform.msi_index];
mc_dev_irq->msi_desc = msi_desc;
mc_dev_irq->resource.id = msi_desc->irq;
}
@@ -525,7 +526,7 @@ int fsl_mc_populate_irq_pool(struct fsl_mc_bus *mc_bus,
return 0;
cleanup_msi_irqs:
- fsl_mc_msi_domain_free_irqs(&mc_bus_dev->dev);
+ platform_msi_domain_free_irqs(&mc_bus_dev->dev);
return error;
}
EXPORT_SYMBOL_GPL(fsl_mc_populate_irq_pool);
@@ -553,7 +554,7 @@ void fsl_mc_cleanup_irq_pool(struct fsl_mc_bus *mc_bus)
res_pool->max_count = 0;
res_pool->free_count = 0;
mc_bus->irq_resources = NULL;
- fsl_mc_msi_domain_free_irqs(&mc_bus_dev->dev);
+ platform_msi_domain_free_irqs(&mc_bus_dev->dev);
}
EXPORT_SYMBOL_GPL(fsl_mc_cleanup_irq_pool);
diff --git a/drivers/staging/fsl-mc/bus/mc-msi.c
b/drivers/staging/fsl-mc/bus/mc-msi.c
index 3a8258f..ae62a71 100644
--- a/drivers/staging/fsl-mc/bus/mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/mc-msi.c
@@ -16,33 +16,9 @@
#include
#include
#include
-#include
#include "../include/mc-sys.h"
#include "dprc-cmd.h"
-static void fsl_mc_msi_set_desc(msi_alloc_info_t *arg,
- struct msi_desc *desc)
-{
- arg->desc = desc;
- arg->hwirq = (irq_hw_number_t)desc->fsl_mc.msi_index;
-}
-
-static void fsl_mc_msi_update_dom_ops(struct msi_domain_info *info)
-{
- struct msi_domain_ops *ops = info->ops;
-
- if (WARN_ON(!ops))
- return;
-
- /*
-* set_desc should not be set by the caller
-*/
- if (WARN_ON(ops->set_desc))
- return;
-
- ops->set_desc = fsl_mc_msi_set_desc;
-}
-
static void __fsl_mc_msi_write_msg(struct fsl_mc_device *mc_bus_dev,
struct
[PATCH 3/6] genirq/msi: Export msi_get_domain_info
From: Matthias Brugger
Allow modules to call msi_get_domain_info.
Signed-off-by: Matthias Brugger
---
kernel/irq/msi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 38e89ce..9b0ba4a 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -400,5 +400,6 @@ struct msi_domain_info *msi_get_domain_info(struct
irq_domain *domain)
{
return (struct msi_domain_info *)domain->host_data;
}
+EXPORT_SYMBOL_GPL(msi_get_domain_info);
#endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
--
2.6.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/6] base: Export platform_msi_create_irq_domain
From: Matthias Brugger Export platform_msi_create_irq_domain to make it useable from within modules. Signed-off-by: Matthias Brugger --- drivers/base/platform-msi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c index 279e539..9ae0443 100644 --- a/drivers/base/platform-msi.c +++ b/drivers/base/platform-msi.c @@ -200,6 +200,7 @@ struct irq_domain *platform_msi_create_irq_domain(struct fwnode_handle *fwnode, return domain; } +EXPORT_SYMBOL_GPL(platform_msi_create_irq_domain); static struct platform_msi_priv_data * platform_msi_alloc_priv_data(struct device *dev, unsigned int nvec, -- 2.6.6 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/6] staging: fsl-mc: Clean up of irq_chip callbacks
platform_msi_create_irq_domain already sets the irq_chip callbacks accordingly.
We don't need to define them explicitly in the driver.
Signed-off-by: Matthias Brugger
---
drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index 0eecb7e..c787090 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -22,9 +22,6 @@
static struct irq_chip its_msi_irq_chip = {
.name = "fsl-mc-bus-msi",
- .irq_mask = irq_chip_mask_parent,
- .irq_unmask = irq_chip_unmask_parent,
- .irq_eoi = irq_chip_eoi_parent,
};
static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
--
2.6.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
staging: fsl-mc: Convert to use platform_msi infrastrucutre
Freescale MC driver can't be build as module as it uses it's own msi implementation. This patch set converts the driver to use platform_msi infrastructure instead, so that we can build the driver as a module. Apart from that we have to export some functions of the msi framework to handle the domain. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/6] staging: fsl-mc: Use platform_msi_* infrastructure
On 13/04/16 12:56, Marc Zyngier wrote:
On 13/04/16 11:30, Matthias Brugger wrote:
From: Matthias Brugger
The fsl-mc driver can't be build as a module because it uses msi_*
functions directly. Port the driver to use the platform_msi_*
infrastructure instead, to allow it to be build as a module.
Signed-off-by: Matthias Brugger
---
.../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 5 +-
drivers/staging/fsl-mc/bus/mc-allocator.c | 9 +-
drivers/staging/fsl-mc/bus/mc-msi.c| 169 +
drivers/staging/fsl-mc/include/mc-sys.h| 3 +
4 files changed, 14 insertions(+), 172 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index 720e2b0..0eecb7e 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -25,7 +25,6 @@ static struct irq_chip its_msi_irq_chip = {
.irq_mask = irq_chip_mask_parent,
.irq_unmask = irq_chip_unmask_parent,
.irq_eoi = irq_chip_eoi_parent,
- .irq_set_affinity = msi_domain_set_affinity
};
static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
@@ -86,7 +85,7 @@ int __init its_fsl_mc_msi_init(void)
continue;
}
- mc_msi_domain = fsl_mc_msi_create_irq_domain(
+ mc_msi_domain = platform_msi_create_irq_domain(
of_node_to_fwnode(np),
&its_fsl_mc_msi_domain_info,
parent);
What? We are already creating a platform MSI domain for the ITS. How is
that going to work? If you want to convert this set of drivers to
platform ITS, fine. But you can't randomly hack in the ITS code and pray
for things not to fall apart.
From what I see, the difference between irq-gic-v3-its-fsl-mc-msi and
the irq-gic-v3-its-platform-msi is the way ITS specific DeviceID is
created in msi_prepare.
German, is there a reason why you use the ICID read from the DPRC as dev_id?
Regards,
Matthias
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fsl-mc: bus: Drop warning
When updating the irq_chip and msi_domain_ops, the code checkes for already present functions. When more then one ITS controller are present in the system, irq_chip and msi_domain_ops got already set and a warning is invoked. This patch deletes the warning, as the funtions are just already set to the needed callbacks. Signed-off-by: Matthias Brugger --- drivers/staging/fsl-mc/bus/mc-msi.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/staging/fsl-mc/bus/mc-msi.c b/drivers/staging/fsl-mc/bus/mc-msi.c index 3a8258f..c0933fe 100644 --- a/drivers/staging/fsl-mc/bus/mc-msi.c +++ b/drivers/staging/fsl-mc/bus/mc-msi.c @@ -37,10 +37,8 @@ static void fsl_mc_msi_update_dom_ops(struct msi_domain_info *info) /* * set_desc should not be set by the caller */ - if (WARN_ON(ops->set_desc)) - return; - - ops->set_desc = fsl_mc_msi_set_desc; + if (ops->set_desc == NULL) + ops->set_desc = fsl_mc_msi_set_desc; } static void __fsl_mc_msi_write_msg(struct fsl_mc_device *mc_bus_dev, @@ -129,10 +127,8 @@ static void fsl_mc_msi_update_chip_ops(struct msi_domain_info *info) /* * irq_write_msi_msg should not be set by the caller */ - if (WARN_ON(chip->irq_write_msi_msg)) - return; - - chip->irq_write_msi_msg = fsl_mc_msi_write_msg; + if (chip->irq_write_msi_msg == NULL) + chip->irq_write_msi_msg = fsl_mc_msi_write_msg; } /** -- 2.6.6 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fsl-mc: bus: Drop warning
On 15/04/16 00:57, Stuart Yoder wrote: -Original Message- From: Matthias Brugger [mailto:mbrug...@suse.com] Sent: Thursday, April 14, 2016 4:24 PM To: german.riv...@freescale.com; gre...@linuxfoundation.org Cc: Stuart Yoder ; Scott Wood ; ag...@suse.de; linux- ker...@vger.kernel.org; de...@driverdev.osuosl.org; mbrug...@suse.com Subject: [PATCH] staging: fsl-mc: bus: Drop warning When updating the irq_chip and msi_domain_ops, the code checkes for already present functions. When more then one ITS controller are present in the system, irq_chip and msi_domain_ops got already set and a warning is invoked. How can this situation happen? And what do you mean by multiple ITS controllers? ...multiple instances of the GIC ITS on an SoC? Yes, there are two arm,gic-v3-its defined in the FDT. ~ # ll /proc/device-tree/interrupt-controller@8010\,/ total 0 -r--r--r-- 1 root root 4 Apr 15 12:31 #address-cells -r--r--r-- 1 root root 11 Apr 15 12:31 compatible drwxr-xr-x 2 root root 0 Apr 15 12:31 gic-its@8010,0002 drwxr-xr-x 2 root root 0 Apr 15 12:31 gic-its@9010,0002 -r--r--r-- 1 root root 4 Apr 15 12:31 #interrupt-cells -r--r--r-- 1 root root 0 Apr 15 12:31 interrupt-controller -r--r--r-- 1 root root 12 Apr 15 12:31 interrupts -r--r--r-- 1 root root 4 Apr 15 12:31 linux,phandle -r--r--r-- 1 root root 21 Apr 15 12:31 name -r--r--r-- 1 root root 4 Apr 15 12:31 phandle -r--r--r-- 1 root root 0 Apr 15 12:31 ranges -r--r--r-- 1 root root 4 Apr 15 12:31 #redistributor-regions -r--r--r-- 1 root root 48 Apr 15 12:31 reg -r--r--r-- 1 root root 4 Apr 15 12:31 #size-cells Regards, Matthias ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/11] staging: fsl-mc: make fsl_mc_is_root_dprc() global
On 22/06/16 23:40, Stuart Yoder wrote:
make fsl_mc_is_root_dprc() global so that the dprc driver
can use it
Signed-off-by: Stuart Yoder
---
drivers/staging/fsl-mc/bus/mc-bus.c | 28 +---
drivers/staging/fsl-mc/include/mc.h | 2 ++
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index e975adc..a49186e 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -24,8 +24,6 @@
static struct kmem_cache *mc_dev_cache;
-static bool fsl_mc_is_root_dprc(struct device *dev);
-
/**
* fsl_mc_bus_match - device to driver matching callback
* @dev: the MC object device structure to match against
@@ -247,19 +245,6 @@ static void fsl_mc_get_root_dprc(struct device *dev,
}
}
-/**
- * fsl_mc_is_root_dprc - function to check if a given device is a root dprc
- */
-static bool fsl_mc_is_root_dprc(struct device *dev)
-{
- struct device *root_dprc_dev;
-
- fsl_mc_get_root_dprc(dev, &root_dprc_dev);
- if (!root_dprc_dev)
- return false;
- return dev == root_dprc_dev;
-}
-
static int get_dprc_attr(struct fsl_mc_io *mc_io,
int container_id, struct dprc_attributes *attr)
{
@@ -424,6 +409,19 @@ error_cleanup_regions:
}
/**
+ * fsl_mc_is_root_dprc - function to check if a given device is a root dprc
+ */
+bool fsl_mc_is_root_dprc(struct device *dev)
+{
+ struct device *root_dprc_dev;
+
+ fsl_mc_get_root_dprc(dev, &root_dprc_dev);
+ if (!root_dprc_dev)
+ return false;
+ return dev == root_dprc_dev;
+}
+
+/**
Is there any reason why apart from deleting "static" you move
fsl_mc_is_root to a different line?
Regards,
Matthias
* Add a newly discovered MC object device to be visible in Linux
*/
int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
diff --git a/drivers/staging/fsl-mc/include/mc.h
b/drivers/staging/fsl-mc/include/mc.h
index a9a9d23..853cbf3 100644
--- a/drivers/staging/fsl-mc/include/mc.h
+++ b/drivers/staging/fsl-mc/include/mc.h
@@ -207,6 +207,8 @@ int __must_check fsl_mc_allocate_irqs(struct fsl_mc_device
*mc_dev);
void fsl_mc_free_irqs(struct fsl_mc_device *mc_dev);
+bool fsl_mc_is_root_dprc(struct device *dev);
+
extern struct bus_type fsl_mc_bus_type;
#endif /* _FSL_MC_H_ */
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/11] staging: fsl-mc: make fsl_mc_is_root_dprc() global
On 29/06/16 16:25, Stuart Yoder wrote:
-Original Message-
From: Matthias Brugger [mailto:mbrug...@suse.com]
Sent: Wednesday, June 29, 2016 9:17 AM
To: Stuart Yoder ; gre...@linuxfoundation.org
Cc: de...@driverdev.osuosl.org; ag...@suse.de; a...@arndb.de; Jose Rivera
;
linux-ker...@vger.kernel.org; Yang-Leo Li
Subject: Re: [PATCH 06/11] staging: fsl-mc: make fsl_mc_is_root_dprc() global
On 22/06/16 23:40, Stuart Yoder wrote:
make fsl_mc_is_root_dprc() global so that the dprc driver
can use it
Signed-off-by: Stuart Yoder
---
drivers/staging/fsl-mc/bus/mc-bus.c | 28 +---
drivers/staging/fsl-mc/include/mc.h | 2 ++
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index e975adc..a49186e 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -24,8 +24,6 @@
static struct kmem_cache *mc_dev_cache;
-static bool fsl_mc_is_root_dprc(struct device *dev);
-
/**
* fsl_mc_bus_match - device to driver matching callback
* @dev: the MC object device structure to match against
@@ -247,19 +245,6 @@ static void fsl_mc_get_root_dprc(struct device *dev,
}
}
-/**
- * fsl_mc_is_root_dprc - function to check if a given device is a root dprc
- */
-static bool fsl_mc_is_root_dprc(struct device *dev)
-{
- struct device *root_dprc_dev;
-
- fsl_mc_get_root_dprc(dev, &root_dprc_dev);
- if (!root_dprc_dev)
- return false;
- return dev == root_dprc_dev;
-}
-
static int get_dprc_attr(struct fsl_mc_io *mc_io,
int container_id, struct dprc_attributes *attr)
{
@@ -424,6 +409,19 @@ error_cleanup_regions:
}
/**
+ * fsl_mc_is_root_dprc - function to check if a given device is a root dprc
+ */
+bool fsl_mc_is_root_dprc(struct device *dev)
+{
+ struct device *root_dprc_dev;
+
+ fsl_mc_get_root_dprc(dev, &root_dprc_dev);
+ if (!root_dprc_dev)
+ return false;
+ return dev == root_dprc_dev;
+}
+
+/**
Is there any reason why apart from deleting "static" you move
fsl_mc_is_root to a different line?
I moved it just to keep internal consistency inside the source file where all
the
static functions were grouped together in the first part of the file, and public
functions were in the second part.
Ok, thanks for clarification.
Reviewed-by: Matthias Brugger
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/11] staging: fsl-mc: clean up the device id struct
On 22/06/16 23:40, Stuart Yoder wrote:
-rename the struct used for fsl-mc device ids to be more
consistent with other busses
-remove the now obsolete and unused version fields
Signed-off-by: Stuart Yoder
---
drivers/staging/fsl-mc/bus/dprc-driver.c | 2 +-
drivers/staging/fsl-mc/bus/mc-allocator.c | 2 +-
drivers/staging/fsl-mc/bus/mc-bus.c | 2 +-
drivers/staging/fsl-mc/include/mc.h | 10 +++---
4 files changed, 6 insertions(+), 10 deletions(-)
Reviewed-by: Matthias Brugger
diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index 7fc4717..f865d18 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -805,7 +805,7 @@ static int dprc_remove(struct fsl_mc_device *mc_dev)
return 0;
}
-static const struct fsl_mc_device_match_id match_id_table[] = {
+static const struct fsl_mc_device_id match_id_table[] = {
{
.vendor = FSL_MC_VENDOR_FREESCALE,
.obj_type = "dprc"},
diff --git a/drivers/staging/fsl-mc/bus/mc-allocator.c
b/drivers/staging/fsl-mc/bus/mc-allocator.c
index fb08f22..e59d850 100644
--- a/drivers/staging/fsl-mc/bus/mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/mc-allocator.c
@@ -717,7 +717,7 @@ static int fsl_mc_allocator_remove(struct fsl_mc_device
*mc_dev)
return 0;
}
-static const struct fsl_mc_device_match_id match_id_table[] = {
+static const struct fsl_mc_device_id match_id_table[] = {
{
.vendor = FSL_MC_VENDOR_FREESCALE,
.obj_type = "dpbp",
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index cf92a1c..e975adc 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -36,7 +36,7 @@ static bool fsl_mc_is_root_dprc(struct device *dev);
*/
static int fsl_mc_bus_match(struct device *dev, struct device_driver *drv)
{
- const struct fsl_mc_device_match_id *id;
+ const struct fsl_mc_device_id *id;
struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
struct fsl_mc_driver *mc_drv = to_fsl_mc_driver(drv);
bool found = false;
diff --git a/drivers/staging/fsl-mc/include/mc.h
b/drivers/staging/fsl-mc/include/mc.h
index ac7c1ce..bc0d45c 100644
--- a/drivers/staging/fsl-mc/include/mc.h
+++ b/drivers/staging/fsl-mc/include/mc.h
@@ -39,7 +39,7 @@ struct fsl_mc_bus;
*/
struct fsl_mc_driver {
struct device_driver driver;
- const struct fsl_mc_device_match_id *match_id_table;
+ const struct fsl_mc_device_id *match_id_table;
int (*probe)(struct fsl_mc_device *dev);
int (*remove)(struct fsl_mc_device *dev);
void (*shutdown)(struct fsl_mc_device *dev);
@@ -51,20 +51,16 @@ struct fsl_mc_driver {
container_of(_drv, struct fsl_mc_driver, driver)
/**
- * struct fsl_mc_device_match_id - MC object device Id entry for driver
matching
+ * struct fsl_mc_device_id - MC object device Id entry for driver matching
* @vendor: vendor ID
* @obj_type: MC object type
- * @ver_major: MC object version major number
- * @ver_minor: MC object version minor number
*
* Type of entries in the "device Id" table for MC object devices supported by
* a MC object device driver. The last entry of the table has vendor set to
0x0
*/
-struct fsl_mc_device_match_id {
+struct fsl_mc_device_id {
u16 vendor;
const char obj_type[16];
- u32 ver_major;
- u32 ver_minor;
};
/**
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
