linux-kernel - Re: [PATCH v2 5/5] ASoC: adau17x1: Support platform data via DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Feb 2016 09:58:29 +0100
From:	Andreas Irestål <andreas.irestal@...s.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Andreas Irestål <andire@...s.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	<devicetree@...r.kernel.org>, <alsa-devel@...a-project.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 5/5] ASoC: adau17x1: Support platform data via DT

On Tue, Feb 16, 2016 at 02:42:02PM +0100, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 13:56:45 Andreas Irestål wrote:
> > Currently, it is only possible to configure HW-specific options to the
> > adau17x1 codecs by providing a platform data struct. With this patch,
> > it is possible to provide the same data via DT instead.
> > 
> > Signed-off-by: Andreas Irestål <andire@...s.com>
> > ---
> >  .../devicetree/bindings/sound/adi,adau17x1.txt     |  31 +++++
> >  include/dt-bindings/sound/adau17x1.h               |  14 +++
> >  sound/soc/codecs/adau1761.c                        | 127 +++++++++++++++++++++
> >  sound/soc/codecs/adau1781.c                        |  48 ++++++++
> >  4 files changed, 220 insertions(+)
> >  create mode 100644 include/dt-bindings/sound/adau17x1.h
> 
> > +		of_pdata = devm_kzalloc(dev, sizeof(*of_pdata), GFP_KERNEL);
> > +		if (!of_pdata)
> > +			return -ENOMEM;
> > +		adau1781_pdata_from_of(dev, of_pdata);
> > +		dev->platform_data = of_pdata;
> 
> and here I'd try to avoid the dynamic allocation and just add the fields to the
> driver private structure. You can copy the information from the platform
> data in the 'else' path.

Since the driver private structure is shared between two different
codecs, the platform_data struct can be of 2 different types, but I
guess it should be OK to have two fields or a
union in the private struct.

I was thinking about this too but chose the approach above since providing
platform_data is optional. However, I could add some default values and
submit again.

Thanks a lot for the feedback.
/Andreas

> 
> 	Arnd