Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1242561 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 1/5] gadget: Introduce the notifier functions Pavel Machek <pavel@ucw.cz> - 2015-10-08 18:00 +0200
    Re: [PATCH v4 1/5] gadget: Introduce the notifier functions Felipe Balbi <balbi@ti.com> - 2015-10-09 23:20 +0200
      Re: [PATCH v4 1/5] gadget: Introduce the notifier functions Mark Brown <broonie@kernel.org> - 2015-10-12 19:00 +0200

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

HI!

> > +	int ret;
> > +
> > +	mutex_lock(&gadget->lock);
> > +	ret = raw_notifier_chain_unregister(&gadget->nh, nb);
> 
> Greg, this is the kind of thing I wanted to avoid adding more of.
> 
> I was wondering if you would accept subsystems using kdbus for
> this sort of notification. I'm okay waiting for kdbus for another
> couple merge windows (if we have to) before that's merged, but
> if we take this raw notifier approach now, we will end up having
> to support it forever.
> 
> Also, because soon enough we will have to support USB Power Delivery
> with Type C connector, this is bound to change in the coming months.
> 
> Frankly, I wanted all of this to be decided in userland with the
> kernel just providing notification and basic safety checks (we don't
> want to allow a bogus userspace daemon frying anybody's devices).
> 
> How would you feel about that ?

So init=/bin/bash boot no longer provides machine that charges itself?

That would be bad. Traditionally, hardware controls battery charging,
and if hardware needs some help, we should do it in kernel, to mask
the difference from userspace.
								Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1243663

[Multipart message — attachments visible in raw view] — view raw

Hi,

Pavel Machek <pavel@ucw.cz> writes:
> HI!
>
>> > +	int ret;
>> > +
>> > +	mutex_lock(&gadget->lock);
>> > +	ret = raw_notifier_chain_unregister(&gadget->nh, nb);
>> 
>> Greg, this is the kind of thing I wanted to avoid adding more of.
>> 
>> I was wondering if you would accept subsystems using kdbus for
>> this sort of notification. I'm okay waiting for kdbus for another
>> couple merge windows (if we have to) before that's merged, but
>> if we take this raw notifier approach now, we will end up having
>> to support it forever.
>> 
>> Also, because soon enough we will have to support USB Power Delivery
>> with Type C connector, this is bound to change in the coming months.
>> 
>> Frankly, I wanted all of this to be decided in userland with the
>> kernel just providing notification and basic safety checks (we don't
>> want to allow a bogus userspace daemon frying anybody's devices).
>> 
>> How would you feel about that ?
>
> So init=/bin/bash boot no longer provides machine that charges itself?
>
> That would be bad. Traditionally, hardware controls battery charging,
> and if hardware needs some help, we should do it in kernel, to mask
> the difference from userspace.

this is a very valid point which I hadn't considered :-)

Seems like kernel it is, no matter how easy or how difficult it gets.

Mark, when can we try to have a discussion about how to get this
upstream ? It seems like designing everything in the mailing list will
just take forever. Any ideas ?

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1244915

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 09, 2015 at 04:17:27PM -0500, Felipe Balbi wrote:

> Mark, when can we try to have a discussion about how to get this
> upstream ? It seems like designing everything in the mailing list will
> just take forever. Any ideas ?

Can we take this off-list?  I'm in the UK, Baolin is in China and I
believe you're in the US so it might be a fun one to schedule...

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web