Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
>> Pavel Machek  writes:
>> > On Mon 2016-04-18 13:55:17, Felipe Balbi wrote:
>> >> 
>> >> Hi,
>> >> 
>> >> Felipe Balbi  writes:
>> >> >> But cellphone user knows what he connected his charger to, and that's
>> >> >> why it is useful to be able to lower the current. Even when you said
>> >> >> "less is just stupid" I demonstrated it is not, at least in case when
>> >> 
>> >> and btw, you haven't demonstrated anything. You merely stated that it
>> >> isn't without references or numbers, or any source of trustworthy
>> >> information. I'm not really into 'believing'.
>> >
>> > You are not really into reading, either, it seems. Or into the
>> > electronics. Or into physics.
>> >
>> > You seem to understand that charging li-ion from li-ion produces too
>> > much heat. (And yes, it does, DC-DC convertors are not 100%
>> > effective). Converting energy into heat is not a good idea.
>> >
>> > If you need numbers or references to understand basic physics, you'll
>> > need to google it yourself, I'm afraid. 
>> 
>> still doesn't change the fact that you haven't demonstrated anything. If
>> you can't be helpful and/or constructive, you may also go away and use
>> whatever unsafe setup you want to use.
>
> So you still claim that it is "stupid" to charge at anything lower
> than maximum allowed current?
>
> Even after I described the example with device running off power bank
> on a train? Would you explain your reasoning?

you still haven't produced evidence of your claim. Claiming without
evidence has virtually no meaning. Anyway, I'll just google a bit later
seen as if you're just unwilling to produce evidence of your claims.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
>> > Of course, we may do something sensible by default. But manual
>> > controls should still be present. You called them "stupid" but they
>> > are not.
>> >
>> > Note that just because you detected wall charger does not even mean
>> > you are connected to wall charger. See the link below.
>> 
>> that's a horrible product. So what ? If you want to use that, be my
>> guest. Just, again, don't ask for support when things start falling
>> apart ;-)
>
> So you have USB spec? So what? There are many such products out there,
> and I have at least two such cables here.
>
> They did not cause end of the world, yet, and they are actually very
> useful.

they are also breaking safety requirements and, as I already said, are
potentially dangerous to the user.

>> >> >> still unsafe. If you really wanna do that, you're welcome to removing
>> >> >> safety margins from your own kernel, but we're definitely not going to
>> >> >> ship this to millions of users.
>> >> >
>> >> > Not more unsafe than loading wall chargers with "lets see how much we
>> >> > can get out of it" algorithm. Plus actually required to charge your
>> >> 
>> >> it actually _is_ more unsafe. You could burn mother boards with that. If
>> >> host tells you it only has 100mA power budget left, why are you trying
>> >> to get more ?
>> >
>> > No, you can't burn motherboard like that... You can force emergency
>> > shutdowns, which is also bad, but... There are many devices that break
>> > this aspect of USB protocol.
>> >
>> > https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the
>> 
>> we can't prevent people from coming up with bad devices/cables/whatever,
>> right ? But we can make sure that overcoming a 500mA power budget on a
>> USB 2.0 port will not be allowed.
>
> No, you can't, because you don't know if you are connected to USB 2.0
> port. (Because non-compliant cables exist).

yeah, we can't also protect car passenger from bad drivers, but we can
give them all a seat belt ;-)

>> >> > Unfortunately, there's more than one standard for detecting charger,
>> >> > so manual control will probably be required.
>> >> 
>> >> n900 never had manual control of anything. It was just using information
>> >> given by the battery IC, charger IC and twl4030 madc.
>> >
>> > Manual control of n900 charging is done by:
>> >
>> > echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit
>> 
>> yes, that's fine. And if you're connected to a dedicated charger (DCP)
>> which follows USB Battery Charger specification, we *know* that it
>> should, per the spec, source up to 2A, so this is fine.
>
> BTW have you ever seen such USB-compliant dedicated charger? I have
> more than 5 chargers here, and not one of them is 2A. (Most are .5A,
> some are 1A, one is 1.2A).

yeah, if it has the USB BC logo, it _must_ be compliant and full all
requirements of the USB BC spec.

>> However, if you're connected to SDP (regular PC port), which has a power
>> budget of 500mA per-port (meaning, that if you're behind a bus powered
>> hub, you can't even get 500mA), then this write() of yours should be
>> invalid. It should *not* be a successful write() as that creates an
>> unsafe and potentially dangerous scenario for the user.
>
> Yes, USB is "potentially dangerous", because noone follows the
> specs. Fortunately, everyone knows (except you?) that noone follows
> the specs, so the hardware can deal with that, and they include
> (poly?) fuses where neccessary.

heh :-)

>> > They already can go over the limit, for example using cable linked
>> > above. I have several such cables here. I also have various wall
>> 
>> people can use unsupported cable assemblies if they want, but you can't
>> expect kernel to support you.
>
> Then we won't have useful charging support in kernel.

oh no, we will. We just won't let users step outside of safety requirements.

>> > supplies that are not detected as a wall supply by N900. So I either
>> > have to remember and connect them with the "special" cable, or
>> > (easier) use the override above to get useful charging.
>> 
>> those supplies are not supported by N900. N900 was designed with USB
>> Battery Chaging specification in mind and Nokia is not around anymore to
>> give you SW updates. Sorry, but that's not the kernel's fault.
>> 
>> The point is the following: there are a handful of people who would
>> *know* how to fiddle with these limits, many would not. The vast
>> majority would not. And, considering this is something completely out of
>> spec, and, again, potentially dangerous to the user, we are not going to
>> support it.
>
> You speak about dangerous where little danger exist; number of
> non-compliant cables and USB devices is very high (take your power
> bank. Does it really limit to .5A when charging from computer?) and we
> should support them, not cry "dangerous" and force everyone to come
> with their own "solutions".

hehe, you're pretty 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

Hi!

> > Of course, we may do something sensible by default. But manual
> > controls should still be present. You called them "stupid" but they
> > are not.
> >
> > Note that just because you detected wall charger does not even mean
> > you are connected to wall charger. See the link below.
> 
> that's a horrible product. So what ? If you want to use that, be my
> guest. Just, again, don't ask for support when things start falling
> apart ;-)

So you have USB spec? So what? There are many such products out there,
and I have at least two such cables here.

They did not cause end of the world, yet, and they are actually very useful.

> >> >> still unsafe. If you really wanna do that, you're welcome to removing
> >> >> safety margins from your own kernel, but we're definitely not going to
> >> >> ship this to millions of users.
> >> >
> >> > Not more unsafe than loading wall chargers with "lets see how much we
> >> > can get out of it" algorithm. Plus actually required to charge your
> >> 
> >> it actually _is_ more unsafe. You could burn mother boards with that. If
> >> host tells you it only has 100mA power budget left, why are you trying
> >> to get more ?
> >
> > No, you can't burn motherboard like that... You can force emergency
> > shutdowns, which is also bad, but... There are many devices that break
> > this aspect of USB protocol.
> >
> > https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the
> 
> we can't prevent people from coming up with bad devices/cables/whatever,
> right ? But we can make sure that overcoming a 500mA power budget on a
> USB 2.0 port will not be allowed.

No, you can't, because you don't know if you are connected to USB 2.0
port. (Because non-compliant cables exist).

> >> > Unfortunately, there's more than one standard for detecting charger,
> >> > so manual control will probably be required.
> >> 
> >> n900 never had manual control of anything. It was just using information
> >> given by the battery IC, charger IC and twl4030 madc.
> >
> > Manual control of n900 charging is done by:
> >
> > echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit
> 
> yes, that's fine. And if you're connected to a dedicated charger (DCP)
> which follows USB Battery Charger specification, we *know* that it
> should, per the spec, source up to 2A, so this is fine.

BTW have you ever seen such USB-compliant dedicated charger? I have
more than 5 chargers here, and not one of them is 2A. (Most are .5A,
some are 1A, one is 1.2A).

> However, if you're connected to SDP (regular PC port), which has a power
> budget of 500mA per-port (meaning, that if you're behind a bus powered
> hub, you can't even get 500mA), then this write() of yours should be
> invalid. It should *not* be a successful write() as that creates an
> unsafe and potentially dangerous scenario for the user.

Yes, USB is "potentially dangerous", because noone follows the
specs. Fortunately, everyone knows (except you?) that noone follows
the specs, so the hardware can deal with that, and they include
(poly?) fuses where neccessary.

> > They already can go over the limit, for example using cable linked
> > above. I have several such cables here. I also have various wall
> 
> people can use unsupported cable assemblies if they want, but you can't
> expect kernel to support you.

Then we won't have useful charging support in kernel.

> > supplies that are not detected as a wall supply by N900. So I either
> > have to remember and connect them with the "special" cable, or
> > (easier) use the override above to get useful charging.
> 
> those supplies are not supported by N900. N900 was designed with USB
> Battery Chaging specification in mind and Nokia is not around anymore to
> give you SW updates. Sorry, but that's not the kernel's fault.
> 
> The point is the following: there are a handful of people who would
> *know* how to fiddle with these limits, many would not. The vast
> majority would not. And, considering this is something completely out of
> spec, and, again, potentially dangerous to the user, we are not going to
> support it.

You speak about dangerous where little danger exist; number of
non-compliant cables and USB devices is very high (take your power
bank. Does it really limit to .5A when charging from computer?) and we
should support them, not cry "dangerous" and force everyone to come
with their own "solutions".

> You may use your hacked up cables, not a problem. I did that myself
> during N900 development (though I was using a lab power supply with a 2A
> current limit sourcing 5V) to test port type detection and charging
> algorithm. But that's really not something any company (or this
> community) will support.

Fortunately, that's not your decision and community already decided
the other way.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

On Mon 2016-04-18 14:42:58, Felipe Balbi wrote:
> 
> Hi,
> 
> Pavel Machek  writes:
> > On Mon 2016-04-18 13:55:17, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Felipe Balbi  writes:
> >> >> But cellphone user knows what he connected his charger to, and that's
> >> >> why it is useful to be able to lower the current. Even when you said
> >> >> "less is just stupid" I demonstrated it is not, at least in case when
> >> 
> >> and btw, you haven't demonstrated anything. You merely stated that it
> >> isn't without references or numbers, or any source of trustworthy
> >> information. I'm not really into 'believing'.
> >
> > You are not really into reading, either, it seems. Or into the
> > electronics. Or into physics.
> >
> > You seem to understand that charging li-ion from li-ion produces too
> > much heat. (And yes, it does, DC-DC convertors are not 100%
> > effective). Converting energy into heat is not a good idea.
> >
> > If you need numbers or references to understand basic physics, you'll
> > need to google it yourself, I'm afraid. 
> 
> still doesn't change the fact that you haven't demonstrated anything. If
> you can't be helpful and/or constructive, you may also go away and use
> whatever unsafe setup you want to use.

So you still claim that it is "stupid" to charge at anything lower
than maximum allowed current?

Even after I described the example with device running off power bank
on a train? Would you explain your reasoning?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
>> >> manually ??? Hell no! Charger IC should be able to do this no
>> >> problem. I would be surprised if there's any charger IC out there which
>> >> blindly connects a 1.8A load from the start. What these ICs do is that
>> >> they slowly increment the load and check voltage level. They'll continue
>> >> to do that up to the maximum you listed (1.8A, let's say). As soon as
>> >> voltage drops a bit, charger IC knows that it use previous load.
>> >
>> > As I explained, if the note on the wall charger says 1.5A, you want to
>> > do 1.5A, not 1.8A. You can measure voltage on the charger, but you
>> > don't know its temperature.
>> 
>> phone can't read what it says in the wall charger, nor can it know that
>> it's connected charger ABC and not charger XYZ. Think of the user
>> experience. You can't expect users to tell you "okay phone, the charger
>> reads that maximum is 1.5A, so please don't go over that."
>
> Of course, we may do something sensible by default. But manual
> controls should still be present. You called them "stupid" but they
> are not.
>
> Note that just because you detected wall charger does not even mean
> you are connected to wall charger. See the link below.

that's a horrible product. So what ? If you want to use that, be my
guest. Just, again, don't ask for support when things start falling
apart ;-)

>> >> still unsafe. If you really wanna do that, you're welcome to removing
>> >> safety margins from your own kernel, but we're definitely not going to
>> >> ship this to millions of users.
>> >
>> > Not more unsafe than loading wall chargers with "lets see how much we
>> > can get out of it" algorithm. Plus actually required to charge your
>> 
>> it actually _is_ more unsafe. You could burn mother boards with that. If
>> host tells you it only has 100mA power budget left, why are you trying
>> to get more ?
>
> No, you can't burn motherboard like that... You can force emergency
> shutdowns, which is also bad, but... There are many devices that break
> this aspect of USB protocol.
>
> https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the

we can't prevent people from coming up with bad devices/cables/whatever,
right ? But we can make sure that overcoming a 500mA power budget on a
USB 2.0 port will not be allowed.

>> > Unfortunately, there's more than one standard for detecting charger,
>> > so manual control will probably be required.
>> 
>> n900 never had manual control of anything. It was just using information
>> given by the battery IC, charger IC and twl4030 madc.
>
> Manual control of n900 charging is done by:
>
> echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit

yes, that's fine. And if you're connected to a dedicated charger (DCP)
which follows USB Battery Charger specification, we *know* that it
should, per the spec, source up to 2A, so this is fine.

However, if you're connected to SDP (regular PC port), which has a power
budget of 500mA per-port (meaning, that if you're behind a bus powered
hub, you can't even get 500mA), then this write() of yours should be
invalid. It should *not* be a successful write() as that creates an
unsafe and potentially dangerous scenario for the user.

>> >> > (And with USB 5V connected directly to pretty beefy PC power supply...
>> >> > it is sometimes safer than it looks).
>> >> 
>> >> you're not considering the thermal dissipation on the USB connector
>> >> itself. Many of them might not use good metals because they assume the
>> >> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
>> >> you could, literally, melt the connector.
>> >
>> > If you are dissipating 2.5W at the connector, you are doing something
>> > very wrong. You should not be short-circuiting your USB... even when
>> > the ports are usually designed to survive that.
>> 
>> yes. You shouldn't. You also shouldn't go over that limit. If you have a
>> 500mA total power budget, we should not let anybody try to draw more
>> because we have no control over what's on the side of the wire.
>
> They already can go over the limit, for example using cable linked
> above. I have several such cables here. I also have various wall

people can use unsupported cable assemblies if they want, but you can't
expect kernel to support you.

> supplies that are not detected as a wall supply by N900. So I either
> have to remember and connect them with the "special" cable, or
> (easier) use the override above to get useful charging.

those supplies are not supported by N900. N900 was designed with USB
Battery Chaging specification in mind and Nokia is not around anymore to
give you SW updates. Sorry, but that's not the kernel's fault.

The point is the following: there are a handful of people who would
*know* how to fiddle with these limits, many would not. The vast
majority would not. And, considering this is something completely out of
spec, and, again, potentially dangerous to 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
> On Mon 2016-04-18 13:55:17, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Felipe Balbi  writes:
>> >> But cellphone user knows what he connected his charger to, and that's
>> >> why it is useful to be able to lower the current. Even when you said
>> >> "less is just stupid" I demonstrated it is not, at least in case when
>> 
>> and btw, you haven't demonstrated anything. You merely stated that it
>> isn't without references or numbers, or any source of trustworthy
>> information. I'm not really into 'believing'.
>
> You are not really into reading, either, it seems. Or into the
> electronics. Or into physics.
>
> You seem to understand that charging li-ion from li-ion produces too
> much heat. (And yes, it does, DC-DC convertors are not 100%
> effective). Converting energy into heat is not a good idea.
>
> If you need numbers or references to understand basic physics, you'll
> need to google it yourself, I'm afraid. 

still doesn't change the fact that you haven't demonstrated anything. If
you can't be helpful and/or constructive, you may also go away and use
whatever unsafe setup you want to use.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

Hi!

On Mon 2016-04-18 10:59:23, David Laight wrote:
> From: Pavel Machek
> > Sent: 18 April 2016 11:40
> ...
> > > >> > Actually, less is not stupid. Charging li-ion battery from li-ion 
> > > >> > battery might
> > > >> > be stupid. Imagine I'm on train, with device like N900 (50% battery) 
> > > >> > and power bank
> > > >> > (3Ah). I'm actively using the device. If I let it charge at full 
> > > >> > current, I'll waste
> > > >> > energy. If I limit current to approximately the power consumption, 
> > > >> > it will run the
> > > >> > powerbank empty, first, then empty the internal battery, maximizing 
> > > >> > total time I
> > > >> > can use the device.
> > > >>
> > > >> why would you waste energy ? What the charger chip would do is charge
> > > >> battery to maximum then just to maintenance charge from that point
> > > >> on. Where is energy being wasted other than normal heat dissipation ?
> > > >
> > > > Physics 101, of course wasted energy goes to heat. Lets not waste
> > > > energy by charging li-ion from li-ion when it is not required.
> > >
> > > your cellphone has no means to know that it's connected to a Li-Ion
> > > battery. We don't have visibility on what we're connected to, just how
> > > much it can source.
> > 
> > But cellphone user knows what he connected his charger to, and that's
> > why it is useful to be able to lower the current. Even when you said
> > "less is just stupid" I demonstrated it is not, at least in case when
> > your power source is a battery.
> 
> It reality you may want the phone/tablet to be configurable to take power
> from USB, but disable the li-ion charging circuit.
> That will maximise the time you get when running from an external battery.
> I connect my tablet to the 1A output (which discharges the internal battery
> slowly) rather than the 2A one (which will charge it with some
> cables).

Yes, being able to power device from external without charging the
battery is useful, too.

But I'd still like to control individual currents, too. If I have
power bank and two devices, I may want to select which one charges
faster.

Best regards,   
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[David Laight]

From: Pavel Machek
> Sent: 18 April 2016 11:40
...
> > >> > Actually, less is not stupid. Charging li-ion battery from li-ion 
> > >> > battery might
> > >> > be stupid. Imagine I'm on train, with device like N900 (50% battery) 
> > >> > and power bank
> > >> > (3Ah). I'm actively using the device. If I let it charge at full 
> > >> > current, I'll waste
> > >> > energy. If I limit current to approximately the power consumption, it 
> > >> > will run the
> > >> > powerbank empty, first, then empty the internal battery, maximizing 
> > >> > total time I
> > >> > can use the device.
> > >>
> > >> why would you waste energy ? What the charger chip would do is charge
> > >> battery to maximum then just to maintenance charge from that point
> > >> on. Where is energy being wasted other than normal heat dissipation ?
> > >
> > > Physics 101, of course wasted energy goes to heat. Lets not waste
> > > energy by charging li-ion from li-ion when it is not required.
> >
> > your cellphone has no means to know that it's connected to a Li-Ion
> > battery. We don't have visibility on what we're connected to, just how
> > much it can source.
> 
> But cellphone user knows what he connected his charger to, and that's
> why it is useful to be able to lower the current. Even when you said
> "less is just stupid" I demonstrated it is not, at least in case when
> your power source is a battery.

It reality you may want the phone/tablet to be configurable to take power
from USB, but disable the li-ion charging circuit.
That will maximise the time you get when running from an external battery.
I connect my tablet to the 1A output (which discharges the internal battery
slowly) rather than the 2A one (which will charge it with some cables).

Getting 2A from a USB charger seems to be very device/cable/charger dependant.
We've two Samsung chargers that look similar, but have completely different
characteristics. Both claim 2A at 5v (one says 5.3v), one claims 1.5A at
something like 12v as well - not sure we should be using that one for
'random' devices.

David

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
>> >> > a) you are connected to a dedicated charger
>> >> >
>> >> > In this case, you can get up to 2000mA depending on the charger.
>> >> >
>> >> > If $this charger can give you or not 2000mA is not detectable,
>> >> > so what do charging ICs do ? They slowly increase the attached
>> >> > load accross VBUS/GND and measure VBUS value. When IC notices
>> >> > VBUS dropping bit, step back to previous load.
>> >> >
>> >> > This means you will always charger with maximum rating of DCP.
>> >> >
>> >> > Why would user change this ? More is unsafe, less is just
>> >> > stupid.
>> >
>> > Less is not neccessarily stupid. First, it is useful for debugging, 
>> > second, you
>> > don't know how much this charger can give you. You measured you can get 
>> > 1.8A,
>> > but the note on the charger says 1.5A. You may want to go with 1.5A.
>> >
>> > Also, there are several incompatible standards for detecting
>> > "dedicated charger". IIRC iPhone has different one from iPad. So it is
>> > quite important to be able to control this manually.
>> 
>> manually ??? Hell no! Charger IC should be able to do this no
>> problem. I would be surprised if there's any charger IC out there which
>> blindly connects a 1.8A load from the start. What these ICs do is that
>> they slowly increment the load and check voltage level. They'll continue
>> to do that up to the maximum you listed (1.8A, let's say). As soon as
>> voltage drops a bit, charger IC knows that it use previous load.
>
> As I explained, if the note on the wall charger says 1.5A, you want to
> do 1.5A, not 1.8A. You can measure voltage on the charger, but you
> don't know its temperature.

phone can't read what it says in the wall charger, nor can it know that
it's connected charger ABC and not charger XYZ. Think of the user
experience. You can't expect users to tell you "okay phone, the charger
reads that maximum is 1.5A, so please don't go over that."

>> >> > d) you are connected to a standard port and get enumerated with your
>> >> > 100mA configuration.
>> >> >
>> >> > you *know* 100mA is okay. So you connect a 100mA load and get it
>> >> > over with.
>> >> >
>> >> > This means you will always charger with maximum rating for this
>> >> > SDP.
>> >> >
>> >> > Why would user change this ? More is unsafe, less is just
>> >> > stupid.
>> >
>> > I've needed to override 100mA default many times. Maybe it is unsafe,
>> > but it is useful.
>> 
>> still unsafe. If you really wanna do that, you're welcome to removing
>> safety margins from your own kernel, but we're definitely not going to
>> ship this to millions of users.
>
> Not more unsafe than loading wall chargers with "lets see how much we
> can get out of it" algorithm. Plus actually required to charge your

it actually _is_ more unsafe. You could burn mother boards with that. If
host tells you it only has 100mA power budget left, why are you trying
to get more ?

> machines in useful way. So it is important that common API
> exists. Whether it gets enalbed at production is different question.

as I said, if you wanna do some unsafe manual method, be my guest; but
I'm not convinced that every user of the linux kernel wants that in
their pockets.

> Unfortunately, there's more than one standard for detecting charger,
> so manual control will probably be required.

n900 never had manual control of anything. It was just using information
given by the battery IC, charger IC and twl4030 madc.

>> > (And with USB 5V connected directly to pretty beefy PC power supply...
>> > it is sometimes safer than it looks).
>> 
>> you're not considering the thermal dissipation on the USB connector
>> itself. Many of them might not use good metals because they assume the
>> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
>> you could, literally, melt the connector.
>
> If you are dissipating 2.5W at the connector, you are doing something
> very wrong. You should not be short-circuiting your USB... even when
> the ports are usually designed to survive that.

yes. You shouldn't. You also shouldn't go over that limit. If you have a
500mA total power budget, we should not let anybody try to draw more
because we have no control over what's on the side of the wire.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

On Mon 2016-04-18 13:55:17, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi  writes:
> >> But cellphone user knows what he connected his charger to, and that's
> >> why it is useful to be able to lower the current. Even when you said
> >> "less is just stupid" I demonstrated it is not, at least in case when
> 
> and btw, you haven't demonstrated anything. You merely stated that it
> isn't without references or numbers, or any source of trustworthy
> information. I'm not really into 'believing'.

You are not really into reading, either, it seems. Or into the
electronics. Or into physics.

You seem to understand that charging li-ion from li-ion produces too
much heat. (And yes, it does, DC-DC convertors are not 100%
effective). Converting energy into heat is not a good idea.

If you need numbers or references to understand basic physics, you'll
need to google it yourself, I'm afraid. 

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

Hi!

> >> manually ??? Hell no! Charger IC should be able to do this no
> >> problem. I would be surprised if there's any charger IC out there which
> >> blindly connects a 1.8A load from the start. What these ICs do is that
> >> they slowly increment the load and check voltage level. They'll continue
> >> to do that up to the maximum you listed (1.8A, let's say). As soon as
> >> voltage drops a bit, charger IC knows that it use previous load.
> >
> > As I explained, if the note on the wall charger says 1.5A, you want to
> > do 1.5A, not 1.8A. You can measure voltage on the charger, but you
> > don't know its temperature.
> 
> phone can't read what it says in the wall charger, nor can it know that
> it's connected charger ABC and not charger XYZ. Think of the user
> experience. You can't expect users to tell you "okay phone, the charger
> reads that maximum is 1.5A, so please don't go over that."

Of course, we may do something sensible by default. But manual
controls should still be present. You called them "stupid" but they
are not.

Note that just because you detected wall charger does not even mean
you are connected to wall charger. See the link below.

> >> still unsafe. If you really wanna do that, you're welcome to removing
> >> safety margins from your own kernel, but we're definitely not going to
> >> ship this to millions of users.
> >
> > Not more unsafe than loading wall chargers with "lets see how much we
> > can get out of it" algorithm. Plus actually required to charge your
> 
> it actually _is_ more unsafe. You could burn mother boards with that. If
> host tells you it only has 100mA power budget left, why are you trying
> to get more ?

No, you can't burn motherboard like that... You can force emergency
shutdowns, which is also bad, but... There are many devices that break
this aspect of USB protocol.

https://www.kickstarter.com/projects/1785889318/doubbletime-charging-cable-full-battery-in-1-2-the

> > Unfortunately, there's more than one standard for detecting charger,
> > so manual control will probably be required.
> 
> n900 never had manual control of anything. It was just using information
> given by the battery IC, charger IC and twl4030 madc.

Manual control of n900 charging is done by:

echo 1800 > /sys/class/power_supply/bq24150a-0/current_limit

> >> > (And with USB 5V connected directly to pretty beefy PC power supply...
> >> > it is sometimes safer than it looks).
> >> 
> >> you're not considering the thermal dissipation on the USB connector
> >> itself. Many of them might not use good metals because they assume the
> >> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
> >> you could, literally, melt the connector.
> >
> > If you are dissipating 2.5W at the connector, you are doing something
> > very wrong. You should not be short-circuiting your USB... even when
> > the ports are usually designed to survive that.
> 
> yes. You shouldn't. You also shouldn't go over that limit. If you have a
> 500mA total power budget, we should not let anybody try to draw more
> because we have no control over what's on the side of the wire.

They already can go over the limit, for example using cable linked
above. I have several such cables here. I also have various wall
supplies that are not detected as a wall supply by N900. So I either
have to remember and connect them with the "special" cable, or
(easier) use the override above to get useful charging.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Felipe Balbi  writes:
>> But cellphone user knows what he connected his charger to, and that's
>> why it is useful to be able to lower the current. Even when you said
>> "less is just stupid" I demonstrated it is not, at least in case when

and btw, you haven't demonstrated anything. You merely stated that it
isn't without references or numbers, or any source of trustworthy
information. I'm not really into 'believing'.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
> On Mon 2016-04-18 13:30:54, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Pavel Machek  writes:
>> >> > Very often, you want to charge using 1.8A from an old desktop PC.
>> >> 
>> >> if that old desktop's port is not a charging port, you shouldn't be
>> >> allowed to do that. Not ever.
>> >
>> > Yes, Felipe just decided that I should not be able to charge my N900
>> > in useful way.
>> 
>> you can do whatever you want with *your* kernel binary, but we're not
>> gonna ship something potentially dangerous. If that PC port is telling
>> you it can only allow 100mA, you should *not* be allowed to overcome
>> that limitation from the device side, sorry.
>
> Yes, and if your cpu tells you it can only run on 2GHz, you should not
> be able to run it on 2.1GHz. And you should not be able to use
> non-VESA VGA modes, because you could overheat coils in the monitor.

heh, yada-yada-yada.

> You are shipping something potentially dangerous already, because you
> know, USB-A-to-micro-B cables with D+/D- connected to simulate charger
> are actually very common. The world did not end, yet, so it is clearly
> not as bad as you make it be.

That's not even a supported cable assembly. If you break your HW, that's
your own fault for not using proper cables. There's nothing the kernel
can do about that anyway.

If you're willing to by a "special" cable just to overcome safety limits
set by the various USB specifications, go head. But don't ask me to
support you when things go wrong.

>> >> >> a) you are connected to a dedicated charger
>> >> >> 
>> >> >>In this case, you can get up to 2000mA depending on the charger.
>> >> >> 
>> >> >>If $this charger can give you or not 2000mA is not detectable,
>> >> >>so what do charging ICs do ? They slowly increase the attached
>> >> >>load accross VBUS/GND and measure VBUS value. When IC notices
>> >> >>VBUS dropping bit, step back to previous load.
>> >> >> 
>> >> >>This means you will always charger with maximum rating of DCP.
>> >> >> 
>> >> >>Why would user change this ? More is unsafe, less is just
>> >> >>stupid.
>> >> >
>> >> > Actually, less is not stupid. Charging li-ion battery from li-ion 
>> >> > battery might
>> >> > be stupid. Imagine I'm on train, with device like N900 (50% battery) 
>> >> > and power bank
>> >> > (3Ah). I'm actively using the device. If I let it charge at full 
>> >> > current, I'll waste
>> >> > energy. If I limit current to approximately the power consumption, it 
>> >> > will run the
>> >> > powerbank empty, first, then empty the internal battery, maximizing 
>> >> > total time I
>> >> > can use the device.
>> >> 
>> >> why would you waste energy ? What the charger chip would do is charge
>> >> battery to maximum then just to maintenance charge from that point
>> >> on. Where is energy being wasted other than normal heat dissipation ?
>> >
>> > Physics 101, of course wasted energy goes to heat. Lets not waste
>> > energy by charging li-ion from li-ion when it is not required.
>> 
>> your cellphone has no means to know that it's connected to a Li-Ion
>> battery. We don't have visibility on what we're connected to, just how
>> much it can source.
>
> But cellphone user knows what he connected his charger to, and that's
> why it is useful to be able to lower the current. Even when you said
> "less is just stupid" I demonstrated it is not, at least in case when
> your power source is a battery.

okay, so let's do this. How much more "time" do you get by doing this ?
Without numbers showing that it's considerably better, we can't do
anything.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

On Mon 2016-04-18 13:30:54, Felipe Balbi wrote:
> 
> Hi,
> 
> Pavel Machek  writes:
> >> > Very often, you want to charge using 1.8A from an old desktop PC.
> >> 
> >> if that old desktop's port is not a charging port, you shouldn't be
> >> allowed to do that. Not ever.
> >
> > Yes, Felipe just decided that I should not be able to charge my N900
> > in useful way.
> 
> you can do whatever you want with *your* kernel binary, but we're not
> gonna ship something potentially dangerous. If that PC port is telling
> you it can only allow 100mA, you should *not* be allowed to overcome
> that limitation from the device side, sorry.

Yes, and if your cpu tells you it can only run on 2GHz, you should not
be able to run it on 2.1GHz. And you should not be able to use
non-VESA VGA modes, because you could overheat coils in the monitor.

You are shipping something potentially dangerous already, because you
know, USB-A-to-micro-B cables with D+/D- connected to simulate charger
are actually very common. The world did not end, yet, so it is clearly
not as bad as you make it be.

> >> >> a) you are connected to a dedicated charger
> >> >> 
> >> >> In this case, you can get up to 2000mA depending on the charger.
> >> >> 
> >> >> If $this charger can give you or not 2000mA is not detectable,
> >> >> so what do charging ICs do ? They slowly increase the attached
> >> >> load accross VBUS/GND and measure VBUS value. When IC notices
> >> >> VBUS dropping bit, step back to previous load.
> >> >> 
> >> >> This means you will always charger with maximum rating of DCP.
> >> >> 
> >> >> Why would user change this ? More is unsafe, less is just
> >> >> stupid.
> >> >
> >> > Actually, less is not stupid. Charging li-ion battery from li-ion 
> >> > battery might
> >> > be stupid. Imagine I'm on train, with device like N900 (50% battery) and 
> >> > power bank
> >> > (3Ah). I'm actively using the device. If I let it charge at full 
> >> > current, I'll waste
> >> > energy. If I limit current to approximately the power consumption, it 
> >> > will run the
> >> > powerbank empty, first, then empty the internal battery, maximizing 
> >> > total time I
> >> > can use the device.
> >> 
> >> why would you waste energy ? What the charger chip would do is charge
> >> battery to maximum then just to maintenance charge from that point
> >> on. Where is energy being wasted other than normal heat dissipation ?
> >
> > Physics 101, of course wasted energy goes to heat. Lets not waste
> > energy by charging li-ion from li-ion when it is not required.
> 
> your cellphone has no means to know that it's connected to a Li-Ion
> battery. We don't have visibility on what we're connected to, just how
> much it can source.

But cellphone user knows what he connected his charger to, and that's
why it is useful to be able to lower the current. Even when you said
"less is just stupid" I demonstrated it is not, at least in case when
your power source is a battery.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

Hi!

> >> > a) you are connected to a dedicated charger
> >> >
> >> > In this case, you can get up to 2000mA depending on the charger.
> >> >
> >> > If $this charger can give you or not 2000mA is not detectable,
> >> > so what do charging ICs do ? They slowly increase the attached
> >> > load accross VBUS/GND and measure VBUS value. When IC notices
> >> > VBUS dropping bit, step back to previous load.
> >> >
> >> > This means you will always charger with maximum rating of DCP.
> >> >
> >> > Why would user change this ? More is unsafe, less is just
> >> > stupid.
> >
> > Less is not neccessarily stupid. First, it is useful for debugging, second, 
> > you
> > don't know how much this charger can give you. You measured you can get 
> > 1.8A,
> > but the note on the charger says 1.5A. You may want to go with 1.5A.
> >
> > Also, there are several incompatible standards for detecting
> > "dedicated charger". IIRC iPhone has different one from iPad. So it is
> > quite important to be able to control this manually.
> 
> manually ??? Hell no! Charger IC should be able to do this no
> problem. I would be surprised if there's any charger IC out there which
> blindly connects a 1.8A load from the start. What these ICs do is that
> they slowly increment the load and check voltage level. They'll continue
> to do that up to the maximum you listed (1.8A, let's say). As soon as
> voltage drops a bit, charger IC knows that it use previous load.

As I explained, if the note on the wall charger says 1.5A, you want to
do 1.5A, not 1.8A. You can measure voltage on the charger, but you
don't know its temperature.

> >> > d) you are connected to a standard port and get enumerated with your
> >> > 100mA configuration.
> >> >
> >> > you *know* 100mA is okay. So you connect a 100mA load and get it
> >> > over with.
> >> >
> >> > This means you will always charger with maximum rating for this
> >> > SDP.
> >> >
> >> > Why would user change this ? More is unsafe, less is just
> >> > stupid.
> >
> > I've needed to override 100mA default many times. Maybe it is unsafe,
> > but it is useful.
> 
> still unsafe. If you really wanna do that, you're welcome to removing
> safety margins from your own kernel, but we're definitely not going to
> ship this to millions of users.

Not more unsafe than loading wall chargers with "lets see how much we
can get out of it" algorithm. Plus actually required to charge your
machines in useful way. So it is important that common API
exists. Whether it gets enalbed at production is different question.

Unfortunately, there's more than one standard for detecting charger,
so manual control will probably be required.

> > (And with USB 5V connected directly to pretty beefy PC power supply...
> > it is sometimes safer than it looks).
> 
> you're not considering the thermal dissipation on the USB connector
> itself. Many of them might not use good metals because they assume the
> maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
> you could, literally, melt the connector.

If you are dissipating 2.5W at the connector, you are doing something
very wrong. You should not be short-circuiting your USB... even when
the ports are usually designed to survive that.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
>> > Very often, you want to charge using 1.8A from an old desktop PC.
>> 
>> if that old desktop's port is not a charging port, you shouldn't be
>> allowed to do that. Not ever.
>
> Yes, Felipe just decided that I should not be able to charge my N900
> in useful way.

you can do whatever you want with *your* kernel binary, but we're not
gonna ship something potentially dangerous. If that PC port is telling
you it can only allow 100mA, you should *not* be allowed to overcome
that limitation from the device side, sorry.

>> >> a) you are connected to a dedicated charger
>> >> 
>> >>   In this case, you can get up to 2000mA depending on the charger.
>> >> 
>> >>   If $this charger can give you or not 2000mA is not detectable,
>> >>   so what do charging ICs do ? They slowly increase the attached
>> >>   load accross VBUS/GND and measure VBUS value. When IC notices
>> >>   VBUS dropping bit, step back to previous load.
>> >> 
>> >>   This means you will always charger with maximum rating of DCP.
>> >> 
>> >>   Why would user change this ? More is unsafe, less is just
>> >>   stupid.
>> >
>> > Actually, less is not stupid. Charging li-ion battery from li-ion battery 
>> > might
>> > be stupid. Imagine I'm on train, with device like N900 (50% battery) and 
>> > power bank
>> > (3Ah). I'm actively using the device. If I let it charge at full current, 
>> > I'll waste
>> > energy. If I limit current to approximately the power consumption, it will 
>> > run the
>> > powerbank empty, first, then empty the internal battery, maximizing total 
>> > time I
>> > can use the device.
>> 
>> why would you waste energy ? What the charger chip would do is charge
>> battery to maximum then just to maintenance charge from that point
>> on. Where is energy being wasted other than normal heat dissipation ?
>
> Physics 101, of course wasted energy goes to heat. Lets not waste
> energy by charging li-ion from li-ion when it is not required.

your cellphone has no means to know that it's connected to a Li-Ion
battery. We don't have visibility on what we're connected to, just how
much it can source.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

Hi!

> >> >>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
> >> >>
> >> >> According to the spec we should always be talking about unit loads (1
> >> >> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
> >> >> work for SS capable ports and SS gadgets (we have quite a few of them,
> >> >> actually). You're missing the opportunity of charging at 900mA.
> >> >
> >> > I follow the DCP/SDP/CDP/ACA type's default current limitation and
> >> > user can set them what they want.
> >> 
> >> no, the user CANNOT set it to what they want. If you get enumerated
> >> @100mA and the user just decides to set it to 2000mA, s/he could even
> >> melt the USB connector. The kernel _must_ prevent such cases.
> >
> > root should be allowed to do that.
> 
> root should not be allowed to put user at risk. The usb connector is a
> path to earth ground in most (all?) desktop computers. Allowing root to
> put that connector in a situation where it could melt the connector and
> short mains should never be allowed.

Be sure that hardware people put reasonable precautions...

> > Very often, you want to charge using 1.8A from an old desktop PC.
> 
> if that old desktop's port is not a charging port, you shouldn't be
> allowed to do that. Not ever.

Yes, Felipe just decided that I should not be able to charge my N900
in useful way.

> > N900 will simply not charge from .5A.
> 
> it used to with original maemo userspace/kernel.

Yeah, at about 10% per night.

> >> a) you are connected to a dedicated charger
> >> 
> >>In this case, you can get up to 2000mA depending on the charger.
> >> 
> >>If $this charger can give you or not 2000mA is not detectable,
> >>so what do charging ICs do ? They slowly increase the attached
> >>load accross VBUS/GND and measure VBUS value. When IC notices
> >>VBUS dropping bit, step back to previous load.
> >> 
> >>This means you will always charger with maximum rating of DCP.
> >> 
> >>Why would user change this ? More is unsafe, less is just
> >>stupid.
> >
> > Actually, less is not stupid. Charging li-ion battery from li-ion battery 
> > might
> > be stupid. Imagine I'm on train, with device like N900 (50% battery) and 
> > power bank
> > (3Ah). I'm actively using the device. If I let it charge at full current, 
> > I'll waste
> > energy. If I limit current to approximately the power consumption, it will 
> > run the
> > powerbank empty, first, then empty the internal battery, maximizing total 
> > time I
> > can use the device.
> 
> why would you waste energy ? What the charger chip would do is charge
> battery to maximum then just to maintenance charge from that point
> on. Where is energy being wasted other than normal heat dissipation ?

Physics 101, of course wasted energy goes to heat. Lets not waste
energy by charging li-ion from li-ion when it is not required.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
> Hi!
>
>> > It's your HW :-) You tell me if it's really necessary. But, hey, if you
>> > get enumerated @500mA, this is the host telling you it _CAN_ give you
>> > 500mA. In that case, why wouldn't you ?
>
> Dunno, perhaps not to drain battery in host too quickly?
> Or perhaps you are charging from external battery?
>
>> >>> why RW ? Who's going to use these ? Also, you're not documenting this
>> >>> new sysfs file.
>> >>
>> >> Cause we have show and store operation for SDP type. If users want to
>> >> know or set the SDP current, they can use the sysfs file.
>> >> I'll add the documentation for it.
>> >
>> > but why would the user change it ? Here's the thing: you have a few
>> > posibilities for this:
>> >
>> > a) you are connected to a dedicated charger
>> >
>> > In this case, you can get up to 2000mA depending on the charger.
>> >
>> > If $this charger can give you or not 2000mA is not detectable,
>> > so what do charging ICs do ? They slowly increase the attached
>> > load accross VBUS/GND and measure VBUS value. When IC notices
>> > VBUS dropping bit, step back to previous load.
>> >
>> > This means you will always charger with maximum rating of DCP.
>> >
>> > Why would user change this ? More is unsafe, less is just
>> > stupid.
>
> Less is not neccessarily stupid. First, it is useful for debugging, second, 
> you
> don't know how much this charger can give you. You measured you can get 1.8A,
> but the note on the charger says 1.5A. You may want to go with 1.5A.
>
> Also, there are several incompatible standards for detecting
> "dedicated charger". IIRC iPhone has different one from iPad. So it is
> quite important to be able to control this manually.

manually ??? Hell no! Charger IC should be able to do this no
problem. I would be surprised if there's any charger IC out there which
blindly connects a 1.8A load from the start. What these ICs do is that
they slowly increment the load and check voltage level. They'll continue
to do that up to the maximum you listed (1.8A, let's say). As soon as
voltage drops a bit, charger IC knows that it use previous load.

>> > d) you are connected to a standard port and get enumerated with your
>> > 100mA configuration.
>> >
>> > you *know* 100mA is okay. So you connect a 100mA load and get it
>> > over with.
>> >
>> > This means you will always charger with maximum rating for this
>> > SDP.
>> >
>> > Why would user change this ? More is unsafe, less is just
>> > stupid.
>
> I've needed to override 100mA default many times. Maybe it is unsafe,
> but it is useful.

still unsafe. If you really wanna do that, you're welcome to removing
safety margins from your own kernel, but we're definitely not going to
ship this to millions of users.

> (And with USB 5V connected directly to pretty beefy PC power supply...
> it is sometimes safer than it looks).

you're not considering the thermal dissipation on the USB connector
itself. Many of them might not use good metals because they assume the
maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more,
you could, literally, melt the connector.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Pavel Machek  writes:
>> >>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>> >>
>> >> According to the spec we should always be talking about unit loads (1
>> >> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
>> >> work for SS capable ports and SS gadgets (we have quite a few of them,
>> >> actually). You're missing the opportunity of charging at 900mA.
>> >
>> > I follow the DCP/SDP/CDP/ACA type's default current limitation and
>> > user can set them what they want.
>> 
>> no, the user CANNOT set it to what they want. If you get enumerated
>> @100mA and the user just decides to set it to 2000mA, s/he could even
>> melt the USB connector. The kernel _must_ prevent such cases.
>
> root should be allowed to do that.

root should not be allowed to put user at risk. The usb connector is a
path to earth ground in most (all?) desktop computers. Allowing root to
put that connector in a situation where it could melt the connector and
short mains should never be allowed.

> Very often, you want to charge using 1.8A from an old desktop PC.

if that old desktop's port is not a charging port, you shouldn't be
allowed to do that. Not ever.

> N900 will simply not charge from .5A.

it used to with original maemo userspace/kernel.

>> a) you are connected to a dedicated charger
>> 
>>  In this case, you can get up to 2000mA depending on the charger.
>> 
>>  If $this charger can give you or not 2000mA is not detectable,
>>  so what do charging ICs do ? They slowly increase the attached
>>  load accross VBUS/GND and measure VBUS value. When IC notices
>>  VBUS dropping bit, step back to previous load.
>> 
>>  This means you will always charger with maximum rating of DCP.
>> 
>>  Why would user change this ? More is unsafe, less is just
>>  stupid.
>
> Actually, less is not stupid. Charging li-ion battery from li-ion battery 
> might
> be stupid. Imagine I'm on train, with device like N900 (50% battery) and 
> power bank
> (3Ah). I'm actively using the device. If I let it charge at full current, 
> I'll waste
> energy. If I limit current to approximately the power consumption, it will 
> run the
> powerbank empty, first, then empty the internal battery, maximizing total 
> time I
> can use the device.

why would you waste energy ? What the charger chip would do is charge
battery to maximum then just to maintenance charge from that point
on. Where is energy being wasted other than normal heat dissipation ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

Hi!

> > It's your HW :-) You tell me if it's really necessary. But, hey, if you
> > get enumerated @500mA, this is the host telling you it _CAN_ give you
> > 500mA. In that case, why wouldn't you ?

Dunno, perhaps not to drain battery in host too quickly?
Or perhaps you are charging from external battery?

> >>> why RW ? Who's going to use these ? Also, you're not documenting this
> >>> new sysfs file.
> >>
> >> Cause we have show and store operation for SDP type. If users want to
> >> know or set the SDP current, they can use the sysfs file.
> >> I'll add the documentation for it.
> >
> > but why would the user change it ? Here's the thing: you have a few
> > posibilities for this:
> >
> > a) you are connected to a dedicated charger
> >
> > In this case, you can get up to 2000mA depending on the charger.
> >
> > If $this charger can give you or not 2000mA is not detectable,
> > so what do charging ICs do ? They slowly increase the attached
> > load accross VBUS/GND and measure VBUS value. When IC notices
> > VBUS dropping bit, step back to previous load.
> >
> > This means you will always charger with maximum rating of DCP.
> >
> > Why would user change this ? More is unsafe, less is just
> > stupid.

Less is not neccessarily stupid. First, it is useful for debugging, second, you
don't know how much this charger can give you. You measured you can get 1.8A,
but the note on the charger says 1.5A. You may want to go with 1.5A.

Also, there are several incompatible standards for detecting "dedicated 
charger". IIRC
iPhone has different one from iPad. So it is quite important to be able to 
control this manually.


> > d) you are connected to a standard port and get enumerated with your
> > 100mA configuration.
> >
> > you *know* 100mA is okay. So you connect a 100mA load and get it
> > over with.
> >
> > This means you will always charger with maximum rating for this
> > SDP.
> >
> > Why would user change this ? More is unsafe, less is just
> > stupid.

I've needed to override 100mA default many times. Maybe it is unsafe,
but it is useful.

(And with USB 5V connected directly to pretty beefy PC power supply...
it is sometimes safer than it looks).

Plus, again, useful for debugging.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Pavel Machek]

Hi!

> >>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
> >>
> >> According to the spec we should always be talking about unit loads (1
> >> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
> >> work for SS capable ports and SS gadgets (we have quite a few of them,
> >> actually). You're missing the opportunity of charging at 900mA.
> >
> > I follow the DCP/SDP/CDP/ACA type's default current limitation and
> > user can set them what they want.
> 
> no, the user CANNOT set it to what they want. If you get enumerated
> @100mA and the user just decides to set it to 2000mA, s/he could even
> melt the USB connector. The kernel _must_ prevent such cases.

root should be allowed to do that.

Very often, you want to charge using 1.8A from an old desktop PC.

N900 will simply not charge from .5A.

> a) you are connected to a dedicated charger
> 
>   In this case, you can get up to 2000mA depending on the charger.
> 
>   If $this charger can give you or not 2000mA is not detectable,
>   so what do charging ICs do ? They slowly increase the attached
>   load accross VBUS/GND and measure VBUS value. When IC notices
>   VBUS dropping bit, step back to previous load.
> 
>   This means you will always charger with maximum rating of DCP.
> 
>   Why would user change this ? More is unsafe, less is just
>   stupid.

Actually, less is not stupid. Charging li-ion battery from li-ion battery might
be stupid. Imagine I'm on train, with device like N900 (50% battery) and power 
bank
(3Ah). I'm actively using the device. If I let it charge at full current, I'll 
waste
energy. If I limit current to approximately the power consumption, it will run 
the
powerbank empty, first, then empty the internal battery, maximizing total time I
can use the device.

Best regards,

Pavel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Greg KH]

On Mon, Apr 04, 2016 at 09:04:48AM -0700, Mark Brown wrote:
> On Mon, Apr 04, 2016 at 01:47:50PM +0300, Felipe Balbi wrote:
> > Mark Brown  writes:
> 
> > > It does in this new world order.  IIRC on an earlier round of review
> > > there was some code that didn't use a bus but that got complaints that
> > > it was trying to reimplement the bus functionality.
> 
> > fair enough, I'll wait for Greg to have some time to comment on
> > this. Bottomline is that there is *no* real bus. Charger ICs will use
> 
> I've got a feeling Greg is zoning this out by now...

Very true :)

I have a lot of other patches to go through this week, it will be a
while before I get to these...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Mark Brown]

On Mon, Apr 04, 2016 at 01:47:50PM +0300, Felipe Balbi wrote:
> Mark Brown  writes:

> > It does in this new world order.  IIRC on an earlier round of review
> > there was some code that didn't use a bus but that got complaints that
> > it was trying to reimplement the bus functionality.

> fair enough, I'll wait for Greg to have some time to comment on
> this. Bottomline is that there is *no* real bus. Charger ICs will use

I've got a feeling Greg is zoning this out by now...

> SPI or I2C and that's a real bus, $subject is not.

Well, there's the physical connection between the system power supply
and the USB port if you're very keen on looking for hardware.


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Mark Brown  writes:
> On Fri, Apr 01, 2016 at 08:43:10AM +0300, Felipe Balbi wrote:
>> Mark Brown  writes:
>
>> > IIRC Greg didn't want new classes?
>
>> good point. Still, this doesn't seem to fit a but_type IMO.
>
> It does in this new world order.  IIRC on an earlier round of review
> there was some code that didn't use a bus but that got complaints that
> it was trying to reimplement the bus functionality.

fair enough, I'll wait for Greg to have some time to comment on
this. Bottomline is that there is *no* real bus. Charger ICs will use
SPI or I2C and that's a real bus, $subject is not.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Mark Brown]

On Fri, Apr 01, 2016 at 08:43:10AM +0300, Felipe Balbi wrote:
> Mark Brown  writes:

> > IIRC Greg didn't want new classes?

> good point. Still, this doesn't seem to fit a but_type IMO.

It does in this new world order.  IIRC on an earlier round of review
there was some code that didn't use a bus but that got complaints that
it was trying to reimplement the bus functionality.


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Mark Brown  writes:
> On Thu, Mar 31, 2016 at 09:42:58AM +0300, Felipe Balbi wrote:
>> Baolin Wang  writes:
>
>> > I want to use bus structure to manage the charger device. Maybe choose
>> > class to manage them?
>
>> I guess a class would fit better in this case.
>
> IIRC Greg didn't want new classes?

good point. Still, this doesn't seem to fit a but_type IMO.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Mark Brown]

On Thu, Mar 31, 2016 at 09:42:58AM +0300, Felipe Balbi wrote:
> Baolin Wang  writes:

> > I want to use bus structure to manage the charger device. Maybe choose
> > class to manage them?

> I guess a class would fit better in this case.

IIRC Greg didn't want new classes?


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 31 March 2016 at 18:06, Felipe Balbi  wrote:
> Baolin Wang  writes:
>> [ text/plain ]
>> On 31 March 2016 at 16:18, Felipe Balbi  wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang  writes:
 +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>>>
>>> According to the spec we should always be talking about unit loads (1
>>> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
>>> work for SS capable ports and SS gadgets (we have quite a few of them,
>>> actually). You're missing the opportunity of charging at 900mA.
>>
>> I follow the DCP/SDP/CDP/ACA type's default current limitation and
>> user can set them what they want.
>
> no, the user CANNOT set it to what they want. If you get enumerated
> @100mA and the user just decides to set it to 2000mA, s/he could even
> melt the USB connector. The kernel _must_ prevent such cases.
>
> In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
> variable because if you enumerate in SS, you _can_ get up to 900mA.

 Make sense. But these are just default values. They can be changed
 safely by power driver with 'usb_charger_set_cur_limit_by_type()'
 function to set 900mA.
>>>
>>> oh okay. Still, the default value should be a function of gadget->speed,
>>
>> Sorry, I did not get your suggestion, could you give me an example? Thanks.
>
> int default_current_limit = 500;
>
> if (gadget->speed >= USB_SPEED_SUPER)
> default_current_limit = 900;

Make sense.

>
 +
 +/* USB charger state */
 +enum usb_charger_state {
 + USB_CHARGER_DEFAULT,
 + USB_CHARGER_PRESENT,
 + USB_CHARGER_REMOVE,
 +};
>>>
>>> userland really doesn't need these two ?
>>
>> We've reported to userspace by kobject_uevent in
>> 'usb_charger_notify_others()' function.
>
> I mean as a type ;-) So userspace doesn't have to redefine these for
> their applications.

 Make sense. I can introduce some sysfs files for userspace. Thanks for
 your comments.
>>>
>>> okay, my reply was a bit cryptic, but what I mean here is that enum
>>> usb_charger_state could be moved your include/uapi header. My question
>>> is, then, does userland need to have knowledge of enum
>>> usb_charger_state ?
>>
>> I am not sure if userland need the enum usb_charger_state. But I
>> remember you want to report the charger state to userland in previous
>> email.
>
> right, which means this enumeration definition could be placed in the
> UAPI header. Unless, of course, we're reporting strings, rather than
> integers, in the sysfs file.

OK. Thanks.

>
> --
> balbi



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Baolin Wang  writes:
> [ text/plain ]
> On 31 March 2016 at 16:18, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> Baolin Wang  writes:
>>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>>
>> According to the spec we should always be talking about unit loads (1
>> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
>> work for SS capable ports and SS gadgets (we have quite a few of them,
>> actually). You're missing the opportunity of charging at 900mA.
>
> I follow the DCP/SDP/CDP/ACA type's default current limitation and
> user can set them what they want.

 no, the user CANNOT set it to what they want. If you get enumerated
 @100mA and the user just decides to set it to 2000mA, s/he could even
 melt the USB connector. The kernel _must_ prevent such cases.

 In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
 variable because if you enumerate in SS, you _can_ get up to 900mA.
>>>
>>> Make sense. But these are just default values. They can be changed
>>> safely by power driver with 'usb_charger_set_cur_limit_by_type()'
>>> function to set 900mA.
>>
>> oh okay. Still, the default value should be a function of gadget->speed,
>
> Sorry, I did not get your suggestion, could you give me an example? Thanks.

int default_current_limit = 500;

if (gadget->speed >= USB_SPEED_SUPER)
default_current_limit = 900;

>>> +
>>> +/* USB charger state */
>>> +enum usb_charger_state {
>>> + USB_CHARGER_DEFAULT,
>>> + USB_CHARGER_PRESENT,
>>> + USB_CHARGER_REMOVE,
>>> +};
>>
>> userland really doesn't need these two ?
>
> We've reported to userspace by kobject_uevent in
> 'usb_charger_notify_others()' function.

 I mean as a type ;-) So userspace doesn't have to redefine these for
 their applications.
>>>
>>> Make sense. I can introduce some sysfs files for userspace. Thanks for
>>> your comments.
>>
>> okay, my reply was a bit cryptic, but what I mean here is that enum
>> usb_charger_state could be moved your include/uapi header. My question
>> is, then, does userland need to have knowledge of enum
>> usb_charger_state ?
>
> I am not sure if userland need the enum usb_charger_state. But I
> remember you want to report the charger state to userland in previous
> email.

right, which means this enumeration definition could be placed in the
UAPI header. Unless, of course, we're reporting strings, rather than
integers, in the sysfs file.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 31 March 2016 at 16:18, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>
> According to the spec we should always be talking about unit loads (1
> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
> work for SS capable ports and SS gadgets (we have quite a few of them,
> actually). You're missing the opportunity of charging at 900mA.

 I follow the DCP/SDP/CDP/ACA type's default current limitation and
 user can set them what they want.
>>>
>>> no, the user CANNOT set it to what they want. If you get enumerated
>>> @100mA and the user just decides to set it to 2000mA, s/he could even
>>> melt the USB connector. The kernel _must_ prevent such cases.
>>>
>>> In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
>>> variable because if you enumerate in SS, you _can_ get up to 900mA.
>>
>> Make sense. But these are just default values. They can be changed
>> safely by power driver with 'usb_charger_set_cur_limit_by_type()'
>> function to set 900mA.
>
> oh okay. Still, the default value should be a function of gadget->speed,

Sorry, I did not get your suggestion, could you give me an example? Thanks.

> IMO ;-)
>
>> +
>> +/* USB charger state */
>> +enum usb_charger_state {
>> + USB_CHARGER_DEFAULT,
>> + USB_CHARGER_PRESENT,
>> + USB_CHARGER_REMOVE,
>> +};
>
> userland really doesn't need these two ?

 We've reported to userspace by kobject_uevent in
 'usb_charger_notify_others()' function.
>>>
>>> I mean as a type ;-) So userspace doesn't have to redefine these for
>>> their applications.
>>
>> Make sense. I can introduce some sysfs files for userspace. Thanks for
>> your comments.
>
> okay, my reply was a bit cryptic, but what I mean here is that enum
> usb_charger_state could be moved your include/uapi header. My question
> is, then, does userland need to have knowledge of enum
> usb_charger_state ?

I am not sure if userland need the enum usb_charger_state. But I
remember you want to report the charger state to userland in previous
email.

>
> --
> balbi



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)

 According to the spec we should always be talking about unit loads (1
 unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
 work for SS capable ports and SS gadgets (we have quite a few of them,
 actually). You're missing the opportunity of charging at 900mA.
>>>
>>> I follow the DCP/SDP/CDP/ACA type's default current limitation and
>>> user can set them what they want.
>>
>> no, the user CANNOT set it to what they want. If you get enumerated
>> @100mA and the user just decides to set it to 2000mA, s/he could even
>> melt the USB connector. The kernel _must_ prevent such cases.
>>
>> In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
>> variable because if you enumerate in SS, you _can_ get up to 900mA.
>
> Make sense. But these are just default values. They can be changed
> safely by power driver with 'usb_charger_set_cur_limit_by_type()'
> function to set 900mA.

oh okay. Still, the default value should be a function of gadget->speed,
IMO ;-)

> +
> +/* USB charger state */
> +enum usb_charger_state {
> + USB_CHARGER_DEFAULT,
> + USB_CHARGER_PRESENT,
> + USB_CHARGER_REMOVE,
> +};

 userland really doesn't need these two ?
>>>
>>> We've reported to userspace by kobject_uevent in
>>> 'usb_charger_notify_others()' function.
>>
>> I mean as a type ;-) So userspace doesn't have to redefine these for
>> their applications.
>
> Make sense. I can introduce some sysfs files for userspace. Thanks for
> your comments.

okay, my reply was a bit cryptic, but what I mean here is that enum
usb_charger_state could be moved your include/uapi header. My question
is, then, does userland need to have knowledge of enum
usb_charger_state ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 31 March 2016 at 14:42, Felipe Balbi  wrote:
 +#define DEFAULT_CUR_PROTECT  (50)
>>>
>>> Where is this coming from ? Also, () are not necessary.
>>
>> Just want to protect the default current limitation. If that does not
>> need, I'll remove it.
>
> It's your HW :-) You tell me if it's really necessary. But, hey, if you
> get enumerated @500mA, this is the host telling you it _CAN_ give you
> 500mA. In that case, why wouldn't you ?

Make sense. I'll remove the 'DEFAULT_CUR_PROTECT' macro.

>
 +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>>>
>>> According to the spec we should always be talking about unit loads (1
>>> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
>>> work for SS capable ports and SS gadgets (we have quite a few of them,
>>> actually). You're missing the opportunity of charging at 900mA.
>>
>> I follow the DCP/SDP/CDP/ACA type's default current limitation and
>> user can set them what they want.
>
> no, the user CANNOT set it to what they want. If you get enumerated
> @100mA and the user just decides to set it to 2000mA, s/he could even
> melt the USB connector. The kernel _must_ prevent such cases.
>
> In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
> variable because if you enumerate in SS, you _can_ get up to 900mA.

Make sense. But these are just default values. They can be changed
safely by power driver with 'usb_charger_set_cur_limit_by_type()'
function to set 900mA.

>
 +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
 +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
 +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
 +#define UCHGER_STATE_LENGTH  (50)
>>>
>>> what is this UCHGER_STATE_LENGTH ? And also, why don't you spell it out?
>>> Is this weird name coming from a spec ? Which spec ?
>>
>> It is used to indicate the array size to save the charger state to
>> report to userspace. I should move it to where it is used.
>
> and ARRAY_SIZE(arr) is not enough ?

OK.

>
>>> sure this fits as a bus_type. There's no "usb charger" bus. There's USB
>>> bus and its VBUS/GND lines. Why are you using a bus_type here ?
>>
>> I want to use bus structure to manage the charger device. Maybe choose
>> class to manage them?
>
> I guess a class would fit better in this case.

OK.

>
 +{
 + return container_of(udev, struct usb_charger, dev);
 +}
 +
 +static ssize_t sdp_limit_show(struct device *dev,
 +   struct device_attribute *attr,
 +   char *buf)
 +{
 + struct usb_charger *uchger = dev_to_uchger(dev);
 +
 + return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
 +}
 +
 +static ssize_t sdp_limit_store(struct device *dev,
 +struct device_attribute *attr,
 +const char *buf, size_t count)
 +{
 + struct usb_charger *uchger = dev_to_uchger(dev);
 + unsigned int sdp_limit;
 + int ret;
 +
 + ret = kstrtouint(buf, 10, _limit);
 + if (ret < 0)
 + return ret;
 +
 + ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
 + if (ret < 0)
 + return ret;
 +
 + return count;
 +}
 +static DEVICE_ATTR_RW(sdp_limit);
>>>
>>> why RW ? Who's going to use these ? Also, you're not documenting this
>>> new sysfs file.
>>
>> Cause we have show and store operation for SDP type. If users want to
>> know or set the SDP current, they can use the sysfs file.
>> I'll add the documentation for it.
>
> but why would the user change it ? Here's the thing: you have a few
> posibilities for this:
>
> a) you are connected to a dedicated charger
>
> In this case, you can get up to 2000mA depending on the charger.
>
> If $this charger can give you or not 2000mA is not detectable,
> so what do charging ICs do ? They slowly increase the attached
> load accross VBUS/GND and measure VBUS value. When IC notices
> VBUS dropping bit, step back to previous load.
>
> This means you will always charger with maximum rating of DCP.
>
> Why would user change this ? More is unsafe, less is just
> stupid.
>
> b) you are connected to a host charging port and get enumerated with
> your 500mA configuration.
>
> you *know* 500mA is okay, but you _can_ get more (it is a
> charging port after all). So charging IC will connect a 500mA
> load and step upwards until VBUS drops a little, just like (a)
> above.
>
> This means you will always charger with maximum rating for this
> host charging port.
>
> Why would user change this ? More is unsafe, less is just
> stupid.
>
> c) you are connected to a standard port and get enumerated with your
> 500mA 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Baolin Wang  writes:
>>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>>> index af5d922..82a5b3c 100644
>>> --- a/drivers/usb/gadget/Kconfig
>>> +++ b/drivers/usb/gadget/Kconfig
>>> @@ -133,6 +133,13 @@ config U_SERIAL_CONSOLE
>>>   help
>>>  It supports the serial gadget can be used as a console.
>>>
>>> +config USB_CHARGER
>>> + bool "USB charger support"
>>> + help
>>> +   The usb charger driver based on the usb gadget that makes an
>>> +   enhancement to a power driver which can set the current limitation
>>> +   when the usb charger is added or removed.
>>
>> sure you don't depend on anything ?
>
> It just depends on USB_GADGET.

okay, that's cool :-)

>>> +
>>> +#define DEFAULT_CUR_PROTECT  (50)
>>
>> Where is this coming from ? Also, () are not necessary.
>
> Just want to protect the default current limitation. If that does not
> need, I'll remove it.

It's your HW :-) You tell me if it's really necessary. But, hey, if you
get enumerated @500mA, this is the host telling you it _CAN_ give you
500mA. In that case, why wouldn't you ?

>>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>>
>> According to the spec we should always be talking about unit loads (1
>> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
>> work for SS capable ports and SS gadgets (we have quite a few of them,
>> actually). You're missing the opportunity of charging at 900mA.
>
> I follow the DCP/SDP/CDP/ACA type's default current limitation and
> user can set them what they want.

no, the user CANNOT set it to what they want. If you get enumerated
@100mA and the user just decides to set it to 2000mA, s/he could even
melt the USB connector. The kernel _must_ prevent such cases.

In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
variable because if you enumerate in SS, you _can_ get up to 900mA.

>>> +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>>> +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>>> +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>>> +#define UCHGER_STATE_LENGTH  (50)
>>
>> what is this UCHGER_STATE_LENGTH ? And also, why don't you spell it out?
>> Is this weird name coming from a spec ? Which spec ?
>
> It is used to indicate the array size to save the charger state to
> report to userspace. I should move it to where it is used.

and ARRAY_SIZE(arr) is not enough ?

>>> +static DEFINE_IDA(usb_charger_ida);
>>> +static struct bus_type usb_charger_subsys = {
>>> + .name   = "usb-charger",
>>> + .dev_name   = "usb-charger",
>>> +};
>>> +
>>> +static struct usb_charger *dev_to_uchger(struct device *udev)
>>
>> nit-picking but I'd rather call this struct device *dev. Also, I'm not
>
> OK.
>
>> sure this fits as a bus_type. There's no "usb charger" bus. There's USB
>> bus and its VBUS/GND lines. Why are you using a bus_type here ?
>
> I want to use bus structure to manage the charger device. Maybe choose
> class to manage them?

I guess a class would fit better in this case.

>>> +{
>>> + return container_of(udev, struct usb_charger, dev);
>>> +}
>>> +
>>> +static ssize_t sdp_limit_show(struct device *dev,
>>> +   struct device_attribute *attr,
>>> +   char *buf)
>>> +{
>>> + struct usb_charger *uchger = dev_to_uchger(dev);
>>> +
>>> + return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
>>> +}
>>> +
>>> +static ssize_t sdp_limit_store(struct device *dev,
>>> +struct device_attribute *attr,
>>> +const char *buf, size_t count)
>>> +{
>>> + struct usb_charger *uchger = dev_to_uchger(dev);
>>> + unsigned int sdp_limit;
>>> + int ret;
>>> +
>>> + ret = kstrtouint(buf, 10, _limit);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + return count;
>>> +}
>>> +static DEVICE_ATTR_RW(sdp_limit);
>>
>> why RW ? Who's going to use these ? Also, you're not documenting this
>> new sysfs file.
>
> Cause we have show and store operation for SDP type. If users want to
> know or set the SDP current, they can use the sysfs file.
> I'll add the documentation for it.

but why would the user change it ? Here's the thing: you have a few
posibilities for this:

a) you are connected to a dedicated charger

In this case, you can get up to 2000mA depending on the charger.

If $this charger can give you or not 2000mA is not detectable,
so what do charging ICs do ? They slowly increase the attached
load accross VBUS/GND and measure VBUS value. When IC notices
VBUS dropping bit, step back to previous load.

This means you will always charger with maximum rating of DCP.

Why would 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 30 March 2016 at 18:09, Felipe Balbi  wrote:
>> ---
>>  drivers/usb/gadget/Kconfig  |7 +
>>  drivers/usb/gadget/Makefile |1 +
>>  drivers/usb/gadget/charger.c|  669 
>> +++
>
> It seems to me this should be part of udc-core's functionality. Maybe
> move this to drivers/usb/gadget/udc and statically link it to
> udc-core.ko ?

OK.

>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index af5d922..82a5b3c 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -133,6 +133,13 @@ config U_SERIAL_CONSOLE
>>   help
>>  It supports the serial gadget can be used as a console.
>>
>> +config USB_CHARGER
>> + bool "USB charger support"
>> + help
>> +   The usb charger driver based on the usb gadget that makes an
>> +   enhancement to a power driver which can set the current limitation
>> +   when the usb charger is added or removed.
>
> sure you don't depend on anything ?

It just depends on USB_GADGET.

>
>> +
>> +#define DEFAULT_CUR_PROTECT  (50)
>
> Where is this coming from ? Also, () are not necessary.

Just want to protect the default current limitation. If that does not
need, I'll remove it.

>
>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>
> According to the spec we should always be talking about unit loads (1
> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
> work for SS capable ports and SS gadgets (we have quite a few of them,
> actually). You're missing the opportunity of charging at 900mA.

I follow the DCP/SDP/CDP/ACA type's default current limitation and
user can set them what they want.

>
>> +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
>> +#define UCHGER_STATE_LENGTH  (50)
>
> what is this UCHGER_STATE_LENGTH ? And also, why don't you spell it out?
> Is this weird name coming from a spec ? Which spec ?

It is used to indicate the array size to save the charger state to
report to userspace. I should move it to where it is used.

>
>> +static DEFINE_IDA(usb_charger_ida);
>> +static struct bus_type usb_charger_subsys = {
>> + .name   = "usb-charger",
>> + .dev_name   = "usb-charger",
>> +};
>> +
>> +static struct usb_charger *dev_to_uchger(struct device *udev)
>
> nit-picking but I'd rather call this struct device *dev. Also, I'm not

OK.

> sure this fits as a bus_type. There's no "usb charger" bus. There's USB
> bus and its VBUS/GND lines. Why are you using a bus_type here ?

I want to use bus structure to manage the charger device. Maybe choose
class to manage them?

>
>> +{
>> + return container_of(udev, struct usb_charger, dev);
>> +}
>> +
>> +static ssize_t sdp_limit_show(struct device *dev,
>> +   struct device_attribute *attr,
>> +   char *buf)
>> +{
>> + struct usb_charger *uchger = dev_to_uchger(dev);
>> +
>> + return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
>> +}
>> +
>> +static ssize_t sdp_limit_store(struct device *dev,
>> +struct device_attribute *attr,
>> +const char *buf, size_t count)
>> +{
>> + struct usb_charger *uchger = dev_to_uchger(dev);
>> + unsigned int sdp_limit;
>> + int ret;
>> +
>> + ret = kstrtouint(buf, 10, _limit);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return count;
>> +}
>> +static DEVICE_ATTR_RW(sdp_limit);
>
> why RW ? Who's going to use these ? Also, you're not documenting this
> new sysfs file.

Cause we have show and store operation for SDP type. If users want to
know or set the SDP current, they can use the sysfs file.
I'll add the documentation for it.

>
>> +static ssize_t dcp_limit_show(struct device *dev,
>> +   struct device_attribute *attr,
>> +   char *buf)
>> +{
>> + struct usb_charger *uchger = dev_to_uchger(dev);
>> +
>> + return sprintf(buf, "%d\n", uchger->cur_limit.dcp_cur_limit);
>> +}
>> +
>> +static ssize_t dcp_limit_store(struct device *dev,
>> +struct device_attribute *attr,
>> +const char *buf, size_t count)
>> +{
>> + struct usb_charger *uchger = dev_to_uchger(dev);
>> + unsigned int dcp_limit;
>> + int ret;
>> +
>> + ret = kstrtouint(buf, 10, _limit);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = usb_charger_set_cur_limit_by_type(uchger, DCP_TYPE, dcp_limit);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return count;
>> +}
>> +static DEVICE_ATTR_RW(dcp_limit);
>
> likewise, why RW ? 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Mark Brown  writes:
> [ text/plain ]
> On Wed, Mar 30, 2016 at 01:09:00PM +0300, Felipe Balbi wrote:
>> Baolin Wang  writes:
>
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>
>> not very nice to depend on either of or platform_device here. What about
>> PCI-based devices ?
>
> The header inclusion shouldn't be conditional though.  But looking at
> the patch I can't immediately see any use of these in the code anyway.

fair enough, seems like removal is the way.

>> > +static DEVICE_ATTR_RW(sdp_limit);
>
>> why RW ? Who's going to use these ? Also, you're not documenting this
>> new sysfs file.
>
> If they end up not writeable should we just remove them entirely since
> they should just be the spec values?

if they are really just spec values, why would even let them be modified
to start with ? ;-)

But yeah, seems like this is not interesting to userland.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Mark Brown]

On Wed, Mar 30, 2016 at 01:09:00PM +0300, Felipe Balbi wrote:
> Baolin Wang  writes:

> > +#include 
> > +#include 
> > +#include 
> > +#include 

> not very nice to depend on either of or platform_device here. What about
> PCI-based devices ?

The header inclusion shouldn't be conditional though.  But looking at
the patch I can't immediately see any use of these in the code anyway.

> > +static DEVICE_ATTR_RW(sdp_limit);

> why RW ? Who's going to use these ? Also, you're not documenting this
> new sysfs file.

If they end up not writeable should we just remove them entirely since
they should just be the spec values?


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> This patch introduces the usb charger driver based on usb gadget that
> makes an enhancement to a power driver. It works well in practice but
> that requires a system with suitable hardware.
>
> The basic conception of the usb charger is that, when one usb charger
> is added or removed by reporting from the usb gadget state change or
> the extcon device state change, the usb charger will report to power
> user to set the current limitation.
>
> The usb charger will register notifiees on the usb gadget or the extcon
> device to get notified the usb charger state. It also supplies the
> notification mechanism to userspace When the usb charger state is changed.
>
> Power user will register a notifiee on the usb charger to get notified
> by status changes from the usb charger. It will report to power user
> to set the current limitation when detecting the usb charger is added
> or removed from extcon device state or usb gadget state.
>
> This patch doesn't yet integrate with the gadget code, so some functions
> which rely on the 'gadget' are not completed, that will be implemented
> in the following patches.
>
> Signed-off-by: Baolin Wang 
> ---
>  drivers/usb/gadget/Kconfig  |7 +
>  drivers/usb/gadget/Makefile |1 +
>  drivers/usb/gadget/charger.c|  669 
> +++

It seems to me this should be part of udc-core's functionality. Maybe
move this to drivers/usb/gadget/udc and statically link it to
udc-core.ko ?

> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index af5d922..82a5b3c 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -133,6 +133,13 @@ config U_SERIAL_CONSOLE
>   help
>  It supports the serial gadget can be used as a console.
>  
> +config USB_CHARGER
> + bool "USB charger support"
> + help
> +   The usb charger driver based on the usb gadget that makes an
> +   enhancement to a power driver which can set the current limitation
> +   when the usb charger is added or removed.

sure you don't depend on anything ?

> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
> index 598a67d..1e421c1 100644
> --- a/drivers/usb/gadget/Makefile
> +++ b/drivers/usb/gadget/Makefile
> @@ -10,3 +10,4 @@ libcomposite-y  := usbstring.o config.o 
> epautoconf.o
>  libcomposite-y   += composite.o functions.o configfs.o 
> u_f.o
>  
>  obj-$(CONFIG_USB_GADGET) += udc/ function/ legacy/
> +obj-$(CONFIG_USB_CHARGER)+= charger.o
> diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
> new file mode 100644
> index 000..82a9973
> --- /dev/null
> +++ b/drivers/usb/gadget/charger.c
> @@ -0,0 +1,669 @@
> +/*
> + * charger.c -- USB charger driver
> + *
> + * Copyright (C) 2015 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

not very nice to depend on either of or platform_device here. What about
PCI-based devices ?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DEFAULT_CUR_PROTECT  (50)

Where is this coming from ? Also, () are not necessary.

> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)

According to the spec we should always be talking about unit loads (1
unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
work for SS capable ports and SS gadgets (we have quite a few of them,
actually). You're missing the opportunity of charging at 900mA.

> +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
> +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
> +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
> +#define UCHGER_STATE_LENGTH  (50)

what is this UCHGER_STATE_LENGTH ? And also, why don't you spell it out?
Is this weird name coming from a spec ? Which spec ?

> +static DEFINE_IDA(usb_charger_ida);
> +static struct bus_type usb_charger_subsys = {
> + .name   = "usb-charger",
> + .dev_name   = "usb-charger",
> +};
> +
> +static struct usb_charger *dev_to_uchger(struct device *udev)

nit-picking but I'd rather call this struct device *dev. Also, I'm not
sure this fits as a bus_type. There's no "usb charger" bus. There's USB
bus and its VBUS/GND lines. Why are you using a bus_type here ?

> +{
> + return container_of(udev, struct usb_charger, dev);
> +}
> +
> +static ssize_t sdp_limit_show(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> + struct usb_charger *uchger = dev_to_uchger(dev);

[PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig  |7 +
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/charger.c|  669 +++
 include/linux/usb/usb_charger.h |  164 ++
 4 files changed, 841 insertions(+)
 create mode 100644 drivers/usb/gadget/charger.c
 create mode 100644 include/linux/usb/usb_charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index af5d922..82a5b3c 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -133,6 +133,13 @@ config U_SERIAL_CONSOLE
help
   It supports the serial gadget can be used as a console.
 
+config USB_CHARGER
+   bool "USB charger support"
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 598a67d..1e421c1 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -10,3 +10,4 @@ libcomposite-y:= usbstring.o config.o 
epautoconf.o
 libcomposite-y += composite.o functions.o configfs.o u_f.o
 
 obj-$(CONFIG_USB_GADGET)   += udc/ function/ legacy/
+obj-$(CONFIG_USB_CHARGER)  += charger.o
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..82a9973
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,669 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_CUR_PROTECT(50)
+#define DEFAULT_SDP_CUR_LIMIT  (500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define UCHGER_STATE_LENGTH(50)
+
+static DEFINE_IDA(usb_charger_ida);
+static struct bus_type usb_charger_subsys = {
+   .name   = "usb-charger",
+   .dev_name   = "usb-charger",
+};
+
+static struct usb_charger *dev_to_uchger(struct device *udev)
+{
+   return container_of(udev, struct usb_charger, dev);
+}
+
+static ssize_t sdp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
+}
+
+static ssize_t sdp_limit_store(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   unsigned int sdp_limit;
+   int ret;
+
+   ret = kstrtouint(buf, 10, _limit);
+   if (ret < 0)
+   return ret;
+
+   ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+static DEVICE_ATTR_RW(sdp_limit);
+
+static ssize_t dcp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.dcp_cur_limit);
+}
+
+static ssize_t 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Oliver Neukum]

On Wed, 2016-03-16 at 19:46 +0800, Baolin Wang wrote:
> This patch introduces the usb charger driver based on usb gadget that
> makes an enhancement to a power driver. It works well in practice but
> that requires a system with suitable hardware.
> 
> The basic conception of the usb charger is that, when one usb charger
> is added or removed by reporting from the usb gadget state change or
> the extcon device state change, the usb charger will report to power
> user to set the current limitation.

This patch adds sysfs attributes without adding Documentation for them.
That's bad.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 16 March 2016 at 20:09, Oliver Neukum  wrote:
> On Wed, 2016-03-16 at 19:46 +0800, Baolin Wang wrote:
>> This patch introduces the usb charger driver based on usb gadget that
>> makes an enhancement to a power driver. It works well in practice but
>> that requires a system with suitable hardware.
>>
>> The basic conception of the usb charger is that, when one usb charger
>> is added or removed by reporting from the usb gadget state change or
>> the extcon device state change, the usb charger will report to power
>> user to set the current limitation.
>
> This patch adds sysfs attributes without adding Documentation for them.
> That's bad.

I'll add Documentation for the sysfs attributes in next version
patchset. Thanks for your comments.

-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig  |7 +
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/charger.c|  669 +++
 include/linux/usb/usb_charger.h |  164 ++
 4 files changed, 841 insertions(+)
 create mode 100644 drivers/usb/gadget/charger.c
 create mode 100644 include/linux/usb/usb_charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 33834aa..8d69dca 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,13 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
   a module parameter as well.
   If unsure, say 2.
 
+config USB_CHARGER
+   bool "USB charger support"
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 598a67d..1e421c1 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -10,3 +10,4 @@ libcomposite-y:= usbstring.o config.o 
epautoconf.o
 libcomposite-y += composite.o functions.o configfs.o u_f.o
 
 obj-$(CONFIG_USB_GADGET)   += udc/ function/ legacy/
+obj-$(CONFIG_USB_CHARGER)  += charger.o
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..82a9973
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,669 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_CUR_PROTECT(50)
+#define DEFAULT_SDP_CUR_LIMIT  (500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define UCHGER_STATE_LENGTH(50)
+
+static DEFINE_IDA(usb_charger_ida);
+static struct bus_type usb_charger_subsys = {
+   .name   = "usb-charger",
+   .dev_name   = "usb-charger",
+};
+
+static struct usb_charger *dev_to_uchger(struct device *udev)
+{
+   return container_of(udev, struct usb_charger, dev);
+}
+
+static ssize_t sdp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
+}
+
+static ssize_t sdp_limit_store(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   unsigned int sdp_limit;
+   int ret;
+
+   ret = kstrtouint(buf, 10, _limit);
+   if (ret < 0)
+   return ret;
+
+   ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+static DEVICE_ATTR_RW(sdp_limit);
+
+static ssize_t dcp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.dcp_cur_limit);
+}
+
+static ssize_t 

[PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig  |7 +
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/charger.c|  669 +++
 include/linux/usb/usb_charger.h |  164 ++
 4 files changed, 841 insertions(+)
 create mode 100644 drivers/usb/gadget/charger.c
 create mode 100644 include/linux/usb/usb_charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 33834aa..8d69dca 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,13 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
   a module parameter as well.
   If unsure, say 2.
 
+config USB_CHARGER
+   bool "USB charger support"
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 598a67d..1e421c1 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -10,3 +10,4 @@ libcomposite-y:= usbstring.o config.o 
epautoconf.o
 libcomposite-y += composite.o functions.o configfs.o u_f.o
 
 obj-$(CONFIG_USB_GADGET)   += udc/ function/ legacy/
+obj-$(CONFIG_USB_CHARGER)  += charger.o
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..82a9973
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,669 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_CUR_PROTECT(50)
+#define DEFAULT_SDP_CUR_LIMIT  (500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define UCHGER_STATE_LENGTH(50)
+
+static DEFINE_IDA(usb_charger_ida);
+static struct bus_type usb_charger_subsys = {
+   .name   = "usb-charger",
+   .dev_name   = "usb-charger",
+};
+
+static struct usb_charger *dev_to_uchger(struct device *udev)
+{
+   return container_of(udev, struct usb_charger, dev);
+}
+
+static ssize_t sdp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
+}
+
+static ssize_t sdp_limit_store(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   unsigned int sdp_limit;
+   int ret;
+
+   ret = kstrtouint(buf, 10, _limit);
+   if (ret < 0)
+   return ret;
+
+   ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+static DEVICE_ATTR_RW(sdp_limit);
+
+static ssize_t dcp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.dcp_cur_limit);
+}
+
+static ssize_t