[PATCH]

[Yuta Kobayashi]

This patch provides definition of Microsoft Type Cover Pro 4 (JP).

---
 drivers/hid/hid-core.c  | 2 ++
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/hid-microsoft.c | 2 ++
 drivers/hid/usbhid/hid-quirks.c | 1 +
 4 files changed, 6 insertions(+)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 4f9c5c6..98f752a 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -727,6 +727,7 @@ static void hid_scan_collection(struct hid_parser *parser, 
unsigned type)
(hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
 hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 ||
 hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
+hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP ||
 hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
 hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
hid->group == HID_GROUP_MULTITOUCH)
@@ -1978,6 +1979,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_600) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0238f01..7b725d6 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -695,6 +695,7 @@
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_30x07dc
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2  0x07e2
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
+#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP 0x07e9
 #define USB_DEVICE_ID_MS_TYPE_COVER_30x07de
 #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
 
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index e924d55..56c586f 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -288,6 +288,8 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
.driver_data = MS_HIDINPUT },
+   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP),
+   .driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3),
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 53fc856..7f4cecd 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -93,6 +93,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, 
HID_QUIRK_NO_INIT_REPORTS },
+   { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
-- 
2.5.5
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: error building master branch

[Laura Abbott]

On 08/09/2016 03:34 AM, Nicolas Chauvet wrote:

2016-08-08 16:58 GMT+02:00 Laura Abbott :

On 08/08/2016 01:39 AM, Thorsten Leemhuis wrote:


Lo! Mr. Aappddeevv wrote on 08.08.2016 03:47:


I am encountering compile errors building off master. My build system
is f24. Any thoughts? I did some google searches but could not find
anyone else that had the same problem.

One of the errors is below:

 pushd tools/iio/

~/proj/kernel/kernel-4.7.fc26/linux-4.8.0-0.rc0.git7.2.local.fc26.x86_64/tools/iio
~/proj/kernel/kernel-4.7.fc26/linux-4.8.0-0.rc0.git7.2.local.fc26.x86_64
+ make
make[1]: Entering directory
'/home/me/proj/kernel/kernel-4.7.fc26/linux-4.8.0-0.rc0.git7.2.local.fc26.x86_64/tools/iio'
gcc -Wall -g -D_GNU_SOURCE   -c -o iio_event_monitor.o
iio_event_monitor.c
iio_event_monitor.c:58:3: error: 'IIO_PH' undeclared here (not in a
function)
  [IIO_PH] = "ph",



I ran into this issue when building 4.8-pre for F23 and F24
(https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories ). If you
want to just circumvent this problem install the kernel-headers package
from at least 4.7 (from my repos or the kernel-stabilization repo) in
your build environment. Those headers contain everything that is needed
to compile the iio tools from 4.8-pre. I haven't reported the problem
upstream yet (-ELACKOFTIME) :-/

CU, thl




Yes, installing the new headers is the correct solution. Several of
the #defines for the IIO tools came in for 4.7. Since this is a


It would be better for the userspace tools to use the headers from the
kernel source tree instead of those from the "previous" kernel-headers
package.
This will lead to a bootstraping issue if that's not the case. Or is
there any reason why it's must use system installed headers ?

Thx





The tools aren't necessary for building the kernel itself so I don't
think there is a bootstrapping issue in the upstream project. I see
your point though and other userspace tools do use the kernel headers.
You're welcome to bring this up with the upstream maintainers and/or
submit a patch. If the patch gets acked we can bring it in.

Thanks,
Laura
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: fedora.git upstream 0-Day build testing

[Laura Abbott]

On 08/09/2016 11:32 AM, Josh Boyer wrote:

Hi kernel people,

Recently the upstream 0-Day build testing project started building the
exploded kernel git tree for Fedora on kernel.org:

https://git.kernel.org/cgit/linux/kernel/git/jwboyer/fedora.git/

That was somewhat of a surprise.  It has found a few things here and
there, mostly in building for configurations or architectures that
Fedora does not support.  Sometimes this causes maintainers to be
mailed about build failures somewhat unexpectedly.  The most recent
case as the crash driver on openrisc.

The 0-Day maintainer said they can disable it, but I wanted to run it
past the team first.  I can see value in doing it, even if it isn't
directly applicable to Fedora itself at the moment.  Thoughts?

josh


I'm for this if we can limit it to only arches Fedora supports. Even if
Fedora doesn't officially support some of the configurations right now
it could in the future and compiling is a pretty low bar.

Thanks,
Laura
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: fedora.git upstream 0-Day build testing

[Justin Forbes]

On Tue, Aug 9, 2016 at 1:46 PM, Josh Boyer 
wrote:

> On Tue, Aug 9, 2016 at 2:32 PM, Josh Boyer 
> wrote:
> > Hi kernel people,
> >
> > Recently the upstream 0-Day build testing project started building the
> > exploded kernel git tree for Fedora on kernel.org:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/jwboyer/fedora.git/
> >
> > That was somewhat of a surprise.  It has found a few things here and
> > there, mostly in building for configurations or architectures that
> > Fedora does not support.  Sometimes this causes maintainers to be
> > mailed about build failures somewhat unexpectedly.  The most recent
> > case as the crash driver on openrisc.
> >
> > The 0-Day maintainer said they can disable it, but I wanted to run it
> > past the team first.  I can see value in doing it, even if it isn't
> > directly applicable to Fedora itself at the moment.  Thoughts?
>
> Follow up: Fengguang Wu points out that it can be enabled only for
> specific ARCH as well.  So that's a possibility.


Running only on specific ARCH would be handy.  If that can be maintained.

Justin
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: fedora.git upstream 0-Day build testing

[Josh Boyer]

On Tue, Aug 9, 2016 at 2:32 PM, Josh Boyer  wrote:
> Hi kernel people,
>
> Recently the upstream 0-Day build testing project started building the
> exploded kernel git tree for Fedora on kernel.org:
>
> https://git.kernel.org/cgit/linux/kernel/git/jwboyer/fedora.git/
>
> That was somewhat of a surprise.  It has found a few things here and
> there, mostly in building for configurations or architectures that
> Fedora does not support.  Sometimes this causes maintainers to be
> mailed about build failures somewhat unexpectedly.  The most recent
> case as the crash driver on openrisc.
>
> The 0-Day maintainer said they can disable it, but I wanted to run it
> past the team first.  I can see value in doing it, even if it isn't
> directly applicable to Fedora itself at the moment.  Thoughts?

Follow up: Fengguang Wu points out that it can be enabled only for
specific ARCH as well.  So that's a possibility.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

fedora.git upstream 0-Day build testing

[Josh Boyer]

Hi kernel people,

Recently the upstream 0-Day build testing project started building the
exploded kernel git tree for Fedora on kernel.org:

https://git.kernel.org/cgit/linux/kernel/git/jwboyer/fedora.git/

That was somewhat of a surprise.  It has found a few things here and
there, mostly in building for configurations or architectures that
Fedora does not support.  Sometimes this causes maintainers to be
mailed about build failures somewhat unexpectedly.  The most recent
case as the crash driver on openrisc.

The 0-Day maintainer said they can disable it, but I wanted to run it
past the team first.  I can see value in doing it, even if it isn't
directly applicable to Fedora itself at the moment.  Thoughts?

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org

Re: error building master branch

[Nicolas Chauvet]

2016-08-08 16:58 GMT+02:00 Laura Abbott :
> On 08/08/2016 01:39 AM, Thorsten Leemhuis wrote:
>>
>> Lo! Mr. Aappddeevv wrote on 08.08.2016 03:47:
>>>
>>> I am encountering compile errors building off master. My build system
>>> is f24. Any thoughts? I did some google searches but could not find
>>> anyone else that had the same problem.
>>>
>>> One of the errors is below:
>>>
>>>  pushd tools/iio/
>>>
>>> ~/proj/kernel/kernel-4.7.fc26/linux-4.8.0-0.rc0.git7.2.local.fc26.x86_64/tools/iio
>>> ~/proj/kernel/kernel-4.7.fc26/linux-4.8.0-0.rc0.git7.2.local.fc26.x86_64
>>> + make
>>> make[1]: Entering directory
>>> '/home/me/proj/kernel/kernel-4.7.fc26/linux-4.8.0-0.rc0.git7.2.local.fc26.x86_64/tools/iio'
>>> gcc -Wall -g -D_GNU_SOURCE   -c -o iio_event_monitor.o
>>> iio_event_monitor.c
>>> iio_event_monitor.c:58:3: error: 'IIO_PH' undeclared here (not in a
>>> function)
>>>   [IIO_PH] = "ph",
>>
>>
>> I ran into this issue when building 4.8-pre for F23 and F24
>> (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories ). If you
>> want to just circumvent this problem install the kernel-headers package
>> from at least 4.7 (from my repos or the kernel-stabilization repo) in
>> your build environment. Those headers contain everything that is needed
>> to compile the iio tools from 4.8-pre. I haven't reported the problem
>> upstream yet (-ELACKOFTIME) :-/
>>
>> CU, thl
>>
>
>
> Yes, installing the new headers is the correct solution. Several of
> the #defines for the IIO tools came in for 4.7. Since this is a

It would be better for the userspace tools to use the headers from the
kernel source tree instead of those from the "previous" kernel-headers
package.
This will lead to a bootstraping issue if that's not the case. Or is
there any reason why it's must use system installed headers ?

Thx



-- 
-

Nicolas (kwizart)
___
kernel mailing list
kernel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org