All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Damien Riegel <damien.riegel@savoirfairelinux.com>,
	linux-watchdog@vger.kernel.org, Wim Van Sebroeck <wim@iguana.be>,
	Pratyush Anand <panand@redhat.com>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] watchdog: Create watchdog device in watchdog_dev.c
Date: Tue, 22 Dec 2015 08:15:41 -0800	[thread overview]
Message-ID: <5679772D.8030806@roeck-us.net> (raw)
In-Reply-To: <20151222153337.GB6164@localhost>

On 12/22/2015 07:33 AM, Damien Riegel wrote:
> On Mon, Dec 21, 2015 at 03:28:39PM -0800, Guenter Roeck wrote:
>> On 12/21/2015 09:31 AM, Damien Riegel wrote:
>>> On Sun, Dec 20, 2015 at 01:04:59PM -0800, Guenter Roeck wrote:
>>>> The watchdog character device is currently created in watchdog_dev.c,
>>>> and the watchdog device in watchdog_core.c. This results in
>>>> cross-dependencies, since device creation needs to know the watchdog
>>>> character device number as well as the watchdog class, both of which
>>>> reside in watchdog_dev.c.
>>>>
>>>> Create the watchdog device in watchdog_dev.c to simplify the code.
>>>>
>>>> Inspired by earlier patch set from Damien Riegel.
>>>
>>> Hi Guenter,
>>>
>>> The main purpose of my patch was to inverse the device creation and the
>>> cdev registration to avoid a racy situation, bu you have dropped that in
>>> this version. Is there a reason for that?
>>>
>> Every other driver I looked at does it in the same order (cdev first, device
>> second). I don't really know if doing it differently has any undesired
>> side effect, so I wanted to play safe.
>>
>> It would help a lot if someone listening to this exchange can confirm
>> that it is ok to create the device first, followed by the character device.
>
> The issue is that some drivers use watchdog_device->dev in their
> watchdog_ops functions. With a quick grep, I could spot 3 examples:
>
>   - bcm2835_wdt_stop in bcm2835_wdt.c
>   - gpio_wdt_hwping in gpio_wdt.c
>   - a21_wdt_set_timeout in mena21_wdt.c
>
> Maybe we should simply fix these drivers and keep watchdog_device->dev
> for core internal usage?
>

Yes, I have been thinking about that - essentially move the ->dev pointer
to the internal data structure and either use pr_ functions in those drivers,
or save a pointer to the platform device (if available) and use it.

I think I'll start working on a follow-up patch set to do just that.

Guenter


  reply	other threads:[~2015-12-22 16:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-20 21:04 [PATCH 0/5] watchdog: Replace driver based refcounting Guenter Roeck
2015-12-20 21:04 ` [PATCH 1/5] watchdog: Create watchdog device in watchdog_dev.c Guenter Roeck
2015-12-21 17:31   ` Damien Riegel
2015-12-21 23:28     ` Guenter Roeck
2015-12-22 15:33       ` Damien Riegel
2015-12-22 16:15         ` Guenter Roeck [this message]
2015-12-20 21:05 ` [PATCH 2/5] watchdog: Separate and maintain variables based on variable lifetime Guenter Roeck
2015-12-21 17:28   ` Damien Riegel
2015-12-21 22:50     ` Tomas Winkler
2015-12-21 23:36     ` Tomas Winkler
2015-12-22  1:40       ` Guenter Roeck
2015-12-22 22:05         ` Tomas Winkler
2015-12-23  0:32           ` Guenter Roeck
2015-12-22  1:10     ` Guenter Roeck
2015-12-22 16:09       ` Damien Riegel
2015-12-22 16:22         ` Guenter Roeck
2015-12-22 19:28           ` Damien Riegel
2015-12-22 19:34             ` Guenter Roeck
2015-12-20 21:05 ` [PATCH 3/5] watchdog: da9052_wdt: Drop reference counting Guenter Roeck
2015-12-20 21:05 ` [PATCH 4/5] watchdog: da9055_wdt: " Guenter Roeck
2015-12-20 21:05 ` [PATCH 5/5] hwmon: (sch56xx) Drop watchdog driver data reference count callbacks Guenter Roeck
2015-12-21 10:37   ` Hans de Goede
2015-12-21 13:21     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5679772D.8030806@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=damien.riegel@savoirfairelinux.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=panand@redhat.com \
    --cc=wim@iguana.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.