Re: [PATCH v1] ASoC: Intel: Skylake: Switch to modern UUID API

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
	Takashi Iwai <tiwai@suse.com>,
	Jie Yang <yang.jie@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Vinod Koul <vkoul@kernel.org>, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v1] ASoC: Intel: Skylake: Switch to modern UUID API
Date: Tue, 25 Jun 2019 20:15:19 +0300	[thread overview]
Message-ID: <20190625171519.GE9224@smile.fi.intel.com> (raw)
In-Reply-To: <20190624105157.18a348ce@xxx>

On Mon, Jun 24, 2019 at 10:51:57AM +0200, Amadeusz Sławiński wrote:
> On Wed, 19 Jun 2019 18:02:13 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

Thanks for review, though this one will be part of upstream.

> > -struct UUID {
> > -	u8 id[16];
> > -};
> > -

> >  struct adsp_module_entry {
> >  	u32 struct_id;
> >  	u8  name[8];
> > -	struct UUID uuid;
> > +	u8  uuid[16];
> 
> guid_t uuid;

This seems a part of ABI.
ABI doesn't and shouldn't know anything about kernel internal types.

If I'm mistaken, one, who knows better the area, can submit a followup.

> >  struct skl_module_inst_id {
> > -	uuid_le mod_uuid;
> > +	guid_t mod_uuid;
> >  	int module_id;
> >  	u32 instance_id;
> >  	int pvt_id;
> > @@ -360,7 +360,7 @@ struct skl_module_res {
> >  };
> >  
> >  struct skl_module {
> > -	uuid_le uuid;
> > +	guid_t uuid;
> >  	u8 loadable;
> >  	u8 input_pin_type;
> >  	u8 output_pin_type;
> 
> 
> I would also add:
> 
> struct skl_module_cfg {
> -	u8 guid[16];
> +	guid_t uuid;
> 
> should get rid of few casts above. Overall I would expect no casts at
> all.

See above.

Nevertheless, there is an idea to add some wrappers to UUID framework to cover
cases when raw buffer is copied to UUID type or back and accompanying API.

At least btrfs expects such.

I will try to keep this in mind and convert ASoC stuff to the new API when it
appears in the upstream.

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel