Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-26 Thread Pierre-Louis Bossart




On 3/24/21 10:36 AM, Greg KH wrote:

On Wed, Mar 24, 2021 at 09:55:01AM -0500, Pierre-Louis Bossart wrote:

Note at this point it would mean an API change and impact the existing
Nvidia/Mellanox code, we are using the same sequence as them


THere is no "stable api" in the kernel, so if something has to change,
that's fine, we can change the users at the same time, not an issue.


What I meant is that this requires consensus to make a change, and so 
far I haven't seen any burning desire from the contributors to revisit 
the 2-step sequence.


I will however modify the code in this patch to implement a SoundWire 
'linkdev' register/unregister function, it'll be much easier to review 
and maintain, and will follow the same pattern as the mlx5 code (all 
errors and domain-specific initializations handled in the same 
function). Draft code being tested is at 
https://github.com/thesofproject/linux/pull/2809


Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-24 Thread Greg KH
On Wed, Mar 24, 2021 at 09:55:01AM -0500, Pierre-Louis Bossart wrote:
> Note at this point it would mean an API change and impact the existing
> Nvidia/Mellanox code, we are using the same sequence as them

THere is no "stable api" in the kernel, so if something has to change,
that's fine, we can change the users at the same time, not an issue.

thanks,

greg k-h


Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-24 Thread Pierre-Louis Bossart




On 3/24/21 5:50 AM, Vinod Koul wrote:

On 23-03-21, 12:29, Pierre-Louis Bossart wrote:

Thanks Greg and Vinod for the reviews


-static int intel_master_probe(struct platform_device *pdev)
+static int intel_link_probe(struct auxiliary_device *auxdev, const struct 
auxiliary_device_id *id)
   {
-   struct device *dev = &pdev->dev;
+   struct device *dev = &auxdev->dev;
+   struct sdw_intel_link_dev *ldev = 
auxiliary_dev_to_sdw_intel_link_dev(auxdev);


Do we need another abstractions for resources here, why not aux dev
creation set the resources required and we skip this step...


Not sure what resources you are referring to?


Resources in the sdw_intel_link_dev which are sdw_intel_link_res. They
should be resources for auxdev and if you do that lets you get rid of
this abstraction.


Sorry Vinod, I am not following your line of thought. We must be talking 
of different things or having a different understanding of what the 
auxiliary device is.


The auxiliary device is deliberately minimal by design and does not 
contain domain-specific information/resources/pointers/pdata as the 
platform_device does. You extend it by defining a larger structure that 
contains an auxiliary device and whatever domain-specific 
fields/structures/domains are needed, then use container_of to access it.


It's not just Intel doing this, the first example from Mellanox uses the 
same pattern, albeit with a single pointer instead of the structure we used.


see e.g. 
https://elixir.bootlin.com/linux/latest/source/include/linux/mlx5/driver.h#L545


So I am not sure what you mean by 'rid of this abstraction' when this 
abstraction is pretty much the way things were designed?


Maybe an example of what sort of structure you had in mind would help?



this is just a container_of() and the documented way of extending the auxbus
(see 
https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#example-usage)


struct sdw_intel_link_dev {
struct auxiliary_device auxdev;
struct sdw_intel_link_res link_res;
};

#define auxiliary_dev_to_sdw_intel_link_dev(auxiliary_dev) \
container_of(auxiliary_dev, struct sdw_intel_link_dev, auxdev)


struct sdw_intel *sdw;
struct sdw_cdns *cdns;
struct sdw_bus *bus;
@@ -1346,14 +1347,14 @@ static int intel_master_probe(struct platform_device 
*pdev)
cdns = &sdw->cdns;
bus = &cdns->bus;
-   sdw->instance = pdev->id;
-   sdw->link_res = dev_get_platdata(dev);
+   sdw->instance = auxdev->id;


so auxdev has id and still we pass id as argument :( Not sure if folks
can fix this now


That's odd, yeah, it should be fixed.


I think we are talking about different things?

this is defined in mod_devicetable.h:

struct auxiliary_device_id {
char name[AUXILIARY_NAME_SIZE];
kernel_ulong_t driver_data;
};

and used for the driver probe:

ret = auxdrv->probe(auxdev, auxiliary_match_id(auxdrv->id_table, 
auxdev));

but there is a separate id:

struct auxiliary_device {
struct device dev;
const char *name;
u32 id;
};

which is set during the device initialization in intel_init.c

/* we don't use an IDA since we already have a link ID */
auxdev->id = link_id;

In the auxiliary bus design, the parent has to take care of managing this
id, be it with an IDA or as we do here with a physical link ID that is
unique.


Aha, maybe both of them should not be 'id' to avoid this confusion!


the function definition follows the expected prototype

struct auxiliary_driver {
int (*probe)(struct auxiliary_device *,
 const struct auxiliary_device_id *id);

we can rename the argument to e.g. dev_id if that helps. Suggestions 
welcome.



That also reminds me that we have duplicate info:

+   sdw->instance = auxdev->id;
+   bus->link_id = auxdev->id;

drop the local driver instance and use bus->link_id please


if you are referring to sdw->instance, it could probably be removed, but 
that would need to be a separate cleanup changing cadence_master.c as 
well. this patch only changes pdev->id with auxdev->id and provides only 
the transition from platform device to auxiliary device.




Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-24 Thread Pierre-Louis Bossart




Note that the auxiliary bus API has separate init and add steps, which
requires more attention in the error unwinding paths. The main loop
needs to deal with kfree() and auxiliary_device_uninit() for the
current iteration before jumping to the common label which releases
everything allocated in prior iterations.


The init/add steps can be moved together in the aux bus code if that
makes this usage simpler.  Please do that instead.


IIRC the two steps were separated during the auxbus reviews to allow the
parent to call kfree() on an init failure, and auxiliary_device_uninit()
afterwards.

https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#auxiliary-device

With a single auxbus_register(), the parent wouldn't know whether to use
kfree() or auxiliary_device_uinit() when an error is returned, would it?



It should, you know the difference when you call device_register() vs.
device_initialize()/device_add(), for what to do, right?

Should be no difference here either :)


sorry, not following.

with the regular devices, the errors can only happen on the second "add"
stage.

int device_register(struct device *dev)
{
device_initialize(dev);
return device_add(dev);
}

that's not what is currently implemented for the auxiliary bus

the current flow is

ldev = kzalloc(..)
some inits
ret = auxiliary_device_init(&ldev->auxdev)
if (ret < 0) {
 kfree(ldev);
 goto err1;
}

ret = auxiliary_device_add(&ldev->auxdev)
if (ret < 0)
 auxiliary_device_uninit(&ldev->auxdev)
 goto err2;
}
...
err2:
err1:

How would I convert this to

ldev = kzalloc(..)
some inits
ret = auxiliary_device_register()
if (ret) {
kfree(ldev) or not?
unit or not?
}

IIRC during reviews there was an ask that the parent and name be checked,
and that's why the code added the two checks below:

int auxiliary_device_init(struct auxiliary_device *auxdev)
{
struct device *dev = &auxdev->dev;

if (!dev->parent) {
pr_err("auxiliary_device has a NULL dev->parent\n");
return -EINVAL;
}

if (!auxdev->name) {
pr_err("auxiliary_device has a NULL name\n");
return -EINVAL;
}

dev->bus = &auxiliary_bus_type;
device_initialize(&auxdev->dev);
return 0;
}

does this clarify the sequence?


Yes, thanks, but I don't know the answer to your question, sorry.  This
feels more complex than it should be, but I do not have the time at the
moment to look into it, sorry.

Try getting the authors of this code to fix it up :)


We can try to check why those two tests were added before initialize(), 
I don't fully recall these details


If we could move these tests after device_initialize() then we could add 
a _register function.


Note at this point it would mean an API change and impact the existing 
Nvidia/Mellanox code, we are using the same sequence as them


https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/mellanox/mlx5/core/dev.c#L262



Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-24 Thread Vinod Koul
On 23-03-21, 12:29, Pierre-Louis Bossart wrote:
> Thanks Greg and Vinod for the reviews
> 
> > > > -static int intel_master_probe(struct platform_device *pdev)
> > > > +static int intel_link_probe(struct auxiliary_device *auxdev, const 
> > > > struct auxiliary_device_id *id)
> > > >   {
> > > > -   struct device *dev = &pdev->dev;
> > > > +   struct device *dev = &auxdev->dev;
> > > > +   struct sdw_intel_link_dev *ldev = 
> > > > auxiliary_dev_to_sdw_intel_link_dev(auxdev);
> > > 
> > > Do we need another abstractions for resources here, why not aux dev
> > > creation set the resources required and we skip this step...
> 
> Not sure what resources you are referring to?

Resources in the sdw_intel_link_dev which are sdw_intel_link_res. They
should be resources for auxdev and if you do that lets you get rid of
this abstraction.

> 
> this is just a container_of() and the documented way of extending the auxbus
> (see 
> https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#example-usage)
> 
> 
> struct sdw_intel_link_dev {
>   struct auxiliary_device auxdev;
>   struct sdw_intel_link_res link_res;
> };
> 
> #define auxiliary_dev_to_sdw_intel_link_dev(auxiliary_dev) \
>   container_of(auxiliary_dev, struct sdw_intel_link_dev, auxdev)
> 
> > > > struct sdw_intel *sdw;
> > > > struct sdw_cdns *cdns;
> > > > struct sdw_bus *bus;
> > > > @@ -1346,14 +1347,14 @@ static int intel_master_probe(struct 
> > > > platform_device *pdev)
> > > > cdns = &sdw->cdns;
> > > > bus = &cdns->bus;
> > > > -   sdw->instance = pdev->id;
> > > > -   sdw->link_res = dev_get_platdata(dev);
> > > > +   sdw->instance = auxdev->id;
> > > 
> > > so auxdev has id and still we pass id as argument :( Not sure if folks
> > > can fix this now
> > 
> > That's odd, yeah, it should be fixed.
> 
> I think we are talking about different things?
> 
> this is defined in mod_devicetable.h:
> 
> struct auxiliary_device_id {
>   char name[AUXILIARY_NAME_SIZE];
>   kernel_ulong_t driver_data;
> };
> 
> and used for the driver probe:
> 
>   ret = auxdrv->probe(auxdev, auxiliary_match_id(auxdrv->id_table, 
> auxdev));
> 
> but there is a separate id:
> 
> struct auxiliary_device {
>   struct device dev;
>   const char *name;
>   u32 id;
> };
> 
> which is set during the device initialization in intel_init.c
> 
>   /* we don't use an IDA since we already have a link ID */
>   auxdev->id = link_id;
> 
> In the auxiliary bus design, the parent has to take care of managing this
> id, be it with an IDA or as we do here with a physical link ID that is
> unique.

Aha, maybe both of them should not be 'id' to avoid this confusion!

That also reminds me that we have duplicate info:

+   sdw->instance = auxdev->id;
+   bus->link_id = auxdev->id;

drop the local driver instance and use bus->link_id please

> in short, I don't see how I could change the code given the differences in
> concepts?

-- 
~Vinod


Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-24 Thread Greg KH
On Tue, Mar 23, 2021 at 02:14:18PM -0500, Pierre-Louis Bossart wrote:
> 
> 
> On 3/23/21 1:32 PM, Greg KH wrote:
> > On Tue, Mar 23, 2021 at 01:04:49PM -0500, Pierre-Louis Bossart wrote:
> > > 
> > > > > Note that the auxiliary bus API has separate init and add steps, which
> > > > > requires more attention in the error unwinding paths. The main loop
> > > > > needs to deal with kfree() and auxiliary_device_uninit() for the
> > > > > current iteration before jumping to the common label which releases
> > > > > everything allocated in prior iterations.
> > > > 
> > > > The init/add steps can be moved together in the aux bus code if that
> > > > makes this usage simpler.  Please do that instead.
> > > 
> > > IIRC the two steps were separated during the auxbus reviews to allow the
> > > parent to call kfree() on an init failure, and auxiliary_device_uninit()
> > > afterwards.
> > > 
> > > https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#auxiliary-device
> > > 
> > > With a single auxbus_register(), the parent wouldn't know whether to use
> > > kfree() or auxiliary_device_uinit() when an error is returned, would it?
> > > 
> > 
> > It should, you know the difference when you call device_register() vs.
> > device_initialize()/device_add(), for what to do, right?
> > 
> > Should be no difference here either :)
> 
> sorry, not following.
> 
> with the regular devices, the errors can only happen on the second "add"
> stage.
> 
> int device_register(struct device *dev)
> {
>   device_initialize(dev);
>   return device_add(dev);
> }
> 
> that's not what is currently implemented for the auxiliary bus
> 
> the current flow is
> 
> ldev = kzalloc(..)
> some inits
> ret = auxiliary_device_init(&ldev->auxdev)
> if (ret < 0) {
> kfree(ldev);
> goto err1;
> }
> 
> ret = auxiliary_device_add(&ldev->auxdev)
> if (ret < 0)
> auxiliary_device_uninit(&ldev->auxdev)
> goto err2;
> }
> ...
> err2:
> err1:
> 
> How would I convert this to
> 
> ldev = kzalloc(..)
> some inits
> ret = auxiliary_device_register()
> if (ret) {
>kfree(ldev) or not?
>unit or not?
> }
> 
> IIRC during reviews there was an ask that the parent and name be checked,
> and that's why the code added the two checks below:
> 
> int auxiliary_device_init(struct auxiliary_device *auxdev)
> {
>   struct device *dev = &auxdev->dev;
> 
>   if (!dev->parent) {
>   pr_err("auxiliary_device has a NULL dev->parent\n");
>   return -EINVAL;
>   }
> 
>   if (!auxdev->name) {
>   pr_err("auxiliary_device has a NULL name\n");
>   return -EINVAL;
>   }
> 
>   dev->bus = &auxiliary_bus_type;
>   device_initialize(&auxdev->dev);
>   return 0;
> }
> 
> does this clarify the sequence?

Yes, thanks, but I don't know the answer to your question, sorry.  This
feels more complex than it should be, but I do not have the time at the
moment to look into it, sorry.

Try getting the authors of this code to fix it up :)

thanks,

greg k-h


Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-23 Thread Pierre-Louis Bossart




On 3/23/21 1:32 PM, Greg KH wrote:

On Tue, Mar 23, 2021 at 01:04:49PM -0500, Pierre-Louis Bossart wrote:



Note that the auxiliary bus API has separate init and add steps, which
requires more attention in the error unwinding paths. The main loop
needs to deal with kfree() and auxiliary_device_uninit() for the
current iteration before jumping to the common label which releases
everything allocated in prior iterations.


The init/add steps can be moved together in the aux bus code if that
makes this usage simpler.  Please do that instead.


IIRC the two steps were separated during the auxbus reviews to allow the
parent to call kfree() on an init failure, and auxiliary_device_uninit()
afterwards.

https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#auxiliary-device

With a single auxbus_register(), the parent wouldn't know whether to use
kfree() or auxiliary_device_uinit() when an error is returned, would it?



It should, you know the difference when you call device_register() vs.
device_initialize()/device_add(), for what to do, right?

Should be no difference here either :)


sorry, not following.

with the regular devices, the errors can only happen on the second "add" 
stage.


int device_register(struct device *dev)
{
device_initialize(dev);
return device_add(dev);
}

that's not what is currently implemented for the auxiliary bus

the current flow is

ldev = kzalloc(..)
some inits
ret = auxiliary_device_init(&ldev->auxdev)
if (ret < 0) {
kfree(ldev);
goto err1;
}

ret = auxiliary_device_add(&ldev->auxdev)
if (ret < 0)
auxiliary_device_uninit(&ldev->auxdev)
goto err2;
}
...
err2:
err1:

How would I convert this to

ldev = kzalloc(..)
some inits
ret = auxiliary_device_register()
if (ret) {
   kfree(ldev) or not?
   unit or not?
}

IIRC during reviews there was an ask that the parent and name be 
checked, and that's why the code added the two checks below:


int auxiliary_device_init(struct auxiliary_device *auxdev)
{
struct device *dev = &auxdev->dev;

if (!dev->parent) {
pr_err("auxiliary_device has a NULL dev->parent\n");
return -EINVAL;
}

if (!auxdev->name) {
pr_err("auxiliary_device has a NULL name\n");
return -EINVAL;
}

dev->bus = &auxiliary_bus_type;
device_initialize(&auxdev->dev);
return 0;
}

does this clarify the sequence?









Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-23 Thread Greg KH
On Tue, Mar 23, 2021 at 01:04:49PM -0500, Pierre-Louis Bossart wrote:
> 
> > > Note that the auxiliary bus API has separate init and add steps, which
> > > requires more attention in the error unwinding paths. The main loop
> > > needs to deal with kfree() and auxiliary_device_uninit() for the
> > > current iteration before jumping to the common label which releases
> > > everything allocated in prior iterations.
> > 
> > The init/add steps can be moved together in the aux bus code if that
> > makes this usage simpler.  Please do that instead.
> 
> IIRC the two steps were separated during the auxbus reviews to allow the
> parent to call kfree() on an init failure, and auxiliary_device_uninit()
> afterwards.
> 
> https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#auxiliary-device
> 
> With a single auxbus_register(), the parent wouldn't know whether to use
> kfree() or auxiliary_device_uinit() when an error is returned, would it?
> 

It should, you know the difference when you call device_register() vs.
device_initialize()/device_add(), for what to do, right?

Should be no difference here either :)


Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-23 Thread Pierre-Louis Bossart




Note that the auxiliary bus API has separate init and add steps, which
requires more attention in the error unwinding paths. The main loop
needs to deal with kfree() and auxiliary_device_uninit() for the
current iteration before jumping to the common label which releases
everything allocated in prior iterations.


The init/add steps can be moved together in the aux bus code if that
makes this usage simpler.  Please do that instead.


IIRC the two steps were separated during the auxbus reviews to allow the 
parent to call kfree() on an init failure, and auxiliary_device_uninit() 
afterwards.


https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#auxiliary-device

With a single auxbus_register(), the parent wouldn't know whether to use 
kfree() or auxiliary_device_uinit() when an error is returned, would it?




Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-23 Thread Pierre-Louis Bossart

Thanks Greg and Vinod for the reviews


-static int intel_master_probe(struct platform_device *pdev)
+static int intel_link_probe(struct auxiliary_device *auxdev, const struct 
auxiliary_device_id *id)
  {
-   struct device *dev = &pdev->dev;
+   struct device *dev = &auxdev->dev;
+   struct sdw_intel_link_dev *ldev = 
auxiliary_dev_to_sdw_intel_link_dev(auxdev);


Do we need another abstractions for resources here, why not aux dev
creation set the resources required and we skip this step...


Not sure what resources you are referring to?

this is just a container_of() and the documented way of extending the 
auxbus (see 
https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html#example-usage)



struct sdw_intel_link_dev {
struct auxiliary_device auxdev;
struct sdw_intel_link_res link_res;
};

#define auxiliary_dev_to_sdw_intel_link_dev(auxiliary_dev) \
container_of(auxiliary_dev, struct sdw_intel_link_dev, auxdev)


struct sdw_intel *sdw;
struct sdw_cdns *cdns;
struct sdw_bus *bus;
@@ -1346,14 +1347,14 @@ static int intel_master_probe(struct platform_device 
*pdev)
cdns = &sdw->cdns;
bus = &cdns->bus;
  
-	sdw->instance = pdev->id;

-   sdw->link_res = dev_get_platdata(dev);
+   sdw->instance = auxdev->id;


so auxdev has id and still we pass id as argument :( Not sure if folks
can fix this now


That's odd, yeah, it should be fixed.


I think we are talking about different things?

this is defined in mod_devicetable.h:

struct auxiliary_device_id {
char name[AUXILIARY_NAME_SIZE];
kernel_ulong_t driver_data;
};

and used for the driver probe:

ret = auxdrv->probe(auxdev, auxiliary_match_id(auxdrv->id_table, 
auxdev));

but there is a separate id:

struct auxiliary_device {
struct device dev;
const char *name;
u32 id;
};

which is set during the device initialization in intel_init.c

/* we don't use an IDA since we already have a link ID */
auxdev->id = link_id;

In the auxiliary bus design, the parent has to take care of managing 
this id, be it with an IDA or as we do here with a physical link ID that 
is unique.


in short, I don't see how I could change the code given the differences 
in concepts?




Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-23 Thread Greg KH
On Tue, Mar 23, 2021 at 12:18:46PM +0530, Vinod Koul wrote:
> On 23-03-21, 08:43, Bard Liao wrote:
> > From: Pierre-Louis Bossart 
> > 
> > Now that the auxiliary_bus exists, there's no reason to use platform
> > devices as children of a PCI device any longer.
> > 
> > This patch refactors the code by extending a basic auxiliary device
> > with Intel link-specific structures that need to be passed between
> > controller and link levels. This refactoring is much cleaner with no
> > need for cross-pointers between device and link structures.
> > 
> > Note that the auxiliary bus API has separate init and add steps, which
> > requires more attention in the error unwinding paths. The main loop
> > needs to deal with kfree() and auxiliary_device_uninit() for the
> > current iteration before jumping to the common label which releases
> > everything allocated in prior iterations.
> > 
> > Signed-off-by: Pierre-Louis Bossart 
> > Reviewed-by: Guennadi Liakhovetski 
> > Reviewed-by: Ranjani Sridharan 
> > Signed-off-by: Bard Liao 
> > ---
> >  drivers/soundwire/Kconfig   |   1 +
> >  drivers/soundwire/intel.c   |  52 
> >  drivers/soundwire/intel.h   |  14 +-
> >  drivers/soundwire/intel_init.c  | 190 +++-
> >  include/linux/soundwire/sdw_intel.h |   6 +-
> >  5 files changed, 175 insertions(+), 88 deletions(-)
> > 
> > diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
> > index 016e74230bb7..2b7795233282 100644
> > --- a/drivers/soundwire/Kconfig
> > +++ b/drivers/soundwire/Kconfig
> > @@ -25,6 +25,7 @@ config SOUNDWIRE_INTEL
> > tristate "Intel SoundWire Master driver"
> > select SOUNDWIRE_CADENCE
> > select SOUNDWIRE_GENERIC_ALLOCATION
> > +   select AUXILIARY_BUS
> > depends on ACPI && SND_SOC
> > help
> >   SoundWire Intel Master driver.
> > diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
> > index d2254ee2fee2..039a101982c9 100644
> > --- a/drivers/soundwire/intel.c
> > +++ b/drivers/soundwire/intel.c
> > @@ -11,7 +11,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1331,9 +1331,10 @@ static int intel_init(struct sdw_intel *sdw)
> >  /*
> >   * probe and init
> >   */
> > -static int intel_master_probe(struct platform_device *pdev)
> > +static int intel_link_probe(struct auxiliary_device *auxdev, const struct 
> > auxiliary_device_id *id)
> >  {
> > -   struct device *dev = &pdev->dev;
> > +   struct device *dev = &auxdev->dev;
> > +   struct sdw_intel_link_dev *ldev = 
> > auxiliary_dev_to_sdw_intel_link_dev(auxdev);
> 
> Do we need another abstractions for resources here, why not aux dev
> creation set the resources required and we skip this step...
> 
> > struct sdw_intel *sdw;
> > struct sdw_cdns *cdns;
> > struct sdw_bus *bus;
> > @@ -1346,14 +1347,14 @@ static int intel_master_probe(struct 
> > platform_device *pdev)
> > cdns = &sdw->cdns;
> > bus = &cdns->bus;
> >  
> > -   sdw->instance = pdev->id;
> > -   sdw->link_res = dev_get_platdata(dev);
> > +   sdw->instance = auxdev->id;
> 
> so auxdev has id and still we pass id as argument :( Not sure if folks
> can fix this now

That's odd, yeah, it should be fixed.

greg k-h


Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-23 Thread Greg KH
On Tue, Mar 23, 2021 at 08:43:25AM +0800, Bard Liao wrote:
> From: Pierre-Louis Bossart 
> 
> Now that the auxiliary_bus exists, there's no reason to use platform
> devices as children of a PCI device any longer.
> 
> This patch refactors the code by extending a basic auxiliary device
> with Intel link-specific structures that need to be passed between
> controller and link levels. This refactoring is much cleaner with no
> need for cross-pointers between device and link structures.
> 
> Note that the auxiliary bus API has separate init and add steps, which
> requires more attention in the error unwinding paths. The main loop
> needs to deal with kfree() and auxiliary_device_uninit() for the
> current iteration before jumping to the common label which releases
> everything allocated in prior iterations.

The init/add steps can be moved together in the aux bus code if that
makes this usage simpler.  Please do that instead.

thanks,

greg k-h


Re: [PATCH] soundwire: intel: move to auxiliary bus

2021-03-22 Thread Vinod Koul
On 23-03-21, 08:43, Bard Liao wrote:
> From: Pierre-Louis Bossart 
> 
> Now that the auxiliary_bus exists, there's no reason to use platform
> devices as children of a PCI device any longer.
> 
> This patch refactors the code by extending a basic auxiliary device
> with Intel link-specific structures that need to be passed between
> controller and link levels. This refactoring is much cleaner with no
> need for cross-pointers between device and link structures.
> 
> Note that the auxiliary bus API has separate init and add steps, which
> requires more attention in the error unwinding paths. The main loop
> needs to deal with kfree() and auxiliary_device_uninit() for the
> current iteration before jumping to the common label which releases
> everything allocated in prior iterations.
> 
> Signed-off-by: Pierre-Louis Bossart 
> Reviewed-by: Guennadi Liakhovetski 
> Reviewed-by: Ranjani Sridharan 
> Signed-off-by: Bard Liao 
> ---
>  drivers/soundwire/Kconfig   |   1 +
>  drivers/soundwire/intel.c   |  52 
>  drivers/soundwire/intel.h   |  14 +-
>  drivers/soundwire/intel_init.c  | 190 +++-
>  include/linux/soundwire/sdw_intel.h |   6 +-
>  5 files changed, 175 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
> index 016e74230bb7..2b7795233282 100644
> --- a/drivers/soundwire/Kconfig
> +++ b/drivers/soundwire/Kconfig
> @@ -25,6 +25,7 @@ config SOUNDWIRE_INTEL
>   tristate "Intel SoundWire Master driver"
>   select SOUNDWIRE_CADENCE
>   select SOUNDWIRE_GENERIC_ALLOCATION
> + select AUXILIARY_BUS
>   depends on ACPI && SND_SOC
>   help
> SoundWire Intel Master driver.
> diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
> index d2254ee2fee2..039a101982c9 100644
> --- a/drivers/soundwire/intel.c
> +++ b/drivers/soundwire/intel.c
> @@ -11,7 +11,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1331,9 +1331,10 @@ static int intel_init(struct sdw_intel *sdw)
>  /*
>   * probe and init
>   */
> -static int intel_master_probe(struct platform_device *pdev)
> +static int intel_link_probe(struct auxiliary_device *auxdev, const struct 
> auxiliary_device_id *id)
>  {
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
> + struct sdw_intel_link_dev *ldev = 
> auxiliary_dev_to_sdw_intel_link_dev(auxdev);

Do we need another abstractions for resources here, why not aux dev
creation set the resources required and we skip this step...

>   struct sdw_intel *sdw;
>   struct sdw_cdns *cdns;
>   struct sdw_bus *bus;
> @@ -1346,14 +1347,14 @@ static int intel_master_probe(struct platform_device 
> *pdev)
>   cdns = &sdw->cdns;
>   bus = &cdns->bus;
>  
> - sdw->instance = pdev->id;
> - sdw->link_res = dev_get_platdata(dev);
> + sdw->instance = auxdev->id;

so auxdev has id and still we pass id as argument :( Not sure if folks
can fix this now

> + sdw->link_res = &ldev->link_res;
>   cdns->dev = dev;
>   cdns->registers = sdw->link_res->registers;
>   cdns->instance = sdw->instance;
>   cdns->msg_count = 0;
>  
> - bus->link_id = pdev->id;
> + bus->link_id = auxdev->id;
>  
>   sdw_cdns_probe(cdns);
>  
> @@ -1386,10 +1387,10 @@ static int intel_master_probe(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> -int intel_master_startup(struct platform_device *pdev)
> +int intel_link_startup(struct auxiliary_device *auxdev)
>  {
>   struct sdw_cdns_stream_config config;
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
>   struct sdw_cdns *cdns = dev_get_drvdata(dev);
>   struct sdw_intel *sdw = cdns_to_intel(cdns);
>   struct sdw_bus *bus = &cdns->bus;
> @@ -1526,9 +1527,9 @@ int intel_master_startup(struct platform_device *pdev)
>   return ret;
>  }
>  
> -static int intel_master_remove(struct platform_device *pdev)
> +static void intel_link_remove(struct auxiliary_device *auxdev)
>  {
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
>   struct sdw_cdns *cdns = dev_get_drvdata(dev);
>   struct sdw_intel *sdw = cdns_to_intel(cdns);
>   struct sdw_bus *bus = &cdns->bus;
> @@ -1544,19 +1545,17 @@ static int intel_master_remove(struct platform_device 
> *pdev)
>   snd_soc_unregister_component(dev);
>   }
>   sdw_bus_master_delete(bus);
> -
> - return 0;
>  }
>  
> -int intel_master_process_wakeen_event(struct platform_device *pdev)
> +int intel_link_process_wakeen_event(struct auxiliary_device *auxdev)
>  {
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
>   struct sdw_intel *sdw;
>   struct sdw_bus *bus;
>   void __iomem *shim;
>   u16 wake_sts;
>  
> - sdw = platform_get_drvdata(pdev);
> + sdw = dev_get_drvdata(dev);

N