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: <AANLkTilZ5jJo8spBdfXBqZmTRfNlq4PQJI5wsn2lBj9Z@mail.gmail.com>
Date:	Wed, 2 Jun 2010 18:10:19 +0800
From:	Sonic Zhang <sonic.adi@...il.com>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	uclinux-dist-devel <uclinux-dist-devel@...ckfin.uclinux.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Uclinux-dist-devel] [PATCH v2] regulator: new drivers for AD5398 
	and AD5821

On Wed, Jun 2, 2010 at 5:36 PM, Mike Frysinger <vapier.adi@...il.com> wrote:
> On Wed, Jun 2, 2010 at 05:29, Sonic Zhang wrote:
>> On Wed, Jun 2, 2010 at 5:02 PM, Mike Frysinger wrote:
>>> On Wed, Jun 2, 2010 at 04:51, sonic zhang wrote:
>>>> The AD5398 and AD5821 are single 10-bit DAC with 120 mA output current
>>>> sink capability. They feature an internal reference and operates from
>>>> a single 2.7 V to 5.5 V supply.
>>>>
>>>> This driver supports both the AD5398 and the AD5821.  It adapts into the
>>>> voltage and current framework.
>>>>
>>>>
>>>> Signed-off-by: Sonic Zhang <sonic.zhang@...log.com>
>>>
>>> the "From:" doesnt match your s-o-b tag ...
>>
>> Does this need to be matched? I prefer to discuss via gmail account
>> while keep company email in the patch owner information.
>
> so set the From: in the body as the first line like git-send-email does it:
> From: <author info>
>
> <commit message>
>
> <other tags>
> ---
>  <diffstat>
> ..........
>
>>>> +static const struct ad5398_current_data_format ad5398_df = {10, 4};
>>>> +static const struct ad5398_current_data_format ad5821_df = {10, 4};
>>>> +
>>>> +static const struct i2c_device_id ad5398_id[] = {
>>>> +       { "ad5398", (kernel_ulong_t)&ad5398_df },
>>>> +       { "ad5821", (kernel_ulong_t)&ad5821_df },
>>>> +       { }
>>>> +};
>>>
>>> do you really need sep storage for these _df vars ?
>>
>> Yes, this makes probe code simpler.
>
> how does it make any difference to the probe code what each id is
> pointing to ?  it isnt comparing the private data pointers to any
> other storage pointers.
>
> from what i can see, this should give the same exact behavior:
> static const struct ad5398_current_data_format df_10_4 = {10, 4};
> static const struct i2c_device_id ad5398_id[] = {
>       { "ad5398", (kernel_ulong_t)&df_10_4 },
>       { "ad5821", (kernel_ulong_t)&df_10_4 },
> -mike
>

Yes, the behavior is the same for ad5398 and ad5821. But, if more
chips are enabled in this driver, they may differ.
This line is used as an example for future chips.

Sonic
--
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