Re: [PATCH] gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist

[Ian W MORRISON]

On Sat, 24 Aug 2019 at 07:53, Hans de Goede  wrote:
>
> To avoid problems like this, this commit adds a new
> gpiolib_acpi_run_edge_events_on_boot kernel commandline option which
> can be "on", "off", or "auto" (default).
>
> In auto mode the default is on and a DMI based blacklist is used,
> the initial version of this blacklist contains the Minix Neo Z83-4
> fixing the HDMI being broken on this device.
>

Many thanks Hans. I've tested the patch including the command line
option with both v5.3-rc5 and linux-next on a Minix Neo Z83-4 and it
works fine.

Best regards,
Ian

Re: [PATCH] Skip deferred request irqs for devices known to fail

[Ian W MORRISON]

Hi Hans and everyone,

On Mon, 19 Aug 2019 at 04:59, Hans de Goede  wrote:
>
> Hi Ian, et. al.,
>
> As such I guess we may need to go with the blacklist patch you suggested
> which sucks, but having these devices not boot sucks even harder.
>
> I guess this problem did not magically fix it self in the mean time
> (with newer kernels) ?
>

Unfortunately it didn't 'self-fix' with later kernels.

> Can you resubmit your patch with Andy's review remarks addressed?
>
> In case you've lost Andy's reply I will reproduce the review remarks
> below.
>
> Regards,
>
> Hans
>

Resubmitted as requested.

Many thanks and best regards,
Ian

[PATCH v2] Skip deferred request irqs for devices known to fail

[Ian W MORRISON]

Patch ca876c7483b6 "gpiolib-acpi: make sure we trigger edge events at
least once on boot" causes the MINIX family of mini PCs to fail to boot
resulting in a "black screen". 

This patch excludes MINIX devices from executing this trigger in order
to successfully boot.

Cc: sta...@vger.kernel.org
Signed-off-by: Ian W MORRISON 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
---
 drivers/gpio/gpiolib-acpi.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index fdee8afa5339..f6c3dcdc91c9 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +21,17 @@
 #include "gpiolib.h"
 #include "gpiolib-acpi.h"
 
+static const struct dmi_system_id skip_deferred_request_irqs_table[] = {
+   {
+   .ident = "MINIX Z83-4",
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "MINIX"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"),
+   },
+   },
+   {}
+};
+
 /**
  * struct acpi_gpio_event - ACPI GPIO event handler data
  *
@@ -1273,19 +1285,28 @@ bool acpi_can_fallback_to_crs(struct acpi_device *adev, 
const char *con_id)
return con_id == NULL;
 }
 
-/* Run deferred acpi_gpiochip_request_irqs() */
+/*
+ * Run deferred acpi_gpiochip_request_irqs()
+ * but exclude devices known to fail
+*/
 static int acpi_gpio_handle_deferred_request_irqs(void)
 {
struct acpi_gpio_chip *acpi_gpio, *tmp;
+   const struct dmi_system_id *dmi_id;
 
-   mutex_lock(_gpio_deferred_req_irqs_lock);
-   list_for_each_entry_safe(acpi_gpio, tmp,
+   dmi_id = dmi_first_match(skip_deferred_request_irqs_table);
+   if (dmi_id)
+   return 0;
+   else {
+   mutex_lock(_gpio_deferred_req_irqs_lock);
+   list_for_each_entry_safe(acpi_gpio, tmp,
 _gpio_deferred_req_irqs_list,
 deferred_req_irqs_list_entry)
-   acpi_gpiochip_request_irqs(acpi_gpio);
+   acpi_gpiochip_request_irqs(acpi_gpio);
 
-   acpi_gpio_deferred_req_irqs_done = true;
-   mutex_unlock(_gpio_deferred_req_irqs_lock);
+   acpi_gpio_deferred_req_irqs_done = true;
+   mutex_unlock(_gpio_deferred_req_irqs_lock);
+   }
 
return 0;
 }
-- 
2.17.1

[PATCH] Skip deferred request irqs for devices known to fail

[Ian W MORRISON]

Patch ca876c7483b6 "gpiolib-acpi: make sure we trigger edge events at
least once on boot" causes the MINIX family of mini PCs to fail to boot
resulting in a "black screen". 

This patch excludes MINIX devices from executing this trigger in order
to successfully boot.

Cc: sta...@vger.kernel.org
Signed-off-by: Ian W MORRISON 
---
 drivers/gpio/gpiolib-acpi.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index 259cf6ab969b..8d855dc9b020 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -16,9 +16,21 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "gpiolib.h"
 
+static const struct dmi_system_id skip_deferred_request_irqs_table[] = {
+   {
+   .ident = "MINIX Z83-4",
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "MINIX"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"),
+   },
+   },
+   {}
+};
+
 /**
  * struct acpi_gpio_event - ACPI GPIO event handler data
  *
@@ -1219,18 +1231,24 @@ bool acpi_can_fallback_to_crs(struct acpi_device *adev, 
const char *con_id)
 }
 
 /* Run deferred acpi_gpiochip_request_irqs() */
+/* but exclude devices known to fail */
 static int acpi_gpio_handle_deferred_request_irqs(void)
 {
struct acpi_gpio_chip *acpi_gpio, *tmp;
+   const struct dmi_system_id *dmi_id;
 
-   mutex_lock(_gpio_deferred_req_irqs_lock);
-   list_for_each_entry_safe(acpi_gpio, tmp,
+   dmi_id = dmi_first_match(skip_deferred_request_irqs_table);
+
+   if (! dmi_id) {
+   mutex_lock(_gpio_deferred_req_irqs_lock);
+   list_for_each_entry_safe(acpi_gpio, tmp,
 _gpio_deferred_req_irqs_list,
 deferred_req_irqs_list_entry)
-   acpi_gpiochip_request_irqs(acpi_gpio);
+   acpi_gpiochip_request_irqs(acpi_gpio);
 
-   acpi_gpio_deferred_req_irqs_done = true;
-   mutex_unlock(_gpio_deferred_req_irqs_lock);
+   acpi_gpio_deferred_req_irqs_done = true;
+   mutex_unlock(_gpio_deferred_req_irqs_lock);
+   }
 
return 0;
 }
-- 
2.17.1

[PATCH] Use default .cfg file name for RTL8723BS devices with id of OBDA8723

[Ian W MORRISON]

For RTL8723BS devices the current config file name is a composite of
both the config name (rtl8723bs) and a postfix of the device-id.

Given the majority of RTL8723BS devices use a device-id of OBDA8723
this simplifies the config file name to use "rtl8723bs_config.bin"
as a default of for these devices.

Signed-off-by: Ian W MORRISON 
---
 drivers/bluetooth/hci_h5.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 8eede1197cd2..cce422dc1b8d 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -852,7 +852,9 @@ static int h5_btrtl_setup(struct h5 *h5)
bool flow_control;
int err;
 
-   btrtl_dev = btrtl_initialize(h5->hu->hdev, h5->id);
+   btrtl_dev = strcmp("OBDA8723", h5->id) ?
+   btrtl_initialize(h5->hu->hdev, h5->id) :
+   btrtl_initialize(h5->hu->hdev, NULL);
if (IS_ERR(btrtl_dev))
return PTR_ERR(btrtl_dev);
 
-- 
2.17.1

[PATCH] Use default .cfg file name for RTL8723BS devices with id of OBDA8723

[Ian W MORRISON]

For RTL8723BS devices the current config file name is a composite of
both the config name (rtl8723bs) and a postfix of the device-id.

Given the majority of RTL8723BS devices use a device-id of OBDA8723
this simplifies the config file name to use "rtl8723bs_config.bin"
as a default of for these devices.

Signed-off-by: Ian W MORRISON 
---
 drivers/bluetooth/hci_h5.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 8eede1197cd2..cce422dc1b8d 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -852,7 +852,9 @@ static int h5_btrtl_setup(struct h5 *h5)
bool flow_control;
int err;
 
-   btrtl_dev = btrtl_initialize(h5->hu->hdev, h5->id);
+   btrtl_dev = strcmp("OBDA8723", h5->id) ?
+   btrtl_initialize(h5->hu->hdev, h5->id) :
+   btrtl_initialize(h5->hu->hdev, NULL);
if (IS_ERR(btrtl_dev))
return PTR_ERR(btrtl_dev);
 
-- 
2.17.1

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

Hi Anusha,

Can I ask if this is on anyone's radar as I'm concerned this patch will
stall otherwise?

I see that the significance of testing with the 4.14 kernel enabled the
firmware to be included in the latest Chrome OS kernel (
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/jtpHvZOfZ-Q).
It is important to similarly include in the mainline and stable kernels to
facilitate various distros that are now raising bug reports (for example:
https://bugs.launchpad.net/intel/+bug/1760545).

Many thanks,
Ian
On Sun, 22 Apr 2018 at 08:46, Ian W MORRISON <ianwmorri...@gmail.com> wrote:

> On 21 April 2018 at 11:22, Botello Ortega, Luis
> <luis.botello.ort...@intel.com> wrote:
> > Hi all:
> >
> > We tested GLK DMC 1.04 FW in last week of September 2017, using the
latest drm-tip version for that time (4.14.0-rc2) and according to our
results we could declare this FW as acceptable and healthy to be used with
kernel version 4.14 .
> > However, we cannot guarantee quality and healthy of this FW if it is
used in top of current drm-tip kernel (4.17-rc0).
> >
> > Best Regards
> > Luis Botello
> >
> >

> Your measured response is appreciated and raises at least four
> possible alternatives for this patch to proceed:

> 1. It is normal that firmware is *only* tested at a certain point in
> time with the drm-tip version of the mainline kernel so that the
> statement 'firmware X is acceptable and healthy to be used with kernel
> version Y but is not guaranteed with Y+1 or Y+n' always holds true for
> any microarchitecture codename's DMC firmware. Therefore it is
> appropriate for this patch to have a restricted 'Cc:
> sta...@vger.kernel.org # 4.14' tag together with an explicit
> 'Tested-by: (in 4.14)' tag.
> 2. As firmware testing was not performed on 4.15 and subsequent
> versions, testing is still required on versions 4.15 through to the
> current RC of version 4.17 for the patch to receive a 'Tested-by:' tag
> together with a 'Cc: sta...@vger.kernel.org # 4.14' tag.
> 3. Further firmware testing will only be undertaken for the current RC
> of version 4.17 and on successful completion the patch will only
> receive a 'Tested-by:' tag. A 'Cc: sta...@vger.kernel.org' tag is not
> applicable.
> 4. The firmware was not tested on 4.15 and subsequent versions as it's
> functionality was provided by alternative means and therefore the
> patch is only required in version 4.14 and should have a 'Cc:
> sta...@vger.kernel.org # 4.14 only' tag together with a restricted
> 'Tested-by: (only in 4.14)' tag.

> Could you indicate which alternative is appropriate? If further
> firmware testing is required (as in points 2 or 3) then can an
> expected completion date be provided?

> Best regards,
> Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

Hi Anusha,

Can I ask if this is on anyone's radar as I'm concerned this patch will
stall otherwise?

I see that the significance of testing with the 4.14 kernel enabled the
firmware to be included in the latest Chrome OS kernel (
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/jtpHvZOfZ-Q).
It is important to similarly include in the mainline and stable kernels to
facilitate various distros that are now raising bug reports (for example:
https://bugs.launchpad.net/intel/+bug/1760545).

Many thanks,
Ian
On Sun, 22 Apr 2018 at 08:46, Ian W MORRISON  wrote:

> On 21 April 2018 at 11:22, Botello Ortega, Luis
>  wrote:
> > Hi all:
> >
> > We tested GLK DMC 1.04 FW in last week of September 2017, using the
latest drm-tip version for that time (4.14.0-rc2) and according to our
results we could declare this FW as acceptable and healthy to be used with
kernel version 4.14 .
> > However, we cannot guarantee quality and healthy of this FW if it is
used in top of current drm-tip kernel (4.17-rc0).
> >
> > Best Regards
> > Luis Botello
> >
> >

> Your measured response is appreciated and raises at least four
> possible alternatives for this patch to proceed:

> 1. It is normal that firmware is *only* tested at a certain point in
> time with the drm-tip version of the mainline kernel so that the
> statement 'firmware X is acceptable and healthy to be used with kernel
> version Y but is not guaranteed with Y+1 or Y+n' always holds true for
> any microarchitecture codename's DMC firmware. Therefore it is
> appropriate for this patch to have a restricted 'Cc:
> sta...@vger.kernel.org # 4.14' tag together with an explicit
> 'Tested-by: (in 4.14)' tag.
> 2. As firmware testing was not performed on 4.15 and subsequent
> versions, testing is still required on versions 4.15 through to the
> current RC of version 4.17 for the patch to receive a 'Tested-by:' tag
> together with a 'Cc: sta...@vger.kernel.org # 4.14' tag.
> 3. Further firmware testing will only be undertaken for the current RC
> of version 4.17 and on successful completion the patch will only
> receive a 'Tested-by:' tag. A 'Cc: sta...@vger.kernel.org' tag is not
> applicable.
> 4. The firmware was not tested on 4.15 and subsequent versions as it's
> functionality was provided by alternative means and therefore the
> patch is only required in version 4.14 and should have a 'Cc:
> sta...@vger.kernel.org # 4.14 only' tag together with a restricted
> 'Tested-by: (only in 4.14)' tag.

> Could you indicate which alternative is appropriate? If further
> firmware testing is required (as in points 2 or 3) then can an
> expected completion date be provided?

> Best regards,
> Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 21 April 2018 at 11:22, Botello Ortega, Luis
 wrote:
> Hi all:
>
> We tested GLK DMC 1.04 FW in last week of September 2017, using the latest 
> drm-tip version for that time (4.14.0-rc2) and according to our results we 
> could declare this FW as acceptable and healthy to be used with kernel 
> version 4.14 .
> However, we cannot guarantee quality and healthy of this FW if it is used in 
> top of current drm-tip kernel (4.17-rc0).
>
> Best Regards
> Luis Botello
>
>

Your measured response is appreciated and raises at least four
possible alternatives for this patch to proceed:

1. It is normal that firmware is *only* tested at a certain point in
time with the drm-tip version of the mainline kernel so that the
statement 'firmware X is acceptable and healthy to be used with kernel
version Y but is not guaranteed with Y+1 or Y+n' always holds true for
any microarchitecture codename's DMC firmware. Therefore it is
appropriate for this patch to have a restricted 'Cc:
sta...@vger.kernel.org # 4.14' tag together with an explicit
'Tested-by: (in 4.14)' tag.
2. As firmware testing was not performed on 4.15 and subsequent
versions, testing is still required on versions 4.15 through to the
current RC of version 4.17 for the patch to receive a 'Tested-by:' tag
together with a 'Cc: sta...@vger.kernel.org # 4.14' tag.
3. Further firmware testing will only be undertaken for the current RC
of version 4.17 and on successful completion the patch will only
receive a 'Tested-by:' tag. A 'Cc: sta...@vger.kernel.org' tag is not
applicable.
4. The firmware was not tested on 4.15 and subsequent versions as it's
functionality was provided by alternative means and therefore the
patch is only required in version 4.14 and should have a 'Cc:
sta...@vger.kernel.org # 4.14 only' tag together with a restricted
'Tested-by: (only in 4.14)' tag.

Could you indicate which alternative is appropriate? If further
firmware testing is required (as in points 2 or 3) then can an
expected completion date be provided?

Best regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 21 April 2018 at 11:22, Botello Ortega, Luis
 wrote:
> Hi all:
>
> We tested GLK DMC 1.04 FW in last week of September 2017, using the latest 
> drm-tip version for that time (4.14.0-rc2) and according to our results we 
> could declare this FW as acceptable and healthy to be used with kernel 
> version 4.14 .
> However, we cannot guarantee quality and healthy of this FW if it is used in 
> top of current drm-tip kernel (4.17-rc0).
>
> Best Regards
> Luis Botello
>
>

Your measured response is appreciated and raises at least four
possible alternatives for this patch to proceed:

1. It is normal that firmware is *only* tested at a certain point in
time with the drm-tip version of the mainline kernel so that the
statement 'firmware X is acceptable and healthy to be used with kernel
version Y but is not guaranteed with Y+1 or Y+n' always holds true for
any microarchitecture codename's DMC firmware. Therefore it is
appropriate for this patch to have a restricted 'Cc:
sta...@vger.kernel.org # 4.14' tag together with an explicit
'Tested-by: (in 4.14)' tag.
2. As firmware testing was not performed on 4.15 and subsequent
versions, testing is still required on versions 4.15 through to the
current RC of version 4.17 for the patch to receive a 'Tested-by:' tag
together with a 'Cc: sta...@vger.kernel.org # 4.14' tag.
3. Further firmware testing will only be undertaken for the current RC
of version 4.17 and on successful completion the patch will only
receive a 'Tested-by:' tag. A 'Cc: sta...@vger.kernel.org' tag is not
applicable.
4. The firmware was not tested on 4.15 and subsequent versions as it's
functionality was provided by alternative means and therefore the
patch is only required in version 4.14 and should have a 'Cc:
sta...@vger.kernel.org # 4.14 only' tag together with a restricted
'Tested-by: (only in 4.14)' tag.

Could you indicate which alternative is appropriate? If further
firmware testing is required (as in points 2 or 3) then can an
expected completion date be provided?

Best regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 20 April 2018 at 17:50, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Fri, 20 Apr 2018, Ian W MORRISON <ianwmorri...@gmail.com> wrote:
>> I've performed backport testing and some additional analysis as follows:
>
> What testing did you do beyond booting? Did you run igt?
>
> BR,
> Jani.

I did some basic testing including running a 4K video on Chrome whilst
running intel_gpu_top. The intel_gpu_top program doesn't display
anything on 4.12 either with or without the patch as neither I nor
Canonical enabled CONFIG_DRM_I915_ALPHA_SUPPORT. Do you think that the
stable tag should exclude 4.12 because of the 'alpha quality support'
and if so do you want a V2 of the patch?

Best regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 20 April 2018 at 17:50, Jani Nikula  wrote:
> On Fri, 20 Apr 2018, Ian W MORRISON  wrote:
>> I've performed backport testing and some additional analysis as follows:
>
> What testing did you do beyond booting? Did you run igt?
>
> BR,
> Jani.

I did some basic testing including running a 4K video on Chrome whilst
running intel_gpu_top. The intel_gpu_top program doesn't display
anything on 4.12 either with or without the patch as neither I nor
Canonical enabled CONFIG_DRM_I915_ALPHA_SUPPORT. Do you think that the
stable tag should exclude 4.12 because of the 'alpha quality support'
and if so do you want a V2 of the patch?

Best regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 18 April 2018 at 00:14, Joonas Lahtinen
<joonas.lahti...@linux.intel.com> wrote:
> Quoting Jani Nikula (2018-04-17 12:02:52)
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha" <anusha.sriva...@intel.com> wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W MORRISON <ianwmorri...@gmail.com>
>> >>Cc: Vivi, Rodrigo <rodrigo.v...@intel.com>; Srivatsa, Anusha
>> >><anusha.sriva...@intel.com>; Wajdeczko, Michal
>> >><michal.wajdec...@intel.com>; Greg KH <gre...@linuxfoundation.org>;
>> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
>> >>linux-kernel@vger.kernel.org;
>> >>sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
>> >>de...@lists.freedesktop.org
>> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
>> >>Geminilake



In summary so far:

Jani:
> NAK on indiscriminate Cc: stable. There are zero guarantees that
> older kernels will work with whatever firmware you throw at them.
> Who tested the firmware with v4.12 and later? We only have the CI
> results against *current* drm-tip. We don't even know about v4.16.
> I'm not going to ack and take responsibility for the stable backports
> unless someone actually comes forward with credible Tested-bys.

Anusha:
> The stable kernel version is 4.12 and beyond.
> It is appropriate to add the CC: stable in my opinion

Joonas:
> And even then, some distros will be surprised of the new MODULE_FIRMWARE
> and will need to update the linux-firmware package, too.

I've performed backport testing and some additional analysis as follows:

The DMC firmware for GLK was initially included in 4.11
  (commit: dbb28b5c3d3cb945a63030fab8d3894cf335ce19).
Then the firmware version was upgraded to 1.03 in 4.12
  (commit: f4a791819ed00a749a90387aa139706a507aa690).
However MODULE_FIRMWARE for the GLK DMC firmware
was also removed in 4.12
  (commit: d9321a03efcda867b3a8c6327e01808516f0acd7)
together with the firmware version being bumped to 1.04
  (commit: aebfd1d37194e00d4c417e7be97efeb736cd9c04).

The patch below effectively reverts commit d9321a03 because the GLK
firmware is now available in the linux-firmware repository.

To test stable backports I've used Ubuntu 18.04 (Beta 2) userspace with
both Ubuntu (generic) and self-compiled mainline (patched) kernels.
The conclusion was that the patch works across 4.12 to 4.17-rc1 kernels
additionally displaying a 'Possible missing firmware' message when
installing a kernel with the expected firmware missing.

The following are abridged backport test results:

Scenario: No DMC (glk_dmc_ver1_04.bin) firmware installed in
'/lib/firmware/i915'
  Test:Kernel installation ('grep -i dmc' output from 'apt install'):
4.12-generic and 4.15-generic:
  No output # as expected
4.12 to 4.17-rc1-patched:
  W: Possible missing firmware
/lib/firmware/i915/glk_dmc_ver1_04.bin for module i915
  Result: The effect of the patch is to add a 'Possible missing
firmware' message.
  Test: Booting ('grep -i dmc' output from 'dmesg'):
4.12-generic:
  No output # as expected
4.15-generic:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
4.12-patched:
  No output # as expected
4.13 to 4.14-patched:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
[https://01.org/linuxgraphics/downloads/firmware], disabling runtime
power management.
4.15 to 4.17-rc1-patched:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
  Result: The effect of the patch does not change existing
(non-patched kernel) messages.

Scenario: DMC (glk_dmc_ver1_04.bin) firmware installed in '/lib/firmware/i915'
  Test:Kernel installation ('grep -i dmc' output from 'apt install')
All kernels:
  No messages # as expected
  Result: The effect of the patch does not change existing messages.
  Test" Booting ('grep -i dmc' output from 'dmesg'):
4.12-generic:
  No output # as expected
4.15-generic:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 18 April 2018 at 00:14, Joonas Lahtinen
 wrote:
> Quoting Jani Nikula (2018-04-17 12:02:52)
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W MORRISON 
>> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
>> >>; Wajdeczko, Michal
>> >>; Greg KH ;
>> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
>> >>linux-kernel@vger.kernel.org;
>> >>sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
>> >>de...@lists.freedesktop.org
>> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
>> >>Geminilake



In summary so far:

Jani:
> NAK on indiscriminate Cc: stable. There are zero guarantees that
> older kernels will work with whatever firmware you throw at them.
> Who tested the firmware with v4.12 and later? We only have the CI
> results against *current* drm-tip. We don't even know about v4.16.
> I'm not going to ack and take responsibility for the stable backports
> unless someone actually comes forward with credible Tested-bys.

Anusha:
> The stable kernel version is 4.12 and beyond.
> It is appropriate to add the CC: stable in my opinion

Joonas:
> And even then, some distros will be surprised of the new MODULE_FIRMWARE
> and will need to update the linux-firmware package, too.

I've performed backport testing and some additional analysis as follows:

The DMC firmware for GLK was initially included in 4.11
  (commit: dbb28b5c3d3cb945a63030fab8d3894cf335ce19).
Then the firmware version was upgraded to 1.03 in 4.12
  (commit: f4a791819ed00a749a90387aa139706a507aa690).
However MODULE_FIRMWARE for the GLK DMC firmware
was also removed in 4.12
  (commit: d9321a03efcda867b3a8c6327e01808516f0acd7)
together with the firmware version being bumped to 1.04
  (commit: aebfd1d37194e00d4c417e7be97efeb736cd9c04).

The patch below effectively reverts commit d9321a03 because the GLK
firmware is now available in the linux-firmware repository.

To test stable backports I've used Ubuntu 18.04 (Beta 2) userspace with
both Ubuntu (generic) and self-compiled mainline (patched) kernels.
The conclusion was that the patch works across 4.12 to 4.17-rc1 kernels
additionally displaying a 'Possible missing firmware' message when
installing a kernel with the expected firmware missing.

The following are abridged backport test results:

Scenario: No DMC (glk_dmc_ver1_04.bin) firmware installed in
'/lib/firmware/i915'
  Test:Kernel installation ('grep -i dmc' output from 'apt install'):
4.12-generic and 4.15-generic:
  No output # as expected
4.12 to 4.17-rc1-patched:
  W: Possible missing firmware
/lib/firmware/i915/glk_dmc_ver1_04.bin for module i915
  Result: The effect of the patch is to add a 'Possible missing
firmware' message.
  Test: Booting ('grep -i dmc' output from 'dmesg'):
4.12-generic:
  No output # as expected
4.15-generic:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
4.12-patched:
  No output # as expected
4.13 to 4.14-patched:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
[https://01.org/linuxgraphics/downloads/firmware], disabling runtime
power management.
4.15 to 4.17-rc1-patched:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
  Result: The effect of the patch does not change existing
(non-patched kernel) messages.

Scenario: DMC (glk_dmc_ver1_04.bin) firmware installed in '/lib/firmware/i915'
  Test:Kernel installation ('grep -i dmc' output from 'apt install')
All kernels:
  No messages # as expected
  Result: The effect of the patch does not change existing messages.
  Test" Booting ('grep -i dmc' output from 'dmesg'):
4.12-generic:
  No output # as expected
4.15-generic:
  i915 :00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
  i915 :00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
  i915 :00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
4.12-patched:
  No output # as expected
4.13 to 4.17-rc1-patched:
  [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
  Result: The effect of the patch is to remove the 'Failed to load' message.

Regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 11 April 2018 at 22:27, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Wed, 11 Apr 2018, Ian W MORRISON <ianwmorri...@gmail.com> wrote:
>> 
>>
>>>
>>> NAK on indiscriminate Cc: stable. There are zero guarantees that older
>>> kernels will work with whatever firmware you throw at them.
>>>
>>
>> I included 'Cc: stable' so the patch would get added to the v4.16 and
>> v4.15 kernels which I have tested with the patch. I found that earlier
>> kernels didn't support the 'linux-firmware' package required to get
>> wifi working on Intel's new Gemini Lake NUC.
>
> You realize that this patch should have nothing to do with wifi?
>

Yes. Runtime power management depends on the patch but when distros
such as Ubuntu are installed on a Intel Gemini Lake NUC as an example,
wifi/bluetooth depends on Intel Wireless-AC 9462 which in turn depends
on v4.15 as a minimum so my logic was to add the patch to 4.15 and later.

> Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate
> the specific versions of stable it is appropriate for.
>

Thanks you..

Best regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 11 April 2018 at 22:27, Jani Nikula  wrote:
> On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
>> 
>>
>>>
>>> NAK on indiscriminate Cc: stable. There are zero guarantees that older
>>> kernels will work with whatever firmware you throw at them.
>>>
>>
>> I included 'Cc: stable' so the patch would get added to the v4.16 and
>> v4.15 kernels which I have tested with the patch. I found that earlier
>> kernels didn't support the 'linux-firmware' package required to get
>> wifi working on Intel's new Gemini Lake NUC.
>
> You realize that this patch should have nothing to do with wifi?
>

Yes. Runtime power management depends on the patch but when distros
such as Ubuntu are installed on a Intel Gemini Lake NUC as an example,
wifi/bluetooth depends on Intel Wireless-AC 9462 which in turn depends
on v4.15 as a minimum so my logic was to add the patch to 4.15 and later.

> Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate
> the specific versions of stable it is appropriate for.
>

Thanks you..

Best regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

>
> NAK on indiscriminate Cc: stable. There are zero guarantees that older
> kernels will work with whatever firmware you throw at them.
>

I included 'Cc: stable' so the patch would get added to the v4.16 and
v4.15 kernels
which I have tested with the patch. I found that earlier kernels
didn't support the
'linux-firmware' package required to get wifi working on Intel's new
Gemini Lake NUC.

>
> PS. How is this a "RESEND"? I haven't seen this before.
>

It is a 'RESEND' for that very reason. I initially sent the patch to
the same people as
a similar patch (https://patchwork.kernel.org/patch/10143637/) however
after realising
this omitted required addresses I added them and resent the patch.

Best regards,
Ian

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

>
> NAK on indiscriminate Cc: stable. There are zero guarantees that older
> kernels will work with whatever firmware you throw at them.
>

I included 'Cc: stable' so the patch would get added to the v4.16 and
v4.15 kernels
which I have tested with the patch. I found that earlier kernels
didn't support the
'linux-firmware' package required to get wifi working on Intel's new
Gemini Lake NUC.

>
> PS. How is this a "RESEND"? I haven't seen this before.
>

It is a 'RESEND' for that very reason. I initially sent the patch to
the same people as
a similar patch (https://patchwork.kernel.org/patch/10143637/) however
after realising
this omitted required addresses I added them and resent the patch.

Best regards,
Ian

Re: [PATCH 1/7] staging: rtl8723bs: wifi_regd.c: put spaces around binary operators

[Ian W MORRISON]

On 14 June 2017 at 00:36, Dan Carpenter  wrote:
> Kernel style is to have spaces around the operators.  This is staging
> code so we do all the style fixes.  We don't always update older drivers
> but sometimes we do.  No one is planning to change those drivers though
> so I guess the answer is no we're not going to update those unless you
> are?
>

Thanks for the explanation. I assume submitting changes for the
drivers I identified would only be seen as minor corrections to 'the
chaff' resulting in unnecessary churn. If however it is expected that
corrections should be made when identified then I'm willing to prepare
a patch set. I'm happy to take advice either way.

Re: [PATCH 1/7] staging: rtl8723bs: wifi_regd.c: put spaces around binary operators

[Ian W MORRISON]

On 14 June 2017 at 00:36, Dan Carpenter  wrote:
> Kernel style is to have spaces around the operators.  This is staging
> code so we do all the style fixes.  We don't always update older drivers
> but sometimes we do.  No one is planning to change those drivers though
> so I guess the answer is no we're not going to update those unless you
> are?
>

Thanks for the explanation. I assume submitting changes for the
drivers I identified would only be seen as minor corrections to 'the
chaff' resulting in unnecessary churn. If however it is expected that
corrections should be made when identified then I'm willing to prepare
a patch set. I'm happy to take advice either way.

Re: [PATCH 1/7] staging: rtl8723bs: wifi_regd.c: put spaces around binary operators

[Ian W MORRISON]

On 12 June 2017 at 20:46, Fabian Wolff  wrote:
> This patch adds spaces around the binary operators '-' and '+', which
> is the preferred style, and reformats a pointer argument declaration
> to fix a false positive "spaces preferred around that '*'" message
> reported by checkpatch.pl.
>
> Signed-off-by: Fabian Wolff 
> Signed-off-by: Mate Horvath 
> ---
>  drivers/staging/rtl8723bs/os_dep/wifi_regd.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c 
> b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
> index 9c61125..803eab0 100644
> --- a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
> +++ b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
> @@ -20,7 +20,7 @@
>
>  /* 2G chan 01 - chan 11 */
>  #define RTW_2GHZ_CH01_11   \
> -   REG_RULE(2412-10, 2462+10, 40, 0, 20, 0)
> +   REG_RULE(2412 - 10, 2462 + 10, 40, 0, 20, 0)
>
>  /*
>   *We enable active scan on these a case
> @@ -29,12 +29,12 @@
>
>  /* 2G chan 12 - chan 13, PASSIV SCAN */
>  #define RTW_2GHZ_CH12_13   \
> -   REG_RULE(2467-10, 2472+10, 40, 0, 20,   \
> +   REG_RULE(2467 - 10, 2472 + 10, 40, 0, 20,   \
> NL80211_RRF_PASSIVE_SCAN)
>
>  /* 2G chan 14, PASSIVS SCAN, NO OFDM (B only) */
>  #define RTW_2GHZ_CH14  \
> -   REG_RULE(2484-10, 2484+10, 40, 0, 20,   \
> +   REG_RULE(2484 - 10, 2484 + 10, 40, 0, 20,   \
> NL80211_RRF_PASSIVE_SCAN | NL80211_RRF_NO_OFDM)
>

The construct 'freq_start-10, freq_end+10' is consistent with other drivers e.g.

drivers/net/wireless/mac80211_hwsim.c
drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c:#define
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
drivers/net/wireless/realtek/rtlwifi/regd.c
drivers/net/wireless/ath/regd.c

and looks better (to me) without the inserted spaces.

If the change is required will the other drivers be 'corrected'?

>  static const struct ieee80211_regdomain rtw_regdom_rd = {
> @@ -116,8 +116,8 @@ static int _rtw_reg_notifier_apply(struct wiphy *wiphy,
>  }
>
>  static const struct ieee80211_regdomain *_rtw_regdomain_select(struct
> -  rtw_regulatory
> -  *reg)
> +  rtw_regulatory 
> *
> +  reg)
>  {
> return _regdom_rd;
>  }
> --
> 2.7.4
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/7] staging: rtl8723bs: wifi_regd.c: put spaces around binary operators

[Ian W MORRISON]

On 12 June 2017 at 20:46, Fabian Wolff  wrote:
> This patch adds spaces around the binary operators '-' and '+', which
> is the preferred style, and reformats a pointer argument declaration
> to fix a false positive "spaces preferred around that '*'" message
> reported by checkpatch.pl.
>
> Signed-off-by: Fabian Wolff 
> Signed-off-by: Mate Horvath 
> ---
>  drivers/staging/rtl8723bs/os_dep/wifi_regd.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c 
> b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
> index 9c61125..803eab0 100644
> --- a/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
> +++ b/drivers/staging/rtl8723bs/os_dep/wifi_regd.c
> @@ -20,7 +20,7 @@
>
>  /* 2G chan 01 - chan 11 */
>  #define RTW_2GHZ_CH01_11   \
> -   REG_RULE(2412-10, 2462+10, 40, 0, 20, 0)
> +   REG_RULE(2412 - 10, 2462 + 10, 40, 0, 20, 0)
>
>  /*
>   *We enable active scan on these a case
> @@ -29,12 +29,12 @@
>
>  /* 2G chan 12 - chan 13, PASSIV SCAN */
>  #define RTW_2GHZ_CH12_13   \
> -   REG_RULE(2467-10, 2472+10, 40, 0, 20,   \
> +   REG_RULE(2467 - 10, 2472 + 10, 40, 0, 20,   \
> NL80211_RRF_PASSIVE_SCAN)
>
>  /* 2G chan 14, PASSIVS SCAN, NO OFDM (B only) */
>  #define RTW_2GHZ_CH14  \
> -   REG_RULE(2484-10, 2484+10, 40, 0, 20,   \
> +   REG_RULE(2484 - 10, 2484 + 10, 40, 0, 20,   \
> NL80211_RRF_PASSIVE_SCAN | NL80211_RRF_NO_OFDM)
>

The construct 'freq_start-10, freq_end+10' is consistent with other drivers e.g.

drivers/net/wireless/mac80211_hwsim.c
drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c:#define
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
drivers/net/wireless/realtek/rtlwifi/regd.c
drivers/net/wireless/ath/regd.c

and looks better (to me) without the inserted spaces.

If the change is required will the other drivers be 'corrected'?

>  static const struct ieee80211_regdomain rtw_regdom_rd = {
> @@ -116,8 +116,8 @@ static int _rtw_reg_notifier_apply(struct wiphy *wiphy,
>  }
>
>  static const struct ieee80211_regdomain *_rtw_regdomain_select(struct
> -  rtw_regulatory
> -  *reg)
> +  rtw_regulatory 
> *
> +  reg)
>  {
> return _regdom_rd;
>  }
> --
> 2.7.4
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 2 June 2017 at 00:48, Ian W MORRISON <ianwmorri...@gmail.com> wrote:
> On 6/1/17 5:49 PM, Ian W MORRISON wrote:
>> On 31 May 2017 at 10:53, Doug Smythies <dsmyth...@telus.net> wrote:
>>> Note Before:
>>> I might not have the address list correct, as I have re-created this
>>> e-mail from the web page archive, having found the thread after bisecting 
>>> the
>>> kernel.
>>>
>>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>>>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held <berny...@gmx.de> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this patch breaks the boot of my kernel. The last message is "Booting
>>>>>> the kernel.".
>>>
>>> It breaks my kernel boot also, and I know of at least two others with
>>> the same, or similar, problem as of kernel 4.12-rc3.
>>>
>>
>> Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom
>> (BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms
>> kernel panic with
>> [ 0.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
>> supported by secondary CPU
>>
>>
>> 
>>
>
> Confirmed that following patch fixes boot of v4.12-rc3 for Intel Atom Compute 
> Sticks:
>
> [PATCH] Fix X86_FEATURE_PAT regression bug
>



And for the sake of completeness, the revert patch
(https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent)
also fixes the boot of v4.12-rc3 for Intel Atom Compute Sticks (as
expected and now tested - yay).

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 2 June 2017 at 00:48, Ian W MORRISON  wrote:
> On 6/1/17 5:49 PM, Ian W MORRISON wrote:
>> On 31 May 2017 at 10:53, Doug Smythies  wrote:
>>> Note Before:
>>> I might not have the address list correct, as I have re-created this
>>> e-mail from the web page archive, having found the thread after bisecting 
>>> the
>>> kernel.
>>>
>>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>>>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this patch breaks the boot of my kernel. The last message is "Booting
>>>>>> the kernel.".
>>>
>>> It breaks my kernel boot also, and I know of at least two others with
>>> the same, or similar, problem as of kernel 4.12-rc3.
>>>
>>
>> Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom
>> (BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms
>> kernel panic with
>> [ 0.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
>> supported by secondary CPU
>>
>>
>> 
>>
>
> Confirmed that following patch fixes boot of v4.12-rc3 for Intel Atom Compute 
> Sticks:
>
> [PATCH] Fix X86_FEATURE_PAT regression bug
>



And for the sake of completeness, the revert patch
(https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent)
also fixes the boot of v4.12-rc3 for Intel Atom Compute Sticks (as
expected and now tested - yay).

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 6/1/17 5:49 PM, Ian W MORRISON wrote:
> On 31 May 2017 at 10:53, Doug Smythies <dsmyth...@telus.net> wrote:
>> Note Before:
>> I might not have the address list correct, as I have re-created this
>> e-mail from the web page archive, having found the thread after bisecting the
>> kernel.
>>
>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held <berny...@gmx.de> wrote:
>>>>> Hi,
>>>>>
>>>>> this patch breaks the boot of my kernel. The last message is "Booting
>>>>> the kernel.".
>>
>> It breaks my kernel boot also, and I know of at least two others with
>> the same, or similar, problem as of kernel 4.12-rc3.
>>
> 
> Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom
> (BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms
> kernel panic with
> [ 0.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
> supported by secondary CPU
> 
> 
> 
> 

Confirmed that following patch fixes boot of v4.12-rc3 for Intel Atom Compute 
Sticks:

[PATCH] Fix X86_FEATURE_PAT regression bug

Early kernel panic caused by checking for X86_FEATURE_PAT when enabled but not 
supported by secondary CPU.

Fixes cbed27cdf0e3 ("x86/PAT: Fix Xorg regression on CPUs that don't support 
PAT")
Signed-off-by: Ian W Morrison <ianwmorri...@gmail.com>
---
 arch/x86/mm/pat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 83a59a6..c537bfb 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -234,7 +234,7 @@ static void pat_bsp_init(u64 pat)
 
 static void pat_ap_init(u64 pat)
 {
-   if (!this_cpu_has(X86_FEATURE_PAT)) {
+   if (!boot_cpu_has(X86_FEATURE_PAT)) {
/*
 * If this happens we are on a secondary CPU, but switched to
 * PAT on the boot CPU. We have no way to undo PAT.
-- 
1.9.1

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 6/1/17 5:49 PM, Ian W MORRISON wrote:
> On 31 May 2017 at 10:53, Doug Smythies  wrote:
>> Note Before:
>> I might not have the address list correct, as I have re-created this
>> e-mail from the web page archive, having found the thread after bisecting the
>> kernel.
>>
>> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
>>>>> Hi,
>>>>>
>>>>> this patch breaks the boot of my kernel. The last message is "Booting
>>>>> the kernel.".
>>
>> It breaks my kernel boot also, and I know of at least two others with
>> the same, or similar, problem as of kernel 4.12-rc3.
>>
> 
> Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom
> (BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms
> kernel panic with
> [ 0.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
> supported by secondary CPU
> 
> 
> 
> 

Confirmed that following patch fixes boot of v4.12-rc3 for Intel Atom Compute 
Sticks:

[PATCH] Fix X86_FEATURE_PAT regression bug

Early kernel panic caused by checking for X86_FEATURE_PAT when enabled but not 
supported by secondary CPU.

Fixes cbed27cdf0e3 ("x86/PAT: Fix Xorg regression on CPUs that don't support 
PAT")
Signed-off-by: Ian W Morrison 
---
 arch/x86/mm/pat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 83a59a6..c537bfb 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -234,7 +234,7 @@ static void pat_bsp_init(u64 pat)
 
 static void pat_ap_init(u64 pat)
 {
-   if (!this_cpu_has(X86_FEATURE_PAT)) {
+   if (!boot_cpu_has(X86_FEATURE_PAT)) {
/*
 * If this happens we are on a secondary CPU, but switched to
 * PAT on the boot CPU. We have no way to undo PAT.
-- 
1.9.1

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 31 May 2017 at 10:53, Doug Smythies  wrote:
> Note Before:
> I might not have the address list correct, as I have re-created this
> e-mail from the web page archive, having found the thread after bisecting the
> kernel.
>
> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
 Hi,

 this patch breaks the boot of my kernel. The last message is "Booting
 the kernel.".
>
> It breaks my kernel boot also, and I know of at least two others with
> the same, or similar, problem as of kernel 4.12-rc3.
>

Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom
(BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms
kernel panic with
[ 0.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
supported by secondary CPU

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

[Ian W MORRISON]

On 31 May 2017 at 10:53, Doug Smythies  wrote:
> Note Before:
> I might not have the address list correct, as I have re-created this
> e-mail from the web page archive, having found the thread after bisecting the
> kernel.
>
> On 2017.05.29 18:50:57 -0400 (EDT) Mikulas Patocka wrote:
>> On Sun, 28 May 2017, Andy Lutomirski wrote:
>>> On Sun, May 28, 2017 at 11:18 AM, Bernhard Held  wrote:
 Hi,

 this patch breaks the boot of my kernel. The last message is "Booting
 the kernel.".
>
> It breaks my kernel boot also, and I know of at least two others with
> the same, or similar, problem as of kernel 4.12-rc3.
>

Just to add that I cannot boot v4.12-rc3 kernel with any Intel Atom
(BYT and CHT) Intel Compute Sticks. Adding 'earlyprintk=efi' confirms
kernel panic with
[ 0.00] Kernel panic - not syncing: x86/PAT: PAT enabled, but not
supported by secondary CPU

Re: [PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

On 9 May 2017 at 00:42, Andy Shevchenko <andy.shevche...@gmail.com> wrote:
> On Sun, May 7, 2017 at 1:04 PM, Ian W MORRISON <ianwmorri...@gmail.com> wrote:



>
> What are you trying to achieve by posting this patch over and over so often?
>
> Version 5 look pretty good to me. Just stop posting it again and wait
> when Greg takes it.
>

I made a series of errors in the patch submission due to inexperience
in submitting my very first patch. The visibility of my minor mistakes
in certainly not what I would have liked and I can only apologize for
the annoyance caused. I believe I have finally corrected the patch to
meet the exacting standards required and having learnt from the
experience I hope never to repeat them.

> FWIW (version 5!):
> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
>
> --
> With Best Regards,
> Andy Shevchenko

Thank you for your review,
Ian

Re: [PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

On 9 May 2017 at 00:42, Andy Shevchenko  wrote:
> On Sun, May 7, 2017 at 1:04 PM, Ian W MORRISON  wrote:



>
> What are you trying to achieve by posting this patch over and over so often?
>
> Version 5 look pretty good to me. Just stop posting it again and wait
> when Greg takes it.
>

I made a series of errors in the patch submission due to inexperience
in submitting my very first patch. The visibility of my minor mistakes
in certainly not what I would have liked and I can only apologize for
the annoyance caused. I believe I have finally corrected the patch to
meet the exacting standards required and having learnt from the
experience I hope never to repeat them.

> FWIW (version 5!):
> Reviewed-by: Andy Shevchenko 
>
> --
> With Best Regards,
> Andy Shevchenko

Thank you for your review,
Ian

[PATCH v6] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A re-positioned call to kfree() in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
causes a segmentation error. This patch removed the kfree() call.

Fixes 6557ddfec348 ("staging: rtl8723bs: Fix various errors in 
os_dep/ioctl_cfg80211.c")
Signed-off-by: Ian W Morrison <ianwmorri...@gmail.com>
Reviewed-by: Hans de Goede <hdego...@redhat.com>
---
This version of the patch (version 6) fixes errors in the patch submission.
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH v6] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A re-positioned call to kfree() in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
causes a segmentation error. This patch removed the kfree() call.

Fixes 6557ddfec348 ("staging: rtl8723bs: Fix various errors in 
os_dep/ioctl_cfg80211.c")
Signed-off-by: Ian W Morrison 
Reviewed-by: Hans de Goede 
---
This version of the patch (version 6) fixes errors in the patch submission.
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A kernel cloned from 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and 
built with the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) 
fails when booting on an Intel Atom device with the RTL8723BS wifi 
chipset due to an error in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c.

The kernel when booted with Ubuntu 17.04 results in an unusable system 
however with the following patch booting is successful and the system 
is usable. The patch and kernel builds have been tested against on an 
Intel Compute Stick (STCK1A32WFC model).

This version of the patch (version 5) has tabs rather than spaces, no 
wrap around, a changelog and a sign-off email. 

Reviewed-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Ian W Morrison <ianwmorri...@gmail.com>
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A kernel cloned from 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and 
built with the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) 
fails when booting on an Intel Atom device with the RTL8723BS wifi 
chipset due to an error in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c.

The kernel when booted with Ubuntu 17.04 results in an unusable system 
however with the following patch booting is successful and the system 
is usable. The patch and kernel builds have been tested against on an 
Intel Compute Stick (STCK1A32WFC model).

This version of the patch (version 5) has tabs rather than spaces, no 
wrap around, a changelog and a sign-off email. 

Reviewed-by: Hans de Goede 
Signed-off-by: Ian W Morrison 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH v4] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A kernel cloned from 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and 
built with the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) 
fails when booting on an Intel Atom device with the RTL8723BS wifi 
chipset due to an error in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c.

The kernel when booted with Ubuntu 17.04 results in an unusable system 
however with the following patch booting is successful and the system 
is usable. The patch and kernel builds have been tested against on an 
Intel Compute Stick (STCK1A32WFC model).

This version of the patch (version 4) has tabs rather than spaces, no 
wrap around and a changelog. The patch has received one review:

Patch looks good to me:
Reviewed-by: Hans de Goede <hdego...@redhat.com>

Signed-off-by: Ian W Morrison <linux...@linuxium.com.au>
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH v4] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A kernel cloned from 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and 
built with the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) 
fails when booting on an Intel Atom device with the RTL8723BS wifi 
chipset due to an error in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c.

The kernel when booted with Ubuntu 17.04 results in an unusable system 
however with the following patch booting is successful and the system 
is usable. The patch and kernel builds have been tested against on an 
Intel Compute Stick (STCK1A32WFC model).

This version of the patch (version 4) has tabs rather than spaces, no 
wrap around and a changelog. The patch has received one review:

Patch looks good to me:
Reviewed-by: Hans de Goede 

Signed-off-by: Ian W Morrison 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH v3] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A kernel cloned from 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and built with 
the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) fails when booting on 
an Intel Atom device with the RTL8723BS wifi chipset due to an error in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c.

The kernel when booted with Ubuntu 17.04 results in an unusable system however 
with the following patch booting is successful and the system is usable. The 
patch and kernel builds have been tested against on an Intel Compute Stick 
(STCK1A32WFC model).

This version of the patch (version 3) has tabs rather than spaces and no wrap 
around. The patch has received one review:

Patch looks good to me:
Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,
Ian

From: Ian W Morrison <linux...@linuxium.com.au>
Date: Fri, 28 Apr 2017 02:20:38 +1000
Subject: [PATCH] staging: rtl8723bs: remove a call to kfree in
 os_dep/ioctl_cfg80211.c

Signed-off-by: Ian W Morrison <linux...@linuxium.com.au>
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

[PATCH v3] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

[Ian W MORRISON]

A kernel cloned from 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and built with 
the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) fails when booting on 
an Intel Atom device with the RTL8723BS wifi chipset due to an error in 
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c.

The kernel when booted with Ubuntu 17.04 results in an unusable system however 
with the following patch booting is successful and the system is usable. The 
patch and kernel builds have been tested against on an Intel Compute Stick 
(STCK1A32WFC model).

This version of the patch (version 3) has tabs rather than spaces and no wrap 
around. The patch has received one review:

Patch looks good to me:
Reviewed-by: Hans de Goede 

Regards,
Ian

From: Ian W Morrison 
Date: Fri, 28 Apr 2017 02:20:38 +1000
Subject: [PATCH] staging: rtl8723bs: remove a call to kfree in
 os_dep/ioctl_cfg80211.c

Signed-off-by: Ian W Morrison 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, struct 
device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);
 
return ret;
 
-- 
1.9.1

Re: [GIT PULL] Staging/IIO driver fixes for 4.12-rc1

[Ian W MORRISON]

On 5/6/17 11:41 PM, Greg KH wrote:

On Sat, May 06, 2017 at 06:00:24PM +1000, Ian W MORRISON wrote:

The kernel when booted with Ubuntu 17.04 results in an unusable system
however with the following patch booting is successful and the system
is usable. The patch and kernel builds have been tested against on an
Intel Compute Stick (STCK1A32WFC model).

It's in my queue to get to after 4.12-rc1 is out, it's not lost.




The patch is whitespace dammaged and can not be applied :(

thanks,

greg k-h


Here it is from a different email client. Hopefully preserving the 
whitespaces.


From: Ian W Morrison <linux...@linuxium.com.au>
Date: Fri, 28 Apr 2017 02:20:38 +1000
Subject: [PATCH] staging: rtl8723bs: remove a call to kfree in
 os_dep/ioctl_cfg80211.c

Signed-off-by: Ian W Morrison <linux...@linuxium.com.au>
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c

index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, 
struct device *dev)

 pwdev_priv->power_mgmt = true;
 else
 pwdev_priv->power_mgmt = false;
-kfree((u8 *)wdev);

 return ret;

--
1.9.1

Re: [GIT PULL] Staging/IIO driver fixes for 4.12-rc1

[Ian W MORRISON]

On 5/6/17 11:41 PM, Greg KH wrote:

On Sat, May 06, 2017 at 06:00:24PM +1000, Ian W MORRISON wrote:

The kernel when booted with Ubuntu 17.04 results in an unusable system
however with the following patch booting is successful and the system
is usable. The patch and kernel builds have been tested against on an
Intel Compute Stick (STCK1A32WFC model).

It's in my queue to get to after 4.12-rc1 is out, it's not lost.




The patch is whitespace dammaged and can not be applied :(

thanks,

greg k-h


Here it is from a different email client. Hopefully preserving the 
whitespaces.


From: Ian W Morrison 
Date: Fri, 28 Apr 2017 02:20:38 +1000
Subject: [PATCH] staging: rtl8723bs: remove a call to kfree in
 os_dep/ioctl_cfg80211.c

Signed-off-by: Ian W Morrison 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c

index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter, 
struct device *dev)

 pwdev_priv->power_mgmt = true;
 else
 pwdev_priv->power_mgmt = false;
-kfree((u8 *)wdev);

 return ret;

--
1.9.1

Re: [GIT PULL] Staging/IIO driver fixes for 4.12-rc1

[Ian W MORRISON]

0-linuxium #1
[6.522851] Hardware name: Intel Corporation
STCK1A32WFC/STCK1A32WFC, BIOS FCBYT10H.86A.0032.2016.0831.1658
08/31/2016
[6.522986] task: 9e81af1f5500 task.stack: b8d900898000
[6.523109] RIP: 0010:cfg80211_netdev_notifier_call+0x256/0x620 [cfg80211]
[6.523200] RSP: :b8d90089b908 EFLAGS: 00010202
[6.523271] RAX: 6332692f RBX: 9e81bab6ec00 RCX: 73656369
[6.523362] RDX: c0805a8c RSI: c07e85c8 RDI: 9e81bab6ec48
[6.523452] RBP: b8d90089b9f8 R08: 9e81b9e1e560 R09: c07f4200
[6.523541] R10: b8d90089ba08 R11: 9e81b1e05a00 R12: 7665642f40646461
[6.523631] R13: 9e81b291e000 R14: 7665642f40646161 R15: 
[6.523721] FS:  7fbfa0f268c0() GS:9e81b9e0()
knlGS:
[6.523824] CS:  0010 DS:  ES:  CR0: 80050033
[6.523898] CR2: 55d1f6295f88 CR3: 705de000 CR4: 001006f0

The kernel when booted with Ubuntu 17.04 results in an unusable system
however with the following patch booting is successful and the system
is usable. The patch and kernel builds have been tested against on an
Intel Compute Stick (STCK1A32WFC model).

Regards,
Ian

From: Ian W Morrison <linux...@linuxium.com.au>
Date: Fri, 28 Apr 2017 02:20:38 +1000
Subject: [PATCH] staging: rtl8723bs: remove a call to kfree in
 os_dep/ioctl_cfg80211.c

Signed-off-by: Ian W Morrison <linux...@linuxium.com.au>
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter,
struct device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);

return ret;

--
1.9.1

Re: [GIT PULL] Staging/IIO driver fixes for 4.12-rc1

[Ian W MORRISON]

6.522851] Hardware name: Intel Corporation
STCK1A32WFC/STCK1A32WFC, BIOS FCBYT10H.86A.0032.2016.0831.1658
08/31/2016
[6.522986] task: 9e81af1f5500 task.stack: b8d900898000
[6.523109] RIP: 0010:cfg80211_netdev_notifier_call+0x256/0x620 [cfg80211]
[6.523200] RSP: :b8d90089b908 EFLAGS: 00010202
[6.523271] RAX: 6332692f RBX: 9e81bab6ec00 RCX: 73656369
[6.523362] RDX: c0805a8c RSI: c07e85c8 RDI: 9e81bab6ec48
[6.523452] RBP: b8d90089b9f8 R08: 9e81b9e1e560 R09: c07f4200
[6.523541] R10: b8d90089ba08 R11: 9e81b1e05a00 R12: 7665642f40646461
[6.523631] R13: 9e81b291e000 R14: 7665642f40646161 R15: 
[6.523721] FS:  7fbfa0f268c0() GS:9e81b9e0()
knlGS:
[6.523824] CS:  0010 DS:  ES:  CR0: 80050033
[6.523898] CR2: 55d1f6295f88 CR3: 705de000 CR4: 001006f0

The kernel when booted with Ubuntu 17.04 results in an unusable system
however with the following patch booting is successful and the system
is usable. The patch and kernel builds have been tested against on an
Intel Compute Stick (STCK1A32WFC model).

Regards,
Ian

From: Ian W Morrison 
Date: Fri, 28 Apr 2017 02:20:38 +1000
Subject: [PATCH] staging: rtl8723bs: remove a call to kfree in
 os_dep/ioctl_cfg80211.c

Signed-off-by: Ian W Morrison 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fb..2ee9df5 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3527,7 +3527,6 @@ int rtw_wdev_alloc(struct adapter *padapter,
struct device *dev)
pwdev_priv->power_mgmt = true;
else
pwdev_priv->power_mgmt = false;
-   kfree((u8 *)wdev);

return ret;

--
1.9.1