From: Daniel Mack <daniel@zonque.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
"marek.belisko" <marek.belisko@gmail.com>,
Matus Ujhelyi <ujhelyi.m@gmail.com>
Subject: Re: [PATCH 1/3] net: phylib: add adjust_state callback to phy device
Date: Thu, 05 Jun 2014 23:39:15 +0200 [thread overview]
Message-ID: <5390E383.50805@zonque.org> (raw)
In-Reply-To: <CAGVrzcbas_A=prheBFeczuC+gRyWdACVrAHY0_zhy0N+fePTWQ@mail.gmail.com>
Hi Florian,
On 06/05/2014 08:12 PM, Florian Fainelli wrote:
> 2014-06-05 0:14 GMT-07:00 Daniel Mack <daniel@zonque.org>:
>>> This sounds potentially dangerous if misused, PHY drivers would
>>> basically be allowed to do arbitrary link state changes based on their
>>> custom needs.
>>
>> Yes, and this is basically what my quirk handler does. It takes action
>> when the link goes down (PHY_NOLINK), as we unfortunately need to reset
>> the chip every time this happens.
>
> In fact, the callback name is sort of a misnomer here, as you are not
> really adjusting the PHY device state here, you are reading from it to
> do something about the PHY device based on this state.
>
> Could you rename it to "state_notify" for instance to make it clear
> that this must absolutely be a read-only operation and the PHY driver
> is by no means allow to mess with the PHY device structure at all?
> Constifying the phy_device argument here would not really help
> unfortunately, and providing you with just the 'state' as a RO
> argument would not help either since you need to access the PHY
> device...
Sure, I can rename it, no problem.
> I was thinking about having a notifier callchain here that would
> execute synchronously and in the same context as your proposed
> adjust_link() callback, although that might be be too heavy weighted
> for basically just one notified callback.
Plus, it wouldn't really solve the issue you described above, right?
I'll resend after -rc1 is out, with the changed name for the callback.
Again, thanks!
Daniel
next prev parent reply other threads:[~2014-06-05 21:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 9:00 [PATCH 0/3] Handle stuck TX queue bug in AT8030 PHY Daniel Mack
2014-06-04 9:00 ` [PATCH 1/3] net: phylib: add adjust_state callback to phy device Daniel Mack
2014-06-05 5:11 ` Florian Fainelli
2014-06-05 7:14 ` Daniel Mack
2014-06-05 18:12 ` Florian Fainelli
2014-06-05 21:39 ` Daniel Mack [this message]
2014-06-04 9:00 ` [PATCH 2/3] net: phy: at803x: use #defines for supported PHY ids Daniel Mack
2014-06-04 9:00 ` [PATCH 3/3] net: phy: at803x: Add support for hardware reset Daniel Mack
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=5390E383.50805@zonque.org \
--to=daniel@zonque.org \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=marek.belisko@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=ujhelyi.m@gmail.com \
/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.