On Tue, Apr 10, 2018 at 02:40:29PM -0600, Theo de Raadt wrote:
> >On Mon, Apr 09, 2018 at 11:11:22AM -0600, Theo de Raadt wrote:
> >> I think this approach is wrong, insane, and fragile. DVF_ACTIVE
> >> doesn't work precisely that way.
> >
> >Yes, it's a hack, but i don't see it as fragile, nor in
>On Mon, Apr 09, 2018 at 11:11:22AM -0600, Theo de Raadt wrote:
>> I think this approach is wrong, insane, and fragile. DVF_ACTIVE
>> doesn't work precisely that way.
>
>Yes, it's a hack, but i don't see it as fragile, nor insane,
>and i agree something better is great, but it does work exactly
>a
On Mon, Apr 09, 2018 at 11:11:22AM -0600, Theo de Raadt wrote:
> I think this approach is wrong, insane, and fragile. DVF_ACTIVE
> doesn't work precisely that way.
Yes, it's a hack, but i don't see it as fragile, nor insane,
and i agree something better is great, but it does work exactly
as i wan
I think this approach is wrong, insane, and fragile. DVF_ACTIVE
doesn't work precisely that way.
A better approach would be a whole-tree change such that attach
functions are non-void. This has been proposed a few times, but
noone ever sat down and did the whole-tree work.
> could we allow conf
Hi,
could we allow config_attach() to 'fail' without leaving dead device behind?
ie. with gpioow(4) it's easy to make a load of these while testing stuff,
which does lead to inconsistent unit numbering unless you manually detach
the broken ones before attaching another..
for devices which are fou
