On Jun 15 2017 or thereabouts, Jiri Kosina wrote:
> On Tue, 13 Jun 2017, Benjamin Tissoires wrote:
>
> > BTW, the merge with your for-next branch is going to be tricky :(
>
> I've just pushed the for-next merge. Second/third pair of eyes (scripted
> eyes even better :) ) would be appreciated.
>
On Tue, 13 Jun 2017, Benjamin Tissoires wrote:
> BTW, the merge with your for-next branch is going to be tricky :(
I've just pushed the for-next merge. Second/third pair of eyes (scripted
eyes even better :) ) would be appreciated.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from
On Tue, 13 Jun 2017, Benjamin Tissoires wrote:
> > I tried to cook some script that formats the list in the same way than
> > yours.
> >
> > I just noticed that you have in CONFIG_HID_CHICONY:
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
> > while in v4.12-rc5
On Jun 13 2017 or thereabouts, Benjamin Tissoires wrote:
> On Jun 13 2017 or thereabouts, Jiri Kosina wrote:
> > So I've now pushed the latest version to 'for-4.12/driver-matching-fix' of
> > hid.git, and if no more issues are discovered, I'll push that to Linus
> > this week so that we finally
On Jun 13 2017 or thereabouts, Jiri Kosina wrote:
> So I've now pushed the latest version to 'for-4.12/driver-matching-fix' of
> hid.git, and if no more issues are discovered, I'll push that to Linus
> this week so that we finally get rid of this long-lasting PITA (while
> still heading towards
On Fri, 9 Jun 2017, Hans de Goede wrote:
> So I've decided to just go ahead and give this patch a second pair
> of eyes, it is mostly good, but I did find some issues, comments
> inline.
Thanks for all the comments, highly appreciated.
[ ... snipped the ones that have been put into v2 ... ]
>
Hi,
On 09-06-17 13:25, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
From:
Hi,
On 09-06-17 15:00, Benjamin Tissoires wrote:
On Jun 09 2017 or thereabouts, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go
On Jun 09 2017 or thereabouts, Jiri Kosina wrote:
> On Fri, 9 Jun 2017, Jiri Kosina wrote:
>
> > This is something I've been wanting to fix for ages, but never really got
> > to it. So let's take this as the final impulse to do it.
>
> So I'd suggest to go with something like the below for
Hi,
On 09-06-17 13:25, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
Looks
On Fri, 9 Jun 2017, Jiri Kosina wrote:
> This is something I've been wanting to fix for ages, but never really got
> to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
From: Jiri Kosina
Subject:
Bjørn Mork writes:
> But I should probably go google now, before I repeat too mcuh of the
> previous discussions ;-)
I guess this is the previous proposal: https://lwn.net/Articles/121227/
and discussion: http://lkml.iu.edu/hypermail/linux/kernel/0502.1/index.html#0438
The
Greg KH writes:
> On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote:
>> Greg KH writes:
>>
>> > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
>> >> Longer-term, we'd ideally make 'generic' driver special and let it attach
>> >> as a 'last
On Jun 09 2017 or thereabouts, Greg KH wrote:
> On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote:
> > Greg KH writes:
> >
> > > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
> > >> Longer-term, we'd ideally make 'generic' driver special and let it
> > >>
On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote:
> Greg KH writes:
>
> > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
> >> Longer-term, we'd ideally make 'generic' driver special and let it attach
> >> as a 'last resort driver' if none of the specific
Hi,
On 09-06-17 10:52, Bjørn Mork wrote:
Greg KH writes:
On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
Longer-term, we'd ideally make 'generic' driver special and let it attach
as a 'last resort driver' if none of the specific driver picked the device
up
Greg KH writes:
> On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
>> Longer-term, we'd ideally make 'generic' driver special and let it attach
>> as a 'last resort driver' if none of the specific driver picked the device
>> up during probe. But I don't think our
On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote:
> Longer-term, we'd ideally make 'generic' driver special and let it attach
> as a 'last resort driver' if none of the specific driver picked the device
> up during probe. But I don't think our current driver model allows this
>
On Fri, 9 Jun 2017, Hans de Goede wrote:
> Right, so this is not really a problem with this specific patch, but
> with how the hid_have_special_driver array works in general currently it
> has very few #if IS_ENABLED(CONFIG_FOO) guards around all the devices it
> blacklists the generic HID
Hi,
First of all lets add the HID subsys maintainers to the To list (done).
On 08-06-17 22:17, Linus Torvalds wrote:
On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote:
So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans
to straighten this out.
On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote:
>
> So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans
> to straighten this out.
No, I think the main problem is that the hid_have_special_driver[]
array change is garbage.
It adds the ASUS ID,
On Thu, 8 Jun 2017, Alan Cox wrote:
> > Normally in this situation I'd recommend bisection. However, this case
> > may be simple enough for a usbmon trace to provide the answer.
>
> With a shared file system between the T100TA and a big machine it's not
> too hard to do some builds:
>
> commit
> Normally in this situation I'd recommend bisection. However, this case
> may be simple enough for a usbmon trace to provide the answer.
With a shared file system between the T100TA and a big machine it's not
too hard to do some builds:
commit 76dd1fbebbaebab294dc09230960238746b883b1
is the
On Wed, 7 Jun 2017, Alan Cox wrote:
> On Wed, 7 Jun 2017 18:07:44 +0200
> Greg KH wrote:
>
> > On Wed, Jun 07, 2017 at 04:27:30PM +0100, Alan Cox wrote:
> > > Booting 4.12-rc gives you a machine where neither the keyboard or the
> > > mouse of the base-station work.
> > >
> > >
On Wed, 7 Jun 2017 18:07:44 +0200
Greg KH wrote:
> On Wed, Jun 07, 2017 at 04:27:30PM +0100, Alan Cox wrote:
> > Booting 4.12-rc gives you a machine where neither the keyboard or the
> > mouse of the base-station work.
> >
> > Other USB devices work - including plugging in an
On Wed, Jun 07, 2017 at 04:27:30PM +0100, Alan Cox wrote:
> Booting 4.12-rc gives you a machine where neither the keyboard or the
> mouse of the base-station work.
>
> Other USB devices work - including plugging in an external USB keyboard
> and mouse.
>
> Removing the basestation and replugging
Booting 4.12-rc gives you a machine where neither the keyboard or the
mouse of the base-station work.
Other USB devices work - including plugging in an external USB keyboard
and mouse.
Removing the basestation and replugging it has no effect.
The base station is seen in lsusb.
Bus 001 Device
27 matches
Mail list logo