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:	Thu, 10 Apr 2014 15:51:54 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	David Cohen <david.a.cohen@...ux.intel.com>
CC:	wim@...ana.be, tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-watchdog@...r.kernel.org, gnomes@...rguk.ukuu.org.uk
Subject: Re: [PATCH 2/2] x86: intel-mid: add watchdog platform code for Merrifield

On 04/10/2014 02:23 PM, David Cohen wrote:
> On Thu, Apr 10, 2014 at 01:35:36PM -0700, Guenter Roeck wrote:
>> On Thu, Apr 10, 2014 at 12:30:10PM -0700, David Cohen wrote:
>>> On Thu, Apr 10, 2014 at 12:15:23PM -0700, Guenter Roeck wrote:
>>>> On Tue, Apr 08, 2014 at 01:59:04PM -0700, David Cohen wrote:
>>>>> This patch adds platform code for Intel Merrifield.
>>>>> Since the watchdog is not part of SFI table, we have no other option but
>>>>> to manually register watchdog's platform device (argh!).
>>>>>
>>>>> Signed-off-by: David Cohen <david.a.cohen@...ux.intel.com>
>>>>> ---
>>>>
>>>> Does it really make sense to have this as separate patch ?
>>>>
>>>> It is quite common for watchdog (and many other) drivers to
>>>> register the driver and instantiate the device. I think it
>>>> would be better and more consistent to have both patches
>>>> merged into one.
>>>
>>> Are you talking about to merge them without code changes or make the
>>> driver responsible for the device enumeration (by make the driver to
>>> allocate the device)?
>>>
>>> If it's a simple merge, I'd say I don't like to mix drivers and arch
>>> patches.
>>>
>>> If we're talking about moving the device registration to driver, I
>>> strongly disagree it would be better and more consistent. The way I sent
>>> the driver makes it less dependent of how the enumeration happens.
>>> If this device is added to SFI table, the driver would need no change.
>>>
>> I don't see why that would be a problem. Guess we'll have to agree
>> to disagree.
>
> Sounds fine :)
> If you're not too much against keeping the way it is, I'd like to send
> the v2 with 2 patches again.
>

Not my decision to make. I am not the watchdog maintainer.

Guenter


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