Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

Hi,

On Mon, Oct 05, 2015 at 05:18:33PM +0100, Mark Brown wrote:

On Mon, Oct 05, 2015 at 10:15:11AM -0500, Felipe Balbi wrote:

quoted

On Sun, Oct 04, 2015 at 11:55:06PM +0100, Mark Brown wrote:

quoted

quoted

The trouble is getting traction on adoption.  Vendors have a habit of doing
things like finding problems and rather than reporting them deciding that the
open source solution isn't great and going and writing their own thing
(especially when they're in stealth mode) rather than talking to anyone.
Sometimes we manage to avoid that but it can be challenging, and often we only
even hear about the new thing after it's shipping and there's a lot of inertia
behind changing it.  The kernel ABIs tend to be a lot sticker than userspace
things here.

quoted

but this is not a solid enough argument to push anything into the kernel.

To my mind it is a concern when considering design - it's not the only
consideration certainly but it should influence if or how we split
things.

sure

quoted

quoted

quoted

the same thing will happen with Type-C and power delivery. There won't be tuning
to taste, of course :-) But there will be "very different ideas what what you
want to do with" your charging methodology.

quoted

quoted

Are those very different things about the use cases ("don't bother with
high speed data, get all the power you can" or whatever) or are they
about the details of the board?

quoted

I'm pretty sure there will be interesting designs in the market. I'm pretty sure
there will be type-C systems which won't support USB 3.1 for example, even
though they'll support USB Power Delivery in its entirety.

That's sounding like generic USB stuff to me.

quoted

quoted

Yes, definitely - my experience both in terms of watching how people
like handset vendors often work internally and in terms of getting
things adopted is that it's a lot easier if you can have one component
you need to update to handle new hardware rather than multiple ones that
need to be upgraded for things that are purely board differences.

quoted

IMO, just because you have it in the kernel, it doesn't mean it'll be
adopted. Look at pm_runtime, for example; it's a very nice API and, yet, not
used by Android (or has that changed ?)

That's always been a bit of a myth - most Android systems use runtime PM
extensively when they're running, the discussion is really about the
edge case where you're idling the system.  The Android suspend behaviour
is about the system idle case and is as much about providing a simple
way to go into an idle state, especially bearing in mind that they have
apps installed from the app store there, as anything else.  It's the
making sure things are idle part of things that's different.

okay

quoted

quoted

quoted

okay, this is a fair point :-) I just don't see, as of now at least, how we can
get to that in a way that's somewhat future-proof. It seems like we will
add more and more notifications until we can't maintain this anymore.

quoted

quoted

So we need to look at the new/upcoming USB specs and understand the

quoted

not upcoming, it's already out there.

I assume there's ongoing work on further revisions to the spec though?

that'd be a correct assumption

quoted

quoted

Does the problem not get easier if we break it down to just the charger
elements and realise that the USB C modes are going to have a lot more
policy in them?

quoted

the thing with USB C is that it's not only for negotiating a charging power
(with power delivery you're not necessarily tied to 5V, btw), that very stack
will also be used to change to other alternate modes, and those can be anything:
Thunderbolt, PCIe, DisplayPort, etc.

Surely these features have sufficient orthogonality to allow us to split
things up and deal with some of the problems while providing spaces for
future work?

yeah, might. As long as we keep that voice in our heads that things are likely
to change.

-- 
balbi