* [PATCH] hidraw: Fix crash on HIDIOCGFEATURE with a destroyed device
From: Rodrigo Rivas Costa @ 2018-04-05 23:09 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
Cc: Rodrigo Rivas Costa
Doing `ioctl(HIDIOCGFEATURE)` in a tight loop on a hidraw device
and then disconnecting the device, or unloading the driver, can
cause a NULL pointer dereference.
When a hidraw device is destroyed it sets 0 to `dev->exist`.
Most functions check 'dev->exist' before doing its work, but
`hidraw_get_report()` was missing that check.
Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com>
---
drivers/hid/hidraw.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 5fbe0f81ab2e..01b5a9f01814 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -192,6 +192,11 @@ static ssize_t hidraw_get_report(struct file *file, char __user *buffer, size_t
int ret = 0, len;
unsigned char report_number;
+ if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
+ ret = -ENODEV;
+ goto out;
+ }
+
dev = hidraw_table[minor]->hid;
if (!dev->ll_driver->raw_request) {
--
2.16.3
^ permalink raw reply related
* Re: [PATCH 3/8] Input: elan_i2c - add trackstick report
From: Dmitry Torokhov @ 2018-04-05 23:46 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: kt.liao, Oliver Haessler, Benjamin Berg, linux-input,
linux-kernel
In-Reply-To: <20180405132537.3218-4-benjamin.tissoires@redhat.com>
Hi Benjamin,
On Thu, Apr 05, 2018 at 03:25:32PM +0200, Benjamin Tissoires wrote:
> The Elan touchpads over I2C/SMBus also can handle a
> trackstick. Unfortunately, nothing tells us if the
> device supports trackstick (the information lies in
> the PS/2 node), so rely on a platform data to enable
> or not the trackstick node.
Hmm, I'd prefer if we did not add more platform data but rather user
generic device properties.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)
From: Dmitry Torokhov @ 2018-04-05 23:51 UTC (permalink / raw)
To: Benjamin Tissoires, kt.liao
Cc: Oliver Haessler, Benjamin Berg, linux-input, linux-kernel
In-Reply-To: <20180405132537.3218-1-benjamin.tissoires@redhat.com>
Hi Benjamin,
On Thu, Apr 05, 2018 at 03:25:29PM +0200, Benjamin Tissoires wrote:
> Hi Dmitry,
>
> well, this year, Lenovo gave us a surprise and decided to not use
> the same touchpad/trackstick in all its model. And by default, the
> support under Linux is less than ideal.
>
> Please find a series that should fix those issues. Compared to the 60
> series, there do not seem to e BIOS table issues this time, and suspend/resume
> works fine thanks to your latest trackstick fixes.
>
> The T480s is a different beast, as it uses an Elan touchpad.
> I have been carrying the patches 3-6 for a while and tested previous
> versions on various Elan PS/2 hardware without an issue as far as I
> could tell. I was lacking tests from users with SMBus as all the laptops
> I tried where puer PS/2.
>
> Anyway, it would be cool if you could have a look at the series.
I am mostly happy with the series, but I would love to hear KT's take on
it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/8] Input: support for latest Lenovo thinkpads (series 80)
From: Benjamin Tissoires @ 2018-04-06 6:51 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: 廖崇榮, Oliver Haessler, Benjamin Berg,
open list:HID CORE LAYER, lkml
In-Reply-To: <20180405235126.GB57189@dtor-ws>
Hi Dmitry,
On Fri, Apr 6, 2018 at 1:51 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Benjamin,
>
> On Thu, Apr 05, 2018 at 03:25:29PM +0200, Benjamin Tissoires wrote:
>> Hi Dmitry,
>>
>> well, this year, Lenovo gave us a surprise and decided to not use
>> the same touchpad/trackstick in all its model. And by default, the
>> support under Linux is less than ideal.
>>
>> Please find a series that should fix those issues. Compared to the 60
>> series, there do not seem to e BIOS table issues this time, and suspend/resume
>> works fine thanks to your latest trackstick fixes.
>>
>> The T480s is a different beast, as it uses an Elan touchpad.
>> I have been carrying the patches 3-6 for a while and tested previous
>> versions on various Elan PS/2 hardware without an issue as far as I
>> could tell. I was lacking tests from users with SMBus as all the laptops
>> I tried where puer PS/2.
>>
>> Anyway, it would be cool if you could have a look at the series.
>
> I am mostly happy with the series, but I would love to hear KT's take on
> it.
thanks for the quick review.
I worked closely with KT for this series. He helped me a lot for the
tiny firmware changes that were required. However, quoting his email
from Tuesday:
"There will be a spring vacation in Taiwan from tomorrow." I guess we
won't hear from him until the end of next week as we always have a
backlog of urgent things to do after holidays...
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH 3/8] Input: elan_i2c - add trackstick report
From: Benjamin Tissoires @ 2018-04-06 6:51 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: 廖崇榮, Oliver Haessler, Benjamin Berg,
open list:HID CORE LAYER, lkml
In-Reply-To: <20180405234632.GA57189@dtor-ws>
On Fri, Apr 6, 2018 at 1:46 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Benjamin,
>
> On Thu, Apr 05, 2018 at 03:25:32PM +0200, Benjamin Tissoires wrote:
>> The Elan touchpads over I2C/SMBus also can handle a
>> trackstick. Unfortunately, nothing tells us if the
>> device supports trackstick (the information lies in
>> the PS/2 node), so rely on a platform data to enable
>> or not the trackstick node.
>
> Hmm, I'd prefer if we did not add more platform data but rather user
> generic device properties.
>
Fair enough, I'll work on it for v2.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH 4/8] Input: elantech - split device info into a separate structure
From: kbuild test robot @ 2018-04-06 7:33 UTC (permalink / raw)
Cc: kbuild-all, Dmitry Torokhov, kt.liao, Oliver Haessler,
Benjamin Berg, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20180405132537.3218-5-benjamin.tissoires@redhat.com>
Hi Benjamin,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20180405]
[cannot apply to input/next v4.16 v4.16-rc7 v4.16-rc6 v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Benjamin-Tissoires/Input-support-for-latest-Lenovo-thinkpads-series-80/20180406-110729
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/input/mouse/elantech.c:1665:5: sparse: symbol 'elantech_query_info' was not declared. Should it be static?
drivers/input/mouse/elantech.c: In function 'elantech_init':
drivers/input/mouse/elantech.c:1839:9: warning: 'error' may be used uninitialized in this function [-Wmaybe-uninitialized]
return error;
^~~~~
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH] Input: elantech_query_info() can be static
From: kbuild test robot @ 2018-04-06 7:33 UTC (permalink / raw)
Cc: kbuild-all, Dmitry Torokhov, kt.liao, Oliver Haessler,
Benjamin Berg, linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20180405132537.3218-5-benjamin.tissoires@redhat.com>
Fixes: 3fedcdbcc4b9 ("Input: elantech - split device info into a separate structure")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
elantech.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index d485664..980dfd7 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1662,8 +1662,8 @@ static int elantech_set_properties(struct elantech_device_info *info)
return 0;
}
-int elantech_query_info(struct psmouse *psmouse,
- struct elantech_device_info *info)
+static int elantech_query_info(struct psmouse *psmouse,
+ struct elantech_device_info *info)
{
unsigned char param[3];
^ permalink raw reply related
* Commit *driver core: emit uevents when device is bound to a driver* causes regression
From: Paul Menzel @ 2018-04-06 12:20 UTC (permalink / raw)
To: Michael Tokarev, Greg Kroah-Hartman
Cc: linux-input, Linux Kernel Mailing List, Ben Caradoc-Davies
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
Dear Linux folks,
Commit 1455cf8 (driver core: emit uevents when device is bound to a
driver) [1], introduced in Linux 4.14-rc1, causes a regression in user
space.
After disconnecting USB devices, they are still shown as plugged in [2][3].
> I seem to be having a similar issue, but with an iPhone X using USB
> to provide internet access. Even after the phone is disconnected, it
> still shows up as "loaded active plugged". The only way to fix this
> is to reboot or use a different USB port.
`git bisect` shows that commit 1455cf8 (driver core: emit uevents when
device is bound to a driver) is at fault [4].
As user space should not break with newer Linux kernels, do you know
what to do about that or can you think of a fix?
Kind regards,
Paul
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1455cf8dbfd06aa7651dcfccbadb7a093944ca65
[2] https://github.com/systemd/systemd/issues/7587
[3] https://bugs.debian.org/883425
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883425#68
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* Re: Commit *driver core: emit uevents when device is bound to a driver* causes regression
From: Ben Caradoc-Davies @ 2018-04-06 12:47 UTC (permalink / raw)
To: Paul Menzel, Michael Tokarev, Greg Kroah-Hartman
Cc: linux-input, Linux Kernel Mailing List
In-Reply-To: <8d22cfe6-90b6-eb86-d82e-0e037bfbed4e@molgen.mpg.de>
Paul,
I agree that this is a regression in user space, but I would also like
to note that, as I reported in Debian Bug#883425 ([3] and [4] below), I
was able to restore user space functionality by upgrading to gvfs
1.35.90-1. This later gvfs appears to support (i.e. survive) these uevents.
Kind regards,
Ben.
On 07/04/18 00:20, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Commit 1455cf8 (driver core: emit uevents when device is bound to a
> driver) [1], introduced in Linux 4.14-rc1, causes a regression in user
> space.
>
> After disconnecting USB devices, they are still shown as plugged in [2][3].
>
>> I seem to be having a similar issue, but with an iPhone X using USB
>> to provide internet access. Even after the phone is disconnected, it
>> still shows up as "loaded active plugged". The only way to fix this
>> is to reboot or use a different USB port.
>
> `git bisect` shows that commit 1455cf8 (driver core: emit uevents when
> device is bound to a driver) is at fault [4].
>
> As user space should not break with newer Linux kernels, do you know
> what to do about that or can you think of a fix?
>
>
> Kind regards,
>
> Paul
>
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1455cf8dbfd06aa7651dcfccbadb7a093944ca65
>
> [2] https://github.com/systemd/systemd/issues/7587
> [3] https://bugs.debian.org/883425
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883425#68
>
--
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand
^ permalink raw reply
* Re: Commit *driver core: emit uevents when device is bound to a driver* causes regression
From: Greg Kroah-Hartman @ 2018-04-06 13:18 UTC (permalink / raw)
To: Paul Menzel
Cc: Michael Tokarev, linux-input, Linux Kernel Mailing List,
Ben Caradoc-Davies
In-Reply-To: <8d22cfe6-90b6-eb86-d82e-0e037bfbed4e@molgen.mpg.de>
On Fri, Apr 06, 2018 at 02:20:40PM +0200, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Commit 1455cf8 (driver core: emit uevents when device is bound to a
> driver) [1], introduced in Linux 4.14-rc1, causes a regression in user
> space.
>
> After disconnecting USB devices, they are still shown as plugged in [2][3].
>
> > I seem to be having a similar issue, but with an iPhone X using USB
> > to provide internet access. Even after the phone is disconnected, it
> > still shows up as "loaded active plugged". The only way to fix this
> > is to reboot or use a different USB port.
>
> `git bisect` shows that commit 1455cf8 (driver core: emit uevents when
> device is bound to a driver) is at fault [4].
>
> As user space should not break with newer Linux kernels, do you know what to
> do about that or can you think of a fix?
I thought we fixed this with follow-on patches, are you sure you are
using the latest 4.14.y kernel that has been released?
thanks,
greg k-h
^ permalink raw reply
* Re: Commit *driver core: emit uevents when device is bound to a driver* causes regression
From: Paul Menzel @ 2018-04-06 13:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Michael Tokarev, linux-input, linux-kernel, Ben Caradoc-Davies,
it+linux-input
In-Reply-To: <20180406131820.GA4555@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
Dear Greg,
On 04/06/18 15:18, Greg Kroah-Hartman wrote:
> On Fri, Apr 06, 2018 at 02:20:40PM +0200, Paul Menzel wrote:
>> Commit 1455cf8 (driver core: emit uevents when device is bound to a
>> driver) [1], introduced in Linux 4.14-rc1, causes a regression in user
>> space.
>>
>> After disconnecting USB devices, they are still shown as plugged in [2][3].
>>
>>> I seem to be having a similar issue, but with an iPhone X using USB
>>> to provide internet access. Even after the phone is disconnected, it
>>> still shows up as "loaded active plugged". The only way to fix this
>>> is to reboot or use a different USB port.
>>
>> `git bisect` shows that commit 1455cf8 (driver core: emit uevents when
>> device is bound to a driver) is at fault [4].
>>
>> As user space should not break with newer Linux kernels, do you know what to
>> do about that or can you think of a fix?
>
> I thought we fixed this with follow-on patches, are you sure you are
> using the latest 4.14.y kernel that has been released?
Here we are using Linux 4.14.30. We can try newer versions next week.
Kind regards,
Paul
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* Re: Commit *driver core: emit uevents when device is bound to a driver* causes regression
From: Greg Kroah-Hartman @ 2018-04-06 13:27 UTC (permalink / raw)
To: Paul Menzel
Cc: Michael Tokarev, linux-input, linux-kernel, Ben Caradoc-Davies,
it+linux-input
In-Reply-To: <22ee8cb0-5793-6ad6-d8e0-3e83a8c1361c@molgen.mpg.de>
On Fri, Apr 06, 2018 at 03:24:39PM +0200, Paul Menzel wrote:
> Dear Greg,
>
>
> On 04/06/18 15:18, Greg Kroah-Hartman wrote:
> > On Fri, Apr 06, 2018 at 02:20:40PM +0200, Paul Menzel wrote:
>
> > > Commit 1455cf8 (driver core: emit uevents when device is bound to a
> > > driver) [1], introduced in Linux 4.14-rc1, causes a regression in user
> > > space.
> > >
> > > After disconnecting USB devices, they are still shown as plugged in [2][3].
> > >
> > > > I seem to be having a similar issue, but with an iPhone X using USB
> > > > to provide internet access. Even after the phone is disconnected, it
> > > > still shows up as "loaded active plugged". The only way to fix this
> > > > is to reboot or use a different USB port.
> > >
> > > `git bisect` shows that commit 1455cf8 (driver core: emit uevents when
> > > device is bound to a driver) is at fault [4].
> > >
> > > As user space should not break with newer Linux kernels, do you know what to
> > > do about that or can you think of a fix?
> >
> > I thought we fixed this with follow-on patches, are you sure you are
> > using the latest 4.14.y kernel that has been released?
>
> Here we are using Linux 4.14.30. We can try newer versions next week.
Ah, no, 4.14.30 should be fine.
I saw the patch listed in the debian bug report, so this only happens
for the MTP type devices? That was a really odd "filter" that it was
trying to use before.
So this is only for userspace programs, and one specifically? And for
only one type of device? What device, MTP devices?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 07/10] input: touchscreen: touch_adc: add generic resistive ADC touchscreen
From: Jonathan Cameron @ 2018-04-06 15:13 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jonathan Cameron, Eugen Hristev, ludovic.desroches,
alexandre.belloni, linux-arm-kernel, devicetree, linux-kernel,
linux-iio, linux-input, nicolas.ferre
In-Reply-To: <20180330180911.GA143703@dtor-ws>
> > > +
> > > + input->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
> > > + input->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
> > > +
> > > + st->input = input;
> > > + input_set_drvdata(input, st);
> > > +
> > > + ret = input_register_device(input);
> > > + if (ret) {
> > > + dev_err(dev, "failed to register input device.");
> > > + return ret;
> > > + }
> > > +
> > > + st->iio_cb = iio_channel_get_all_cb(&pdev->dev, grts_cb, st);
>
> Hmm, we don't have devm-variant for this? Then you could use
> devm_add_action_or_reset() to add cleanup action and completely remove
> grts_remove().
Not yet, but I'm not adverse to having one...
^ permalink raw reply
* [PATCH] Input: leds - fix out of bound access
From: Dmitry Torokhov @ 2018-04-06 18:12 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Tasos Sahanidis, Samuel Thibault
UI_SET_LEDBIT ioctl() causes the following KASAN splat when used with
led > LED_CHARGING:
[ 1274.663418] BUG: KASAN: slab-out-of-bounds in input_leds_connect+0x611/0x730 [input_leds]
[ 1274.663426] Write of size 8 at addr ffff88003377b2c0 by task ckb-next-daemon/5128
This happens because we were writing to the led structure before making
sure that it exists.
Reported-by: Tasos Sahanidis <tasos@tasossah.com>
Tested-by: Tasos Sahanidis <tasos@tasossah.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/input-leds.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
index 766bf26601163..5f04b2d946350 100644
--- a/drivers/input/input-leds.c
+++ b/drivers/input/input-leds.c
@@ -88,6 +88,7 @@ static int input_leds_connect(struct input_handler *handler,
const struct input_device_id *id)
{
struct input_leds *leds;
+ struct input_led *led;
unsigned int num_leds;
unsigned int led_code;
int led_no;
@@ -119,14 +120,13 @@ static int input_leds_connect(struct input_handler *handler,
led_no = 0;
for_each_set_bit(led_code, dev->ledbit, LED_CNT) {
- struct input_led *led = &leds->leds[led_no];
+ if (!input_led_info[led_code].name)
+ continue;
+ led = &leds->leds[led_no];
led->handle = &leds->handle;
led->code = led_code;
- if (!input_led_info[led_code].name)
- continue;
-
led->cdev.name = kasprintf(GFP_KERNEL, "%s::%s",
dev_name(&dev->dev),
input_led_info[led_code].name);
--
2.17.0.484.g0c8726318c-goog
--
Dmitry
^ permalink raw reply related
* Re: Commit *driver core: emit uevents when device is bound to a driver* causes regression
From: Dmitry Torokhov @ 2018-04-06 18:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Paul Menzel, Michael Tokarev, linux-input@vger.kernel.org, lkml,
Ben Caradoc-Davies, it+linux-input
In-Reply-To: <20180406132720.GA16189@kroah.com>
On Fri, Apr 6, 2018 at 6:27 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Apr 06, 2018 at 03:24:39PM +0200, Paul Menzel wrote:
>> Dear Greg,
>>
>>
>> On 04/06/18 15:18, Greg Kroah-Hartman wrote:
>> > On Fri, Apr 06, 2018 at 02:20:40PM +0200, Paul Menzel wrote:
>>
>> > > Commit 1455cf8 (driver core: emit uevents when device is bound to a
>> > > driver) [1], introduced in Linux 4.14-rc1, causes a regression in user
>> > > space.
>> > >
>> > > After disconnecting USB devices, they are still shown as plugged in [2][3].
>> > >
>> > > > I seem to be having a similar issue, but with an iPhone X using USB
>> > > > to provide internet access. Even after the phone is disconnected, it
>> > > > still shows up as "loaded active plugged". The only way to fix this
>> > > > is to reboot or use a different USB port.
>> > >
>> > > `git bisect` shows that commit 1455cf8 (driver core: emit uevents when
>> > > device is bound to a driver) is at fault [4].
>> > >
>> > > As user space should not break with newer Linux kernels, do you know what to
>> > > do about that or can you think of a fix?
>> >
>> > I thought we fixed this with follow-on patches, are you sure you are
>> > using the latest 4.14.y kernel that has been released?
>>
>> Here we are using Linux 4.14.30. We can try newer versions next week.
>
> Ah, no, 4.14.30 should be fine.
>
> I saw the patch listed in the debian bug report, so this only happens
> for the MTP type devices? That was a really odd "filter" that it was
> trying to use before.
>
> So this is only for userspace programs, and one specifically? And for
> only one type of device? What device, MTP devices?
So looking at reports, gvfs is fixed, upowerd simply uses g_warning()
for actions it does nto understand and I'll send a patch lowering this
to g_debug(); what else is having trouble with the new actions?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] HID: i2c-hid: Silently fail probe for CHPN0001 touchscreen
From: Sasha Levin @ 2018-04-06 20:05 UTC (permalink / raw)
To: Sasha Levin, Jiri Kosina
Cc: Hans de Goede, linux-input@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20180403131634.13187-2-hdegoede@redhat.com>
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 20.8863)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126.
v4.16: Build OK!
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")
v4.4.126: Failed to apply! Possible dependencies:
94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")
Please let us know if you'd like to have this patch included in a stable tree.
^ permalink raw reply
* Re: [PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad
From: Sasha Levin @ 2018-04-06 20:05 UTC (permalink / raw)
To: Sasha Levin, Ondrej Zary, Dmitry Torokhov
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20180403170810.32005-1-linux@rainbow-software.org>
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 24.5527)
The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126.
v4.16: Build OK!
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad
From: Ondrej Zary @ 2018-04-06 20:16 UTC (permalink / raw)
To: Sasha Levin
Cc: Dmitry Torokhov, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <MW2PR2101MB10344E66701305F65F39EF24FBBA0@MW2PR2101MB1034.namprd21.prod.outlook.com>
On Friday 06 April 2018 22:05:59 Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed by the -stable helper bot and determined
> to be a high probability candidate for -stable trees. (score: 24.5527)
>
> The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
> v4.4.126.
>
> v4.16: Build OK!
> v4.15.15: Build OK!
> v4.14.32: Build OK!
> v4.9.92: Build OK!
> v4.4.126: Build OK!
>
> Please let us know if you'd like to have this patch included in a stable
> tree.
AFAIK, it was already included in various stable trees.
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad
From: Sasha Levin @ 2018-04-06 20:24 UTC (permalink / raw)
To: Ondrej Zary
Cc: Dmitry Torokhov, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <201804062216.20107.linux@rainbow-software.org>
On Fri, Apr 06, 2018 at 10:16:19PM +0200, Ondrej Zary wrote:
>On Friday 06 April 2018 22:05:59 Sasha Levin wrote:
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed by the -stable helper bot and determined
>> to be a high probability candidate for -stable trees. (score: 24.5527)
>>
>> The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92,
>> v4.4.126.
>>
>> v4.16: Build OK!
>> v4.15.15: Build OK!
>> v4.14.32: Build OK!
>> v4.9.92: Build OK!
>> v4.4.126: Build OK!
>>
>> Please let us know if you'd like to have this patch included in a stable
>> tree.
>
>AFAIK, it was already included in various stable trees.
Ah yes, indeed I see it proposed for various -stable trees.
I guess Greg is extra speedy these days :)
^ permalink raw reply
* Re: [PATCH] Input: synaptics-rmi4 - Fix an unchecked out of memory error path
From: Dmitry Torokhov @ 2018-04-06 22:37 UTC (permalink / raw)
To: Andrew Duggan
Cc: Christophe JAILLET, benjamin.tissoires, gregkh, linux-input,
linux-kernel, kernel-janitors
In-Reply-To: <a8d419ae-4047-77af-0a1c-683bf1370e6a@synaptics.com>
On Mon, Apr 02, 2018 at 05:52:52PM -0700, Andrew Duggan wrote:
>
> On 04/02/2018 07:03 AM, Christophe JAILLET wrote:
> > When extending the rmi_spi buffers, we must check that no out of memory
> > error occurs, otherwise we may access data above the currently allocated
> > memory.
> >
> > Propagate the error code returned by 'rmi_spi_manage_pools()' instead.
> Yep, that definitely looks like an oversight on my part. Thanks for the fix.
>
> Andrew
>
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>
> Reviewed-by: Andrew Duggan <aduggan@synaptics.com>
Applied, thank you.
>
> > ---
> > drivers/input/rmi4/rmi_spi.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/rmi4/rmi_spi.c b/drivers/input/rmi4/rmi_spi.c
> > index 76edbf2c1bce..082defc329a8 100644
> > --- a/drivers/input/rmi4/rmi_spi.c
> > +++ b/drivers/input/rmi4/rmi_spi.c
> > @@ -147,8 +147,11 @@ static int rmi_spi_xfer(struct rmi_spi_xport *rmi_spi,
> > if (len > RMI_SPI_XFER_SIZE_LIMIT)
> > return -EINVAL;
> > - if (rmi_spi->xfer_buf_size < len)
> > - rmi_spi_manage_pools(rmi_spi, len);
> > + if (rmi_spi->xfer_buf_size < len) {
> > + ret = rmi_spi_manage_pools(rmi_spi, len);
> > + if (ret < 0)
> > + return ret;
> > + }
> > if (addr == 0)
> > /*
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] HID: i2c-hid: Silently fail probe for CHPN0001 touchscreen
From: Hans de Goede @ 2018-04-07 9:42 UTC (permalink / raw)
To: Sasha Levin, Jiri Kosina
Cc: linux-input@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <MW2PR2101MB1034700D2EE61E78EA6C13E7FBBA0@MW2PR2101MB1034.namprd21.prod.outlook.com>
Hi,
On 06-04-18 22:05, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed by the -stable helper bot and determined
> to be a high probability candidate for -stable trees. (score: 20.8863)
>
> The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126.
>
> v4.16: Build OK!
> v4.15.15: Build OK!
> v4.14.32: Build OK!
> v4.9.92: Failed to apply! Possible dependencies:
> 94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")
>
> v4.4.126: Failed to apply! Possible dependencies:
> 94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")
Cool, first time I see this bot in action, nice work.
> Please let us know if you'd like to have this patch included in a stable tree.
So FWIW this commit is NOT stable material (it cannot hurt, but it is not
necessary). This commit really only makes sense together with a new touchscreen
driver which does actually know how to handle the CHPN0001 touchscreen.
For future mails like this, do I understand the mail correctly that if I
do NOT want a patch picked up by the -stable helper bot to go to stable
I do not have to do anything?
Regards,
Hans
^ permalink raw reply
* [PATCH v2 1/3] resource: Use list_head to link sibling resource
From: Baoquan He @ 2018-04-08 2:47 UTC (permalink / raw)
To: linux-kernel
Cc: Baoquan He, Patrik Jakobsson, David Airlie, K. Y. Srinivasan,
Haiyang Zhang, Stephen Hemminger, Dmitry Torokhov, Dan Williams,
Rob Herring, Frank Rowand, Keith Busch, Jonathan Derrick,
Lorenzo Pieralisi, Bjorn Helgaas, Thomas Gleixner, Brijesh Singh,
Jérôme Glisse, Borislav Petkov
In-Reply-To: <20180408024724.16812-1-bhe@redhat.com>
The struct resource uses singly linked list to link siblings. It's not
easy to do reverse iteration on sibling list. So replace it with list_head.
And this makes codes in kernel/resource.c more readable after refactoring
than pointer operation.
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Jonathan Derrick <jonathan.derrick@intel.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: devel@linuxdriverproject.org
Cc: linux-input@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
Cc: devicetree@vger.kernel.org
Cc: linux-pci@vger.kernel.org
---
drivers/gpu/drm/gma500/gtt.c | 5 +-
drivers/hv/vmbus_drv.c | 52 ++++----
drivers/input/joystick/iforce/iforce-main.c | 4 +-
drivers/nvdimm/e820.c | 2 +-
drivers/nvdimm/namespace_devs.c | 14 +-
drivers/nvdimm/nd.h | 5 +-
drivers/of/address.c | 4 +-
drivers/pci/host/vmd.c | 8 +-
drivers/pci/probe.c | 2 +
drivers/pci/setup-bus.c | 2 +-
include/linux/ioport.h | 4 +-
kernel/resource.c | 193 ++++++++++++++--------------
12 files changed, 151 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 3949b0990916..addd3bc009af 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -565,7 +565,7 @@ int psb_gtt_init(struct drm_device *dev, int resume)
int psb_gtt_restore(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
- struct resource *r = dev_priv->gtt_mem->child;
+ struct resource *r;
struct gtt_range *range;
unsigned int restored = 0, total = 0, size = 0;
@@ -573,14 +573,13 @@ int psb_gtt_restore(struct drm_device *dev)
mutex_lock(&dev_priv->gtt_mutex);
psb_gtt_init(dev, 1);
- while (r != NULL) {
+ list_for_each_entry(r, &dev_priv->gtt_mem->child, sibling) {
range = container_of(r, struct gtt_range, resource);
if (range->pages) {
psb_gtt_insert(dev, range, 1);
size += range->resource.end - range->resource.start;
restored++;
}
- r = r->sibling;
total++;
}
mutex_unlock(&dev_priv->gtt_mutex);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc65c4d79c1f..7ba8a25520d9 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1413,9 +1413,8 @@ static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
{
resource_size_t start = 0;
resource_size_t end = 0;
- struct resource *new_res;
+ struct resource *new_res, *tmp;
struct resource **old_res = &hyperv_mmio;
- struct resource **prev_res = NULL;
switch (res->type) {
@@ -1462,44 +1461,36 @@ static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
/*
* If two ranges are adjacent, merge them.
*/
- do {
- if (!*old_res) {
- *old_res = new_res;
- break;
- }
-
- if (((*old_res)->end + 1) == new_res->start) {
- (*old_res)->end = new_res->end;
+ if (!*old_res) {
+ *old_res = new_res;
+ return AE_OK;
+ }
+ tmp = *old_res;
+ list_for_each_entry_from(tmp, &tmp->parent->child, sibling) {
+ if ((tmp->end + 1) == new_res->start) {
+ tmp->end = new_res->end;
kfree(new_res);
break;
}
- if ((*old_res)->start == new_res->end + 1) {
- (*old_res)->start = new_res->start;
+ if (tmp->start == new_res->end + 1) {
+ tmp->start = new_res->start;
kfree(new_res);
break;
}
- if ((*old_res)->start > new_res->end) {
- new_res->sibling = *old_res;
- if (prev_res)
- (*prev_res)->sibling = new_res;
- *old_res = new_res;
+ if (tmp->start > new_res->end) {
+ list_add(&new_res->sibling, tmp->sibling.prev);
break;
}
-
- prev_res = old_res;
- old_res = &(*old_res)->sibling;
-
- } while (1);
+ }
return AE_OK;
}
static int vmbus_acpi_remove(struct acpi_device *device)
{
- struct resource *cur_res;
- struct resource *next_res;
+ struct resource *res;
if (hyperv_mmio) {
if (fb_mmio) {
@@ -1508,10 +1499,9 @@ static int vmbus_acpi_remove(struct acpi_device *device)
fb_mmio = NULL;
}
- for (cur_res = hyperv_mmio; cur_res; cur_res = next_res) {
- next_res = cur_res->sibling;
- kfree(cur_res);
- }
+ res = hyperv_mmio;
+ list_for_each_entry_from(res, &res->parent->child, sibling)
+ kfree(res);
}
return 0;
@@ -1597,7 +1587,8 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
}
}
- for (iter = hyperv_mmio; iter; iter = iter->sibling) {
+ iter = hyperv_mmio;
+ list_for_each_entry_from(iter, &iter->parent->child, sibling) {
if ((iter->start >= max) || (iter->end <= min))
continue;
@@ -1640,7 +1631,8 @@ void vmbus_free_mmio(resource_size_t start, resource_size_t size)
struct resource *iter;
down(&hyperv_mmio_lock);
- for (iter = hyperv_mmio; iter; iter = iter->sibling) {
+ iter = hyperv_mmio;
+ list_for_each_entry_from(iter, &iter->parent->child, sibling) {
if ((iter->start >= start + size) || (iter->end <= start))
continue;
diff --git a/drivers/input/joystick/iforce/iforce-main.c b/drivers/input/joystick/iforce/iforce-main.c
index daeeb4c7e3b0..5c0be27b33ff 100644
--- a/drivers/input/joystick/iforce/iforce-main.c
+++ b/drivers/input/joystick/iforce/iforce-main.c
@@ -305,8 +305,8 @@ int iforce_init_device(struct iforce *iforce)
iforce->device_memory.end = 200;
iforce->device_memory.flags = IORESOURCE_MEM;
iforce->device_memory.parent = NULL;
- iforce->device_memory.child = NULL;
- iforce->device_memory.sibling = NULL;
+ INIT_LIST_HEAD(&iforce->device_memory.child);
+ INIT_LIST_HEAD(&iforce->device_memory.sibling);
/*
* Wait until device ready - until it sends its first response.
diff --git a/drivers/nvdimm/e820.c b/drivers/nvdimm/e820.c
index 6f9a6ffd7cde..513e661bb0d8 100644
--- a/drivers/nvdimm/e820.c
+++ b/drivers/nvdimm/e820.c
@@ -53,7 +53,7 @@ static int e820_pmem_probe(struct platform_device *pdev)
goto err;
platform_set_drvdata(pdev, nvdimm_bus);
- for (p = iomem_resource.child; p ; p = p->sibling) {
+ list_for_each_entry(p, &iomem_resource.child, sibling) {
struct nd_region_desc ndr_desc;
if (p->desc != IORES_DESC_PERSISTENT_MEMORY_LEGACY)
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 658ada497be0..d175a391fea0 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -637,7 +637,11 @@ static resource_size_t scan_allocate(struct nd_region *nd_region,
retry:
first = 0;
for_each_dpa_resource(ndd, res) {
- struct resource *next = res->sibling, *new_res = NULL;
+ struct resource *next, *new_res = NULL;
+ if (res->parent && !list_is_last(&res->sibling, &res->parent->child))
+ next = list_next_entry(res, sibling);
+ else
+ next = NULL;
resource_size_t allocate, available = 0;
enum alloc_loc loc = ALLOC_ERR;
const char *action;
@@ -763,7 +767,7 @@ static resource_size_t scan_allocate(struct nd_region *nd_region,
* an initial "pmem-reserve pass". Only do an initial BLK allocation
* when none of the DPA space is reserved.
*/
- if ((is_pmem || !ndd->dpa.child) && n == to_allocate)
+ if ((is_pmem || list_empty(&ndd->dpa.child)) && n == to_allocate)
return init_dpa_allocation(label_id, nd_region, nd_mapping, n);
return n;
}
@@ -779,7 +783,11 @@ static int merge_dpa(struct nd_region *nd_region,
retry:
for_each_dpa_resource(ndd, res) {
int rc;
- struct resource *next = res->sibling;
+ struct resource *next;
+ if (res->parent && !list_is_last(&res->sibling, &res->parent->child))
+ next = list_next_entry(res, sibling);
+ else
+ next = NULL;
resource_size_t end = res->start + resource_size(res);
if (!next || strcmp(res->name, label_id->id) != 0
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index 8d6375ee0fda..9f3cad1f5950 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -103,11 +103,10 @@ unsigned sizeof_namespace_label(struct nvdimm_drvdata *ndd);
(unsigned long long) (res ? res->start : 0), ##arg)
#define for_each_dpa_resource(ndd, res) \
- for (res = (ndd)->dpa.child; res; res = res->sibling)
+ list_for_each_entry(res, &(ndd)->dpa.child, sibling)
#define for_each_dpa_resource_safe(ndd, res, next) \
- for (res = (ndd)->dpa.child, next = res ? res->sibling : NULL; \
- res; res = next, next = next ? next->sibling : NULL)
+ list_for_each_entry_safe(res, next, &(ndd)->dpa.child, sibling)
struct nd_percpu_lane {
int count;
diff --git a/drivers/of/address.c b/drivers/of/address.c
index ce4d3d8b85de..55ee8fee9b25 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -328,7 +328,9 @@ int of_pci_range_to_resource(struct of_pci_range *range,
{
int err;
res->flags = range->flags;
- res->parent = res->child = res->sibling = NULL;
+ res->parent = NULL;
+ INIT_LIST_HEAD(&res->child);
+ INIT_LIST_HEAD(&res->sibling);
res->name = np->full_name;
if (res->flags & IORESOURCE_IO) {
diff --git a/drivers/pci/host/vmd.c b/drivers/pci/host/vmd.c
index 930a8fa08bd6..c3000af903ea 100644
--- a/drivers/pci/host/vmd.c
+++ b/drivers/pci/host/vmd.c
@@ -520,14 +520,14 @@ static struct pci_ops vmd_ops = {
static void vmd_attach_resources(struct vmd_dev *vmd)
{
- vmd->dev->resource[VMD_MEMBAR1].child = &vmd->resources[1];
- vmd->dev->resource[VMD_MEMBAR2].child = &vmd->resources[2];
+ list_add(&vmd->resources[1].sibling, &vmd->dev->resource[VMD_MEMBAR1].child);
+ list_add(&vmd->resources[2].sibling, &vmd->dev->resource[VMD_MEMBAR2].child);
}
static void vmd_detach_resources(struct vmd_dev *vmd)
{
- vmd->dev->resource[VMD_MEMBAR1].child = NULL;
- vmd->dev->resource[VMD_MEMBAR2].child = NULL;
+ INIT_LIST_HEAD(&vmd->dev->resource[VMD_MEMBAR1].child);
+ INIT_LIST_HEAD(&vmd->dev->resource[VMD_MEMBAR2].child);
}
/*
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef5377438a1e..09df07776fca 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -58,6 +58,8 @@ static struct resource *get_pci_domain_busn_res(int domain_nr)
r->res.start = 0;
r->res.end = 0xff;
r->res.flags = IORESOURCE_BUS | IORESOURCE_PCI_FIXED;
+ INIT_LIST_HEAD(&r->res.child);
+ INIT_LIST_HEAD(&r->res.sibling);
list_add_tail(&r->list, &pci_domain_busn_res_list);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 3cce29a069e6..f7d54e4903e4 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -2111,7 +2111,7 @@ int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
continue;
/* Ignore BARs which are still in use */
- if (res->child)
+ if (!list_empty(&res->child))
continue;
ret = add_to_list(&saved, bridge, res, 0, 0);
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index da0ebaec25f0..745f2acc3674 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -22,7 +22,8 @@ struct resource {
const char *name;
unsigned long flags;
unsigned long desc;
- struct resource *parent, *sibling, *child;
+ struct list_head child, sibling;
+ struct resource *parent;
};
/*
@@ -215,7 +216,6 @@ static inline bool resource_contains(struct resource *r1, struct resource *r2)
return r1->start <= r2->start && r1->end >= r2->end;
}
-
/* Convenience shorthand with allocation */
#define request_region(start,n,name) __request_region(&ioport_resource, (start), (n), (name), 0)
#define request_muxed_region(start,n,name) __request_region(&ioport_resource, (start), (n), (name), IORESOURCE_MUXED)
diff --git a/kernel/resource.c b/kernel/resource.c
index e270b5048988..05b1efa595c2 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -31,6 +31,8 @@ struct resource ioport_resource = {
.start = 0,
.end = IO_SPACE_LIMIT,
.flags = IORESOURCE_IO,
+ .sibling = LIST_HEAD_INIT(ioport_resource.sibling),
+ .child = LIST_HEAD_INIT(ioport_resource.child),
};
EXPORT_SYMBOL(ioport_resource);
@@ -39,6 +41,8 @@ struct resource iomem_resource = {
.start = 0,
.end = -1,
.flags = IORESOURCE_MEM,
+ .sibling = LIST_HEAD_INIT(iomem_resource.sibling),
+ .child = LIST_HEAD_INIT(iomem_resource.child),
};
EXPORT_SYMBOL(iomem_resource);
@@ -57,20 +61,32 @@ static DEFINE_RWLOCK(resource_lock);
* by boot mem after the system is up. So for reusing the resource entry
* we need to remember the resource.
*/
-static struct resource *bootmem_resource_free;
+static struct list_head bootmem_resource_free = LIST_HEAD_INIT(bootmem_resource_free);
static DEFINE_SPINLOCK(bootmem_resource_lock);
+static struct resource *sibling(struct resource *res)
+{
+ if (res->parent && !list_is_last(&res->sibling, &res->parent->child))
+ return list_next_entry(res, sibling);
+ return NULL;
+}
+
+static struct resource *first_child(struct list_head *head)
+{
+ return list_first_entry_or_null(head, struct resource, sibling);
+}
+
static struct resource *next_resource(struct resource *p, bool sibling_only)
{
/* Caller wants to traverse through siblings only */
if (sibling_only)
- return p->sibling;
+ return sibling(p);
- if (p->child)
- return p->child;
- while (!p->sibling && p->parent)
+ if (!list_empty(&p->child))
+ return first_child(&p->child);
+ while (!sibling(p) && p->parent)
p = p->parent;
- return p->sibling;
+ return sibling(p);
}
static void *r_next(struct seq_file *m, void *v, loff_t *pos)
@@ -90,7 +106,7 @@ static void *r_start(struct seq_file *m, loff_t *pos)
struct resource *p = m->private;
loff_t l = 0;
read_lock(&resource_lock);
- for (p = p->child; p && l < *pos; p = r_next(m, p, &l))
+ for (p = first_child(&p->child); p && l < *pos; p = r_next(m, p, &l))
;
return p;
}
@@ -186,8 +202,7 @@ static void free_resource(struct resource *res)
if (!PageSlab(virt_to_head_page(res))) {
spin_lock(&bootmem_resource_lock);
- res->sibling = bootmem_resource_free;
- bootmem_resource_free = res;
+ list_add(&res->sibling, &bootmem_resource_free);
spin_unlock(&bootmem_resource_lock);
} else {
kfree(res);
@@ -199,10 +214,9 @@ static struct resource *alloc_resource(gfp_t flags)
struct resource *res = NULL;
spin_lock(&bootmem_resource_lock);
- if (bootmem_resource_free) {
- res = bootmem_resource_free;
- bootmem_resource_free = res->sibling;
- }
+ res = first_child(&bootmem_resource_free);
+ if (res)
+ list_del(&res->sibling);
spin_unlock(&bootmem_resource_lock);
if (res)
@@ -210,6 +224,8 @@ static struct resource *alloc_resource(gfp_t flags)
else
res = kzalloc(sizeof(struct resource), flags);
+ INIT_LIST_HEAD(&res->child);
+ INIT_LIST_HEAD(&res->sibling);
return res;
}
@@ -218,7 +234,7 @@ static struct resource * __request_resource(struct resource *root, struct resour
{
resource_size_t start = new->start;
resource_size_t end = new->end;
- struct resource *tmp, **p;
+ struct resource *tmp;
if (end < start)
return root;
@@ -226,64 +242,62 @@ static struct resource * __request_resource(struct resource *root, struct resour
return root;
if (end > root->end)
return root;
- p = &root->child;
- for (;;) {
- tmp = *p;
- if (!tmp || tmp->start > end) {
- new->sibling = tmp;
- *p = new;
+
+ if (list_empty(&root->child)) {
+ list_add(&new->sibling, &root->child);
+ new->parent = root;
+ INIT_LIST_HEAD(&new->child);
+ return NULL;
+ }
+
+ list_for_each_entry(tmp, &root->child, sibling) {
+ if (tmp->start > end) {
+ list_add(&new->sibling, tmp->sibling.prev);
new->parent = root;
+ INIT_LIST_HEAD(&new->child);
return NULL;
}
- p = &tmp->sibling;
if (tmp->end < start)
continue;
return tmp;
}
+
+ list_add_tail(&new->sibling, &root->child);
+ new->parent = root;
+ INIT_LIST_HEAD(&new->child);
+ return NULL;
}
static int __release_resource(struct resource *old, bool release_child)
{
- struct resource *tmp, **p, *chd;
+ struct resource *tmp, *next, *chd;
- p = &old->parent->child;
- for (;;) {
- tmp = *p;
- if (!tmp)
- break;
+ list_for_each_entry_safe(tmp, next, &old->parent->child, sibling) {
if (tmp == old) {
- if (release_child || !(tmp->child)) {
- *p = tmp->sibling;
+ if (release_child || list_empty(&tmp->child)) {
+ list_del(&tmp->sibling);
} else {
- for (chd = tmp->child;; chd = chd->sibling) {
+ list_for_each_entry(chd, &tmp->child, sibling)
chd->parent = tmp->parent;
- if (!(chd->sibling))
- break;
- }
- *p = tmp->child;
- chd->sibling = tmp->sibling;
+ list_splice(&tmp->child, tmp->sibling.prev);
+ list_del(&tmp->sibling);
}
+
old->parent = NULL;
return 0;
}
- p = &tmp->sibling;
}
return -EINVAL;
}
static void __release_child_resources(struct resource *r)
{
- struct resource *tmp, *p;
+ struct resource *tmp, *next;
resource_size_t size;
- p = r->child;
- r->child = NULL;
- while (p) {
- tmp = p;
- p = p->sibling;
-
+ list_for_each_entry_safe(tmp, next, &r->child, sibling) {
tmp->parent = NULL;
- tmp->sibling = NULL;
+ INIT_LIST_HEAD(&tmp->sibling);
__release_child_resources(tmp);
printk(KERN_DEBUG "release child resource %pR\n", tmp);
@@ -292,6 +306,8 @@ static void __release_child_resources(struct resource *r)
tmp->start = 0;
tmp->end = size - 1;
}
+
+ INIT_LIST_HEAD(&tmp->child);
}
void release_child_resources(struct resource *r)
@@ -376,7 +392,8 @@ static int find_next_iomem_res(struct resource *res, unsigned long desc,
read_lock(&resource_lock);
- for (p = iomem_resource.child; p; p = next_resource(p, sibling_only)) {
+ for (p = first_child(&iomem_resource.child); p;
+ p = next_resource(p, sibling_only)) {
if ((p->flags & res->flags) != res->flags)
continue;
if ((desc != IORES_DESC_NONE) && (desc != p->desc))
@@ -564,7 +581,7 @@ int region_intersects(resource_size_t start, size_t size, unsigned long flags,
struct resource *p;
read_lock(&resource_lock);
- for (p = iomem_resource.child; p ; p = p->sibling) {
+ list_for_each_entry(p, &iomem_resource.child, sibling) {
bool is_type = (((p->flags & flags) == flags) &&
((desc == IORES_DESC_NONE) ||
(desc == p->desc)));
@@ -618,7 +635,7 @@ static int __find_resource(struct resource *root, struct resource *old,
resource_size_t size,
struct resource_constraint *constraint)
{
- struct resource *this = root->child;
+ struct resource *this = first_child(&root->child);
struct resource tmp = *new, avail, alloc;
tmp.start = root->start;
@@ -628,7 +645,7 @@ static int __find_resource(struct resource *root, struct resource *old,
*/
if (this && this->start == root->start) {
tmp.start = (this == old) ? old->start : this->end + 1;
- this = this->sibling;
+ this = sibling(this);
}
for(;;) {
if (this)
@@ -663,7 +680,7 @@ next: if (!this || this->end == root->end)
if (this != old)
tmp.start = this->end + 1;
- this = this->sibling;
+ this = sibling(this);
}
return -EBUSY;
}
@@ -707,7 +724,7 @@ static int reallocate_resource(struct resource *root, struct resource *old,
goto out;
}
- if (old->child) {
+ if (!list_empty(&old->child)) {
err = -EBUSY;
goto out;
}
@@ -788,7 +805,7 @@ struct resource *lookup_resource(struct resource *root, resource_size_t start)
struct resource *res;
read_lock(&resource_lock);
- for (res = root->child; res; res = res->sibling) {
+ list_for_each_entry(res, &root->child, sibling) {
if (res->start == start)
break;
}
@@ -821,32 +838,27 @@ static struct resource * __insert_resource(struct resource *parent, struct resou
break;
}
- for (next = first; ; next = next->sibling) {
+ for (next = first; ; next = sibling(next)) {
/* Partial overlap? Bad, and unfixable */
if (next->start < new->start || next->end > new->end)
return next;
- if (!next->sibling)
+ if (!sibling(next))
break;
- if (next->sibling->start > new->end)
+ if (sibling(next)->start > new->end)
break;
}
-
new->parent = parent;
- new->sibling = next->sibling;
- new->child = first;
+ list_add(&new->sibling, &next->sibling);
+ INIT_LIST_HEAD(&new->child);
- next->sibling = NULL;
- for (next = first; next; next = next->sibling)
+ /*
+ * From first to next, they all fall into new's region, so change them
+ * as new's children.
+ */
+ list_cut_position(&new->child, first->sibling.prev, &next->sibling);
+ list_for_each_entry(next, &new->child, sibling)
next->parent = new;
- if (parent->child == first) {
- parent->child = new;
- } else {
- next = parent->child;
- while (next->sibling != first)
- next = next->sibling;
- next->sibling = new;
- }
return NULL;
}
@@ -968,19 +980,17 @@ static int __adjust_resource(struct resource *res, resource_size_t start,
if ((start < parent->start) || (end > parent->end))
goto out;
- if (res->sibling && (res->sibling->start <= end))
+ if (sibling(res) && (sibling(res)->start <= end))
goto out;
- tmp = parent->child;
- if (tmp != res) {
- while (tmp->sibling != res)
- tmp = tmp->sibling;
+ if (res->sibling.prev != &parent->child) {
+ tmp = list_prev_entry(res, sibling);
if (start <= tmp->end)
goto out;
}
skip:
- for (tmp = res->child; tmp; tmp = tmp->sibling)
+ list_for_each_entry(tmp, &res->child, sibling)
if ((tmp->start < start) || (tmp->end > end))
goto out;
@@ -1205,34 +1215,32 @@ EXPORT_SYMBOL(__request_region);
void __release_region(struct resource *parent, resource_size_t start,
resource_size_t n)
{
- struct resource **p;
+ struct resource *res;
resource_size_t end;
- p = &parent->child;
+ res = first_child(&parent->child);
end = start + n - 1;
write_lock(&resource_lock);
for (;;) {
- struct resource *res = *p;
-
if (!res)
break;
if (res->start <= start && res->end >= end) {
if (!(res->flags & IORESOURCE_BUSY)) {
- p = &res->child;
+ res = first_child(&res->child);
continue;
}
if (res->start != start || res->end != end)
break;
- *p = res->sibling;
+ list_del(&res->sibling);
write_unlock(&resource_lock);
if (res->flags & IORESOURCE_MUXED)
wake_up(&muxed_resource_wait);
free_resource(res);
return;
}
- p = &res->sibling;
+ res = sibling(res);
}
write_unlock(&resource_lock);
@@ -1267,9 +1275,7 @@ EXPORT_SYMBOL(__release_region);
int release_mem_region_adjustable(struct resource *parent,
resource_size_t start, resource_size_t size)
{
- struct resource **p;
- struct resource *res;
- struct resource *new_res;
+ struct resource *res, *new_res;
resource_size_t end;
int ret = -EINVAL;
@@ -1280,16 +1286,16 @@ int release_mem_region_adjustable(struct resource *parent,
/* The alloc_resource() result gets checked later */
new_res = alloc_resource(GFP_KERNEL);
- p = &parent->child;
+ res = first_child(&parent->child);
write_lock(&resource_lock);
- while ((res = *p)) {
+ while ((res)) {
if (res->start >= end)
break;
/* look for the next resource if it does not fit into */
if (res->start > start || res->end < end) {
- p = &res->sibling;
+ res = sibling(res);
continue;
}
@@ -1297,14 +1303,14 @@ int release_mem_region_adjustable(struct resource *parent,
break;
if (!(res->flags & IORESOURCE_BUSY)) {
- p = &res->child;
+ res = first_child(&res->child);
continue;
}
/* found the target resource; let's adjust accordingly */
if (res->start == start && res->end == end) {
/* free the whole entry */
- *p = res->sibling;
+ list_del(&res->sibling);
free_resource(res);
ret = 0;
} else if (res->start == start && res->end != end) {
@@ -1327,14 +1333,13 @@ int release_mem_region_adjustable(struct resource *parent,
new_res->flags = res->flags;
new_res->desc = res->desc;
new_res->parent = res->parent;
- new_res->sibling = res->sibling;
- new_res->child = NULL;
+ INIT_LIST_HEAD(&new_res->child);
ret = __adjust_resource(res, res->start,
start - res->start);
if (ret)
break;
- res->sibling = new_res;
+ list_add(&new_res->sibling, &res->sibling);
new_res = NULL;
}
@@ -1515,7 +1520,7 @@ static int __init reserve_setup(char *str)
res->end = io_start + io_num - 1;
res->flags |= IORESOURCE_BUSY;
res->desc = IORES_DESC_NONE;
- res->child = NULL;
+ INIT_LIST_HEAD(&res->child);
if (request_resource(parent, res) == 0)
reserved = x+1;
}
@@ -1535,7 +1540,7 @@ int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
loff_t l;
read_lock(&resource_lock);
- for (p = p->child; p ; p = r_next(NULL, p, &l)) {
+ for (p = first_child(&p->child); p; p = r_next(NULL, p, &l)) {
/*
* We can probably skip the resources without
* IORESOURCE_IO attribute?
@@ -1591,7 +1596,7 @@ bool iomem_is_exclusive(u64 addr)
addr = addr & PAGE_MASK;
read_lock(&resource_lock);
- for (p = p->child; p ; p = r_next(NULL, p, &l)) {
+ for (p = first_child(&p->child); p; p = r_next(NULL, p, &l)) {
/*
* We can probably skip the resources without
* IORESOURCE_IO attribute?
--
2.13.6
^ permalink raw reply related
* Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource
From: kbuild test robot @ 2018-04-08 4:12 UTC (permalink / raw)
Cc: Brijesh Singh, devicetree-u79uwXL29TY76Z2rM5mHXA, David Airlie,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Wei Yang, Keith Busch,
Yaowei Bai, K. Y. Srinivasan, Frank Rowand, Thomas Gleixner,
Lorenzo Pieralisi, Stephen Hemminger, Baoquan He,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Patrik Jakobsson,
linux-input-u79uwXL29TY76Z2rM5mHXA, Borislav Petkov, Tom Lendacky,
Haiyang Zhang, Jérôme Glisse, Rob Herring,
Bjorn Helgaas, Jonathan Derrick
In-Reply-To: <20180408024724.16812-2-bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Baoquan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16 next-20180406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108
config: parisc-c3000_defconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
All errors (new ones prefixed by >>):
drivers//parisc/lba_pci.c: In function 'lba_dump_res':
>> drivers//parisc/lba_pci.c:173:15: error: incompatible type for argument 1 of 'lba_dump_res'
lba_dump_res(r->child, d+2);
^
drivers//parisc/lba_pci.c:162:1: note: expected 'struct resource *' but argument is of type 'struct list_head'
lba_dump_res(struct resource *r, int d)
^~~~~~~~~~~~
drivers//parisc/lba_pci.c:174:15: error: incompatible type for argument 1 of 'lba_dump_res'
lba_dump_res(r->sibling, d);
^
drivers//parisc/lba_pci.c:162:1: note: expected 'struct resource *' but argument is of type 'struct list_head'
lba_dump_res(struct resource *r, int d)
^~~~~~~~~~~~
vim +/lba_dump_res +173 drivers//parisc/lba_pci.c
^1da177e Linus Torvalds 2005-04-16 159
^1da177e Linus Torvalds 2005-04-16 160
^1da177e Linus Torvalds 2005-04-16 161 static void
^1da177e Linus Torvalds 2005-04-16 162 lba_dump_res(struct resource *r, int d)
^1da177e Linus Torvalds 2005-04-16 163 {
^1da177e Linus Torvalds 2005-04-16 164 int i;
^1da177e Linus Torvalds 2005-04-16 165
^1da177e Linus Torvalds 2005-04-16 166 if (NULL == r)
^1da177e Linus Torvalds 2005-04-16 167 return;
^1da177e Linus Torvalds 2005-04-16 168
^1da177e Linus Torvalds 2005-04-16 169 printk(KERN_DEBUG "(%p)", r->parent);
^1da177e Linus Torvalds 2005-04-16 170 for (i = d; i ; --i) printk(" ");
645d11d4 Matthew Wilcox 2006-12-24 171 printk(KERN_DEBUG "%p [%lx,%lx]/%lx\n", r,
645d11d4 Matthew Wilcox 2006-12-24 172 (long)r->start, (long)r->end, r->flags);
^1da177e Linus Torvalds 2005-04-16 @173 lba_dump_res(r->child, d+2);
^1da177e Linus Torvalds 2005-04-16 174 lba_dump_res(r->sibling, d);
^1da177e Linus Torvalds 2005-04-16 175 }
^1da177e Linus Torvalds 2005-04-16 176
:::::: The code at line 173 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds-gWtpgVMusWVb5UGfqNBoRg@public.gmane.org>
:::::: CC: Linus Torvalds <torvalds-gWtpgVMusWVb5UGfqNBoRg@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource
From: kbuild test robot @ 2018-04-08 5:55 UTC (permalink / raw)
Cc: Brijesh Singh, devicetree-u79uwXL29TY76Z2rM5mHXA, David Airlie,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Wei Yang, Keith Busch,
Yaowei Bai, K. Y. Srinivasan, Frank Rowand, Thomas Gleixner,
Lorenzo Pieralisi, Stephen Hemminger, Baoquan He,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Patrik Jakobsson,
linux-input-u79uwXL29TY76Z2rM5mHXA, Borislav Petkov, Tom Lendacky,
Haiyang Zhang, Jérôme Glisse, Rob Herring,
Bjorn Helgaas, Jonathan Derrick
In-Reply-To: <20180408024724.16812-2-bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Baoquan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16 next-20180406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
arch/sparc/kernel/ioport.c: In function 'sparc_io_proc_show':
>> arch/sparc/kernel/ioport.c:672:9: error: incompatible types when assigning to type 'struct resource *' from type 'struct list_head'
for (r = root->child; r != NULL; r = r->sibling) {
^
arch/sparc/kernel/ioport.c:672:37: error: incompatible types when assigning to type 'struct resource *' from type 'struct list_head'
for (r = root->child; r != NULL; r = r->sibling) {
^
vim +672 arch/sparc/kernel/ioport.c
^1da177e4 Linus Torvalds 2005-04-16 666
e7a088f93 Alexey Dobriyan 2009-09-01 667 static int sparc_io_proc_show(struct seq_file *m, void *v)
^1da177e4 Linus Torvalds 2005-04-16 668 {
e7a088f93 Alexey Dobriyan 2009-09-01 669 struct resource *root = m->private, *r;
^1da177e4 Linus Torvalds 2005-04-16 670 const char *nm;
^1da177e4 Linus Torvalds 2005-04-16 671
e7a088f93 Alexey Dobriyan 2009-09-01 @672 for (r = root->child; r != NULL; r = r->sibling) {
c31f76518 Sam Ravnborg 2014-04-21 673 if ((nm = r->name) == NULL) nm = "???";
e7a088f93 Alexey Dobriyan 2009-09-01 674 seq_printf(m, "%016llx-%016llx: %s\n",
685143ac1 Greg Kroah-Hartman 2006-06-12 675 (unsigned long long)r->start,
685143ac1 Greg Kroah-Hartman 2006-06-12 676 (unsigned long long)r->end, nm);
^1da177e4 Linus Torvalds 2005-04-16 677 }
^1da177e4 Linus Torvalds 2005-04-16 678
e7a088f93 Alexey Dobriyan 2009-09-01 679 return 0;
^1da177e4 Linus Torvalds 2005-04-16 680 }
^1da177e4 Linus Torvalds 2005-04-16 681
:::::: The code at line 672 was first introduced by commit
:::::: e7a088f935180b90cfe6ab0aaae8a556f46885fe sparc: convert /proc/io_map, /proc/dvma_map to seq_file
:::::: TO: Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
:::::: CC: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource
From: Baoquan He @ 2018-04-08 9:09 UTC (permalink / raw)
To: kbuild test robot
Cc: Brijesh Singh, devicetree-u79uwXL29TY76Z2rM5mHXA, David Airlie,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Wei Yang, Keith Busch,
Yaowei Bai, K. Y. Srinivasan, Frank Rowand, Thomas Gleixner,
Lorenzo Pieralisi, Stephen Hemminger,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Patrik Jakobsson,
linux-input-u79uwXL29TY76Z2rM5mHXA, Borislav Petkov, Tom Lendacky,
Haiyang Zhang, Jérôme Glisse, Rob Herring,
Bjorn Helgaas, Jonathan Derrick, Greg Kroah-Hartman
In-Reply-To: <201804081247.F3eqBMih%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hi,
Thanks for telling!
On 04/08/18 at 12:12pm, kbuild test robot wrote:
> Hi Baoquan,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16 next-20180406]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108
> config: parisc-c3000_defconfig (attached as .config)
> compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=parisc
>
> All errors (new ones prefixed by >>):
>
> drivers//parisc/lba_pci.c: In function 'lba_dump_res':
> >> drivers//parisc/lba_pci.c:173:15: error: incompatible type for argument 1 of 'lba_dump_res'
> lba_dump_res(r->child, d+2);
I compiled with allyesconfig, don't know why this was missed. Will
change and repost.
> ^
> drivers//parisc/lba_pci.c:162:1: note: expected 'struct resource *' but argument is of type 'struct list_head'
> lba_dump_res(struct resource *r, int d)
> ^~~~~~~~~~~~
> drivers//parisc/lba_pci.c:174:15: error: incompatible type for argument 1 of 'lba_dump_res'
> lba_dump_res(r->sibling, d);
> ^
> drivers//parisc/lba_pci.c:162:1: note: expected 'struct resource *' but argument is of type 'struct list_head'
> lba_dump_res(struct resource *r, int d)
> ^~~~~~~~~~~~
>
> vim +/lba_dump_res +173 drivers//parisc/lba_pci.c
>
> ^1da177e Linus Torvalds 2005-04-16 159
> ^1da177e Linus Torvalds 2005-04-16 160
> ^1da177e Linus Torvalds 2005-04-16 161 static void
> ^1da177e Linus Torvalds 2005-04-16 162 lba_dump_res(struct resource *r, int d)
> ^1da177e Linus Torvalds 2005-04-16 163 {
> ^1da177e Linus Torvalds 2005-04-16 164 int i;
> ^1da177e Linus Torvalds 2005-04-16 165
> ^1da177e Linus Torvalds 2005-04-16 166 if (NULL == r)
> ^1da177e Linus Torvalds 2005-04-16 167 return;
> ^1da177e Linus Torvalds 2005-04-16 168
> ^1da177e Linus Torvalds 2005-04-16 169 printk(KERN_DEBUG "(%p)", r->parent);
> ^1da177e Linus Torvalds 2005-04-16 170 for (i = d; i ; --i) printk(" ");
> 645d11d4 Matthew Wilcox 2006-12-24 171 printk(KERN_DEBUG "%p [%lx,%lx]/%lx\n", r,
> 645d11d4 Matthew Wilcox 2006-12-24 172 (long)r->start, (long)r->end, r->flags);
> ^1da177e Linus Torvalds 2005-04-16 @173 lba_dump_res(r->child, d+2);
> ^1da177e Linus Torvalds 2005-04-16 174 lba_dump_res(r->sibling, d);
> ^1da177e Linus Torvalds 2005-04-16 175 }
> ^1da177e Linus Torvalds 2005-04-16 176
>
> :::::: The code at line 173 was first introduced by commit
> :::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
>
> :::::: TO: Linus Torvalds <torvalds-gWtpgVMusWVb5UGfqNBoRg@public.gmane.org>
> :::::: CC: Linus Torvalds <torvalds-gWtpgVMusWVb5UGfqNBoRg@public.gmane.org>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox