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]
Message-ID: <CAD=FV=U51f+sL_hSGdzusthC3OEgv3kbQ9t1G28JRgXueFYQEQ@mail.gmail.com>
Date:	Mon, 16 Jun 2014 21:07:44 -0700
From:	Doug Anderson <dianders@...gle.com>
To:	Tushar Behera <trblinux@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mike Turquette <mturquette@...aro.org>,
	Tomasz Figa <t.figa@...sung.com>,
	Russell King <linux@....linux.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Kevin Hilman <khilman@...aro.org>,
	Mark Brown <broonie@...aro.org>
Subject: Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

Tushar,

On Mon, Jun 16, 2014 at 8:36 PM, Tushar Behera <trblinux@...il.com> wrote:
> On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson <dianders@...gle.com> wrote:
>> Tushar,
>>
>> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@...il.com> wrote:
>>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>>> Tushar,
>>>>
>>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@...sung.com> wrote:
>>>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>>
>>>> If you want to be a stickler about it, peach-pi actually has a
>>>> max98091.  That requires code changes to the i2c driver, though.
>>>> ...and unfortunately listing two compatible strings for i2c devices is
>>>> broken.  :(
>>>>
>>> Hi Doug,
>>>
>>> You are right. I checked the boot logs, the detected codec type is
>>> MAX98091. Since both these CODECs are supported through a single driver
>>> and the detection of chip is done during runtime, I would suggest we go
>>> ahead with "max98090" compatible string. I will update the commit
>>> message accordingly.
>>>
>>> Does that sound okay to you?
>>
>> As per my understanding you shouldn't do this.  You should have two patches:
>>
>> 1. Add "max98091".  You could simply post Wonjoon's patch from
>> <https://chromium-review.googlesource.com/184091>
>>
>> 2. Change the device tree to refer to "max98091"
>>
>> The argument that the "current kernel driver has a single driver" is
>> an argument that you're not supposed to make for device tree.  The
>> same device tree is supposed to work for U-Boot, BSD, or any other
>> platform.  On those platforms it might not be a shared driver.
>>
>
> My argument is that the device type is getting detected during
> runtime, hence there is no need to differentiate between these two.
>
> But if you prefer that way, I will repost.

Yes please.

True that it is possible to detect 98090 vs. 98091.  ...but it's also
possible to detect exynos5250 vs. exynos5420 vs. exynos5800.  ...yet
they have different compatible strings.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ