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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTilIweGx1NXLiTuRphex1RMk9DF3Vdva5F-6JDKl@mail.gmail.com>
Date:	Wed, 2 Jun 2010 05:36:52 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Sonic Zhang <sonic.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 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
--
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