On Tue, Mar 07 2017, Baolin Wang wrote:
> On 3 March 2017 at 10:23, NeilBrown wrote:
>
>>
>> I understand your reluctance to change drivers that you cannot test.
>> An alternative it do change all the
>> atomic_notifier_call_chain(.*notifier,
>> calls that
o we add one pointer of extcon device into
> usb phy structure, and some other helper functions to register extcon.
>
> Suggested-by: NeilBrown
> Signed-off-by: Baolin Wang
> ---
> Changes since v1:
> - Fix build errors with random config.
> ---
> drivers/usb/phy/K
e reported through the extcon.
The other is information gathered during the USB protocol handshake.
For USB2, this is the requested current of the profile that the host
activates. This should be reported though the USB gadget device.
I don't know how USB3 and/or type-C work
On Wed, Dec 21 2016, Baolin Wang wrote:
> On 21 December 2016 at 11:48, NeilBrown wrote:
>> On Wed, Dec 21 2016, Baolin Wang wrote:
>>
>>> Hi,
>>>
>>> On 21 December 2016 at 06:07, NeilBrown wrote:
>>>> On Tue, Dec 20 2016, Baolin Wang wro
On Wed, Dec 21 2016, Baolin Wang wrote:
> Hi,
>
> On 21 December 2016 at 06:07, NeilBrown wrote:
>> On Tue, Dec 20 2016, Baolin Wang wrote:
>>
>>> Hi Neil,
>>>
>>> On 3 November 2016 at 09:25, NeilBrown wrote:
>>>> On Tue, No
On Tue, Dec 20 2016, Baolin Wang wrote:
> Hi Neil,
>
> On 3 November 2016 at 09:25, NeilBrown wrote:
>> On Tue, Nov 01 2016, Baolin Wang wrote:
>>
>>
>>>> So I won't be responding on this topic any further until I see a genuine
>>>> at
On Sat, Nov 26 2016, Mark Brown wrote:
> [ Unknown signature status ]
> On Tue, Nov 22, 2016 at 09:40:07AM +1100, NeilBrown wrote:
>
>> I agree that the question of where the responsibility for information
>> aggregation lies is open for discussion. If fact all details on
On Tue, Nov 22 2016, Mark Brown wrote:
> [ Unknown signature status ]
> On Thu, Nov 17, 2016 at 05:46:13PM +1100, NeilBrown wrote:
>> On Thu, Nov 17 2016, Mark Brown wrote:
>
>> > To me that's pretty much what's being done here, the code just happens
>> &
On Thu, Nov 17 2016, Mark Brown wrote:
> [ Unknown signature status ]
> On Tue, Nov 15, 2016 at 08:35:13AM +1100, NeilBrown wrote:
>> On Mon, Nov 14 2016, Mark Brown wrote:
>
>> > Conflating the two seems like the whole point here. We're looking for
>> >
On Mon, Nov 14 2016, Mark Brown wrote:
> On Mon, Nov 14, 2016 at 03:21:13PM +1100, NeilBrown wrote:
>> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> > Fourth, we need integrate all charger plugin/out
>> > event in one framework, not from extcon, maybe type-c in futur
On Thu, Nov 10 2016, Baolin Wang wrote:
> Hi
>
> On 8 November 2016 at 04:36, NeilBrown wrote:
>> On Mon, Nov 07 2016, Baolin Wang wrote:
>>
>>> On 3 November 2016 at 09:25, NeilBrown wrote:
>>>> On Tue, Nov 01 2016, Baolin Wang wrote:
>>>
On Tue, Nov 08 2016, Peter Chen wrote:
> On Thu, Nov 03, 2016 at 12:25:42PM +1100, NeilBrown wrote:
>>
>>
>>
>> 2/ Change all usb phys to register an extcon and to send appropriate
>>notifications. Many already do, but I don't think it is universal
On Mon, Nov 07 2016, Baolin Wang wrote:
> On 3 November 2016 at 09:25, NeilBrown wrote:
>> On Tue, Nov 01 2016, Baolin Wang wrote:
>
> I agree with your most opinions, but these are optimization.
I see them as bug fixes, no
of currents are expected and calls the
call-back function with those details.
6/ Any battery charger that needs to know the available current can now
call register_power_client() and get the information delivered.
NeilBrown
signature.asc
Description: PGP signature
t of patches to guess how
something is supposed to work. It needs to be clearly and
unambiguously documented.
However, I'm very quickly losing interest in this whole debate, partly
because it misses a key point. As I have said, I strongly feel that
resolving the current inconsistencies in the use of
usb_register_notifier() is an important preliminary to resolve this
issue, as that is *already* sometimes used to communication available
current.
So I won't be responding on this topic any further until I see a genuine
attempt to understand and resolve the inconsistencies with
usb_register_notifier().
NeilBrown
signature.asc
Description: PGP signature
er_detect() too, which seems
identical to ->get_charger_type(). There is no documentation
explaining the difference.
5/ There is no convincing example usage of this framework.
wm8931x_power.c just scratches the surface.
If it is so good, it should be easy to convert a lot of other
drivers over to it. If you did that it would be much easier
to see how it works and what the strengths/weaknesses were.
NeilBrown
signature.asc
Description: PGP signature
first cleaning up what is there.
Also: resolve the question of whether it could ever make sense to have
more than one "usb_charger" in a system. If it doesn't, make it an
obvious singleton. If it does, make it clear how the correct
usb_charger is chosen.
Also: think very carefully before exposing any details through sysfs.
Some of the details are already visible, either in sys/class/extcon
or sys/class/power_supply. Don't duplicate without good reason.
NeilBrown
>
> --
> balbi
signature.asc
Description: PGP signature
o ensure that voltage doesn't drop
unduly, then I agree with your assertion that it just needs to be told
the upper limit.
I hope you'll agree that other drivers might need to know the lower
limit, so reporting both to all drivers is sensible.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
On Wed, Sep 14 2016, Mark Brown wrote:
> [ Unknown signature status ]
> On Tue, Sep 13, 2016 at 10:00:28AM +0200, NeilBrown wrote:
>> On Mon, Sep 12 2016, Mark Brown wrote:
>
>> > That's not actually 100% clear to me - for what the wm831x is doing it
>> >
On Mon, Sep 12 2016, Mark Brown wrote:
> [ Unknown signature status ]
> On Mon, Sep 12, 2016 at 03:27:18PM +0200, NeilBrown wrote:
>> On Mon, Sep 12 2016, Mark Brown wrote:
>
>> > It's no worse than any other board file situation - if someone has that
>> &g
On Mon, Sep 12 2016, Mark Brown wrote:
> [ Unknown signature status ]
> On Sat, Sep 10, 2016 at 07:57:26AM +1000, NeilBrown wrote:
>> On Fri, Sep 09 2016, Mark Brown wrote:
>
>> > The wm831x driver in the patch series is an example of such hardware -
>> > it is
On Fri, Sep 09 2016, Mark Brown wrote:
> [ Unknown signature status ]
> On Fri, Sep 09, 2016 at 09:13:31AM +1000, NeilBrown wrote:
>
>> Conceptually, the PHY is separate from the power manager and a solution
>> which recognises that will be more universal.
>
> The
_draw.
Your patch passes that to usb_charger_set_cur_limit_by_type()
which calls __usb_charger_set_cur_limit_by_type() which will set the
cur_limit for whichever type uchger->type currently is.
So when it is not relevant, your code *does* set some current limit.
NeilBrown
signature.asc
Description: PGP signature
On Thu, Sep 08 2016, Baolin Wang wrote:
> On 8 September 2016 at 15:31, NeilBrown wrote:
>> On Thu, Sep 08 2016, Baolin Wang wrote:
>>>
>>> Now the usb charger will not get charger type from 'extcon' subsystem,
>>> we get the charger type from
On Thu, Sep 08 2016, Baolin Wang wrote:
> Hi Neil,
>
> On 6 September 2016 at 13:40, NeilBrown wrote:
>> On Mon, Aug 29 2016, Baolin Wang wrote:
>>
>>> Hi Felipe,
>>>
>>> On 11 August 2016 at 11:14, Baolin Wang wrote:
>>>> Hi Fel
B charging framework should communicate the MIN and MAX as
specified in the standard, and allow the PMIC to use that information as
appropriate.
A library routine to support the incremental increase in current drain
would probably be appreciated by PMIC driver writers.
A more details discussion of
On Tue, 14 Apr 2015 08:50:01 +0200 Olivier Sobrie wrote:
> Hello Neil,
>
> On Tue, Apr 14, 2015 at 11:03:03AM +1000, NeilBrown wrote:
> > On Tue, 14 Apr 2015 09:36:34 +1000 NeilBrown wrote:
> >
> > >
> > >
> > > Prior to
> > > comm
On Tue, 14 Apr 2015 09:36:34 +1000 NeilBrown wrote:
>
>
> Prior to
> commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
> hso: fix crash when device disappears while serial port is open
>
> hso_serial_open would always kref_get(&serial->parent->ref) before
.@vger.kernel.org (v4.0)
Cc: Olivier Sobrie
Signed-off-by: NeilBrown
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 75befc1bd816..6848fc903340 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1299,6 +1299,7 @@ static int hso_serial_open(struct tty_struct *
From: NeilBrown
twl4030_charger currently finds the associated phy
using usb_get_phy() which will return the first USB2 phy.
If your platform has multiple such phys (as mine does),
this is not reliable (and reliably fails on the GTA04).
Change to use devm_usb_get_phy_by_node(), having found the
merge window, though should it go through usb/phy or
power???
Thanks,
NeilBrown
---
NeilBrown (2):
usb: phy: Add interface to get phy give of device_node.
twl4030_charger: find associated phy by more reliable means.
.../devicetree/bindings/power/twl-charger.txt |
From: NeilBrown
Split the "get phy from device_node" functionality out of
"get phy by phandle" so it can be used directly.
This is useful when a battery-charger is intimately associated with a
particular phy but handled by a separate driver. The charger
can find the
On Wed, 25 Feb 2015 22:13:51 +0100 Sebastian Reichel wrote:
> Hi Neil,
>
> On Tue, Feb 24, 2015 at 03:01:29PM +1100, NeilBrown wrote:
> > twl4030_charger currently finds the associated phy
> > using usb_get_phy() which will return the first USB2 phy.
> > If your plat
for an appropriately named sibling in
device-tree.
This makes usb-charging dependent on correct device-tree
configuration.
Signed-off-by: NeilBrown
---
drivers/power/twl4030_charger.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/power
a new interface to allow a phy to be found given a
device node, and then use that interface in twl4030_charger so that
it finds its sibling in the devicetree, and gets the phy associated
with that.
Thanks,
NeilBrown
---
NeilBrown (2):
usb: phy: Add interface to get phy give of device_node
ibling relationships
without the need for a redundant declaration in the devicetree
description.
As a peripheral that gets a phy will often want to register a
notifier block, and de-register it later, that functionality
is included so the de-registration is automatic.
Signed-off-by: NeilBrown
---
d
On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman wrote:
> NeilBrown writes:
>
> > On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg
> > wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Neil,
>
> On 01/21/13 11:28, NeilBrown wrote:
> >
> >
> > The standard suspend sequence involves
MAP3 system with off_mode enabled will find
the musb port non-functional after suspend/resume. With the patch it
works perfectly.
Signed-off-by: NeilBrown
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index fd34867..b6ccc02 100644
--- a/drivers/usb/musb/musb_core
On Mon, 13 Aug 2012 17:32:34 +0300 Felipe Balbi wrote:
> Hi,
>
> On Mon, Aug 13, 2012 at 12:34:53PM +1000, NeilBrown wrote:
> > On Thu, 9 Aug 2012 14:15:51 +0300 Felipe Balbi wrote:
> >
> >
> > > hehe, that's nasty. Please send a patch converting to a
On Thu, 9 Aug 2012 14:15:51 +0300 Felipe Balbi wrote:
> hehe, that's nasty. Please send a patch converting to a try count and a
> udelay_range(), or something.
>
how's this?
Thanks,
NeilBrown
From: NeilBrown
Date: Mon, 13 Aug 2012 12:32:58 +1000
Subject: [PATCH] o
Hi Felipe,
have you had a chance to look at this problem in omap2430_mbus_set_vbus yet?
Are you the person responsible?
thanks,
NeilBrown
On Mon, 9 Jul 2012 01:32:33 -0700 Tony Lindgren wrote:
> * NeilBrown [120706 15:44]:
> >
> > Hello `./scripts/get_maintainer.pl -f d
sing the noise that triggers the musb issue.
I can send a patch which add a loop count if you like, but I suspect you can
come up with a much better approach.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
43 matches
Mail list logo
