Re: [PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel

[CK Hu]

Hi, YT:

some comments inline.

On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 101 
> +
>  1 file changed, 80 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ded4202..0569f2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
>  #define CLK_HS_POST  (0xff << 8)
>  #define CLK_HS_EXIT  (0xff << 16)
>  
> +#define DSI_VM_CMD_CON   0x130
> +#define VM_CMD_ENBIT(0)
> +#define TS_VFP_ENBIT(5)
> +
>  #define DSI_CMDQ00x180
>  #define CONFIG   (0xff << 0)
>  #define SHORT_PACKET 0
> @@ -249,7 +253,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>* mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
>* we set mipi_ratio is 1.05.
>*/
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
> + dsi->data_rate /= (dsi->lanes * 1000 * 10);

This looks like a bug fix that use lanes to calculate data rate.

> + DRM_DEBUG_DRIVER("set mipitx's data rate: %dMHz\n", dsi->data_rate);
>  
>   ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 100);
>   if (ret < 0) {
> @@ -333,16 +339,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
>   u32 vid_mode = CMD_MODE;
>  
>   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
>   vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
>   }
>  
>   writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
>  }
>  
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
>  static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
>  {
>   struct videomode *vm = >vm;
> @@ -480,6 +493,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
>   writel(1, dsi->regs + DSI_START);
>  }
>  
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
>  static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
>  {
>   u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -538,6 +561,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 
> t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -546,11 +582,6 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>   if (--dsi->refcount != 0)
>   return;
>  
> - mtk_dsi_lane0_ulp_mode_enter(dsi);
> - mtk_dsi_clk_ulp_mode_enter(dsi);
> -
> - mtk_dsi_disable(dsi);
> -
>   clk_disable_unprepare(dsi->engine_clk);
>   clk_disable_unprepare(dsi->digital_clk);
>  
> @@ -564,13 +595,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>   if (dsi->enabled)
>   return;
>  
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
>   ret = mtk_dsi_poweron(dsi);
>   if (ret < 0) {
>   DRM_ERROR("failed to power on dsi\n");
> @@ -578,21 +602,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + 

Re: [PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel

[CK Hu]

Hi, YT:

some comments inline.

On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 101 
> +
>  1 file changed, 80 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ded4202..0569f2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
>  #define CLK_HS_POST  (0xff << 8)
>  #define CLK_HS_EXIT  (0xff << 16)
>  
> +#define DSI_VM_CMD_CON   0x130
> +#define VM_CMD_ENBIT(0)
> +#define TS_VFP_ENBIT(5)
> +
>  #define DSI_CMDQ00x180
>  #define CONFIG   (0xff << 0)
>  #define SHORT_PACKET 0
> @@ -249,7 +253,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>* mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
>* we set mipi_ratio is 1.05.
>*/
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
> + dsi->data_rate /= (dsi->lanes * 1000 * 10);

This looks like a bug fix that use lanes to calculate data rate.

> + DRM_DEBUG_DRIVER("set mipitx's data rate: %dMHz\n", dsi->data_rate);
>  
>   ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 100);
>   if (ret < 0) {
> @@ -333,16 +339,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
>   u32 vid_mode = CMD_MODE;
>  
>   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
>   vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
>   }
>  
>   writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
>  }
>  
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
>  static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
>  {
>   struct videomode *vm = >vm;
> @@ -480,6 +493,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
>   writel(1, dsi->regs + DSI_START);
>  }
>  
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
>  static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
>  {
>   u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -538,6 +561,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 
> t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -546,11 +582,6 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>   if (--dsi->refcount != 0)
>   return;
>  
> - mtk_dsi_lane0_ulp_mode_enter(dsi);
> - mtk_dsi_clk_ulp_mode_enter(dsi);
> -
> - mtk_dsi_disable(dsi);
> -
>   clk_disable_unprepare(dsi->engine_clk);
>   clk_disable_unprepare(dsi->digital_clk);
>  
> @@ -564,13 +595,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>   if (dsi->enabled)
>   return;
>  
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
>   ret = mtk_dsi_poweron(dsi);
>   if (ret < 0) {
>   DRM_ERROR("failed to power on dsi\n");
> @@ -578,21 +602,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);

Even though dsi does not directly 

Re: [PATCH] auxdisplay: ht16k33: select required CONFIG_FB_CFB_* helpers

[Robin van der Gracht]

On Tue, 29 Nov 2016 21:04:30 +0100
Greg Kroah-Hartman  wrote:

> On Tue, Nov 29, 2016 at 08:55:50PM +0100, Arnd Bergmann wrote:
> > On Tuesday, November 29, 2016 8:42:47 PM CET Greg Kroah-Hartman wrote:  
> > > On Fri, Nov 25, 2016 at 10:50:07AM +0100, Robin van der Gracht wrote:  
> > > > This selects the respective helpers required in addition to the one
> > > > Arnd Bergmann pointer out earlier.
> > > > 
> > > > Signed-off-by: Robin van der Gracht 
> > > > ---
> > > > This is a responce to https://lkml.org/lkml/2016/11/25/66
> > > > This patch complements the changes Arnd submitted earlier. 
> > > > 
> > > >  drivers/auxdisplay/Kconfig | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
> > > > index b8bbfc6..4ef4c5c 100644
> > > > --- a/drivers/auxdisplay/Kconfig
> > > > +++ b/drivers/auxdisplay/Kconfig
> > > > @@ -132,6 +132,9 @@ config HT16K33
> > > > tristate "Holtek Ht16K33 LED controller with keyscan"
> > > > depends on FB && OF && I2C && INPUT
> > > > select FB_SYS_FOPS
> > > > +   select FB_CFB_FILLRECT
> > > > +   select FB_CFB_COPYAREA
> > > > +   select FB_CFB_IMAGEBLIT
> > > > select INPUT_MATRIXKMAP
> > > > select FB_BACKLIGHT
> > > > help  
> > > 
> > > What tree is this patch against?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > >   
> > 
> > It's on top of my patch "auxdisplay: ht16k33: select CONFIG_FB_SYS_FOPS"
> > from a few days ago. I guess Robin expected you to have picked that
> > up, while you expected him to combine it with the new changes.
> > 
> > Robin, I think it's easier if you send the combined patch and
> > add "Reported-by: Arnd Bergmann ", as Greg has
> > probably already droppped my earlier patch from his queue.  
> 
> Yes, it's not in my queue anymore.
> 
> thanks,
> 
> greg k-h

I'll create a new patch.

Regards,
Robin

Re: [PATCH] auxdisplay: ht16k33: select required CONFIG_FB_CFB_* helpers

[Robin van der Gracht]

On Tue, 29 Nov 2016 21:04:30 +0100
Greg Kroah-Hartman  wrote:

> On Tue, Nov 29, 2016 at 08:55:50PM +0100, Arnd Bergmann wrote:
> > On Tuesday, November 29, 2016 8:42:47 PM CET Greg Kroah-Hartman wrote:  
> > > On Fri, Nov 25, 2016 at 10:50:07AM +0100, Robin van der Gracht wrote:  
> > > > This selects the respective helpers required in addition to the one
> > > > Arnd Bergmann pointer out earlier.
> > > > 
> > > > Signed-off-by: Robin van der Gracht 
> > > > ---
> > > > This is a responce to https://lkml.org/lkml/2016/11/25/66
> > > > This patch complements the changes Arnd submitted earlier. 
> > > > 
> > > >  drivers/auxdisplay/Kconfig | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
> > > > index b8bbfc6..4ef4c5c 100644
> > > > --- a/drivers/auxdisplay/Kconfig
> > > > +++ b/drivers/auxdisplay/Kconfig
> > > > @@ -132,6 +132,9 @@ config HT16K33
> > > > tristate "Holtek Ht16K33 LED controller with keyscan"
> > > > depends on FB && OF && I2C && INPUT
> > > > select FB_SYS_FOPS
> > > > +   select FB_CFB_FILLRECT
> > > > +   select FB_CFB_COPYAREA
> > > > +   select FB_CFB_IMAGEBLIT
> > > > select INPUT_MATRIXKMAP
> > > > select FB_BACKLIGHT
> > > > help  
> > > 
> > > What tree is this patch against?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > >   
> > 
> > It's on top of my patch "auxdisplay: ht16k33: select CONFIG_FB_SYS_FOPS"
> > from a few days ago. I guess Robin expected you to have picked that
> > up, while you expected him to combine it with the new changes.
> > 
> > Robin, I think it's easier if you send the combined patch and
> > add "Reported-by: Arnd Bergmann ", as Greg has
> > probably already droppped my earlier patch from his queue.  
> 
> Yes, it's not in my queue anymore.
> 
> thanks,
> 
> greg k-h

I'll create a new patch.

Regards,
Robin

[PATCH] isofs: add KERN_CONT to printing of ER records

[Mike Rapoport]

The ER records are printed without explicit log level presuming line
continuation until "\n". After the commit 4bcc595ccd8 (printk: reinstate
KERN_CONT for printing continuation lines), the ER records are printed
a character per line.
Adding KERN_CONT to appropriate printk statements restores the printout
behavior.

Signed-off-by: Mike Rapoport 
---
 fs/isofs/rock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index 98b3eb7..0ec1373 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -377,9 +377,9 @@ int get_rock_ridge_filename(struct iso_directory_record *de,
{
int p;
for (p = 0; p < rr->u.ER.len_id; p++)
-   printk("%c", rr->u.ER.data[p]);
+   printk(KERN_CONT "%c", 
rr->u.ER.data[p]);
}
-   printk("\n");
+   printk(KERN_CONT "\n");
break;
case SIG('P', 'X'):
inode->i_mode = isonum_733(rr->u.PX.mode);
-- 
1.9.1

[PATCH] isofs: add KERN_CONT to printing of ER records

[Mike Rapoport]

The ER records are printed without explicit log level presuming line
continuation until "\n". After the commit 4bcc595ccd8 (printk: reinstate
KERN_CONT for printing continuation lines), the ER records are printed
a character per line.
Adding KERN_CONT to appropriate printk statements restores the printout
behavior.

Signed-off-by: Mike Rapoport 
---
 fs/isofs/rock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index 98b3eb7..0ec1373 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -377,9 +377,9 @@ int get_rock_ridge_filename(struct iso_directory_record *de,
{
int p;
for (p = 0; p < rr->u.ER.len_id; p++)
-   printk("%c", rr->u.ER.data[p]);
+   printk(KERN_CONT "%c", 
rr->u.ER.data[p]);
}
-   printk("\n");
+   printk(KERN_CONT "\n");
break;
case SIG('P', 'X'):
inode->i_mode = isonum_733(rr->u.PX.mode);
-- 
1.9.1

Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x

[Jacek Anaszewski]

Hi Tin,

How this patch is different from the one already merged?

Best regards,
Jacek Anaszewski

On 11/30/2016 04:08 AM, Tin Huynh wrote:

This patch enables ACPI support for leds-pca955x driver.

Signed-off-by: Tin Huynh 
---
 drivers/leds/leds-pca955x.c |   22 +-
 1 files changed, 21 insertions(+), 1 deletions(-)

Change from V2:
 -Correct coding conventions.

Change from V1:
 -Remove CONFIG_ACPI.

diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
index 840401a..b168ebe 100644
--- a/drivers/leds/leds-pca955x.c
+++ b/drivers/leds/leds-pca955x.c
@@ -40,6 +40,7 @@
  *  bits the chip supports.
  */

+#include 
 #include 
 #include 
 #include 
@@ -100,6 +101,15 @@ struct pca955x_chipdef {
 };
 MODULE_DEVICE_TABLE(i2c, pca955x_id);

+static const struct acpi_device_id pca955x_acpi_ids[] = {
+   { .id = "PCA9550", .driver_data = pca9550 },
+   { .id = "PCA9551", .driver_data = pca9551 },
+   { .id = "PCA9552", .driver_data = pca9552 },
+   { .id = "PCA9553", .driver_data = pca9553 },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+
 struct pca955x {
struct mutex lock;
struct pca955x_led *leds;
@@ -250,7 +260,16 @@ static int pca955x_probe(struct i2c_client *client,
struct led_platform_data *pdata;
int i, err;

-   chip = _chipdefs[id->driver_data];
+   if (id) {
+   chip = _chipdefs[id->driver_data];
+   } else {
+   const struct acpi_device_id *acpi_id;
+
+   acpi_id = acpi_match_device(pca955x_acpi_ids, >dev);
+   if (!acpi_id)
+   return -ENODEV;
+   chip = _chipdefs[acpi_id->driver_data];
+   }
adapter = to_i2c_adapter(client->dev.parent);
pdata = dev_get_platdata(>dev);

@@ -358,6 +377,7 @@ static int pca955x_remove(struct i2c_client *client)
 static struct i2c_driver pca955x_driver = {
.driver = {
.name   = "leds-pca955x",
+   .acpi_match_table = ACPI_PTR(pca955x_acpi_ids),
},
.probe  = pca955x_probe,
.remove = pca955x_remove,

Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x

[Jacek Anaszewski]

Hi Tin,

How this patch is different from the one already merged?

Best regards,
Jacek Anaszewski

On 11/30/2016 04:08 AM, Tin Huynh wrote:

This patch enables ACPI support for leds-pca955x driver.

Signed-off-by: Tin Huynh 
---
 drivers/leds/leds-pca955x.c |   22 +-
 1 files changed, 21 insertions(+), 1 deletions(-)

Change from V2:
 -Correct coding conventions.

Change from V1:
 -Remove CONFIG_ACPI.

diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
index 840401a..b168ebe 100644
--- a/drivers/leds/leds-pca955x.c
+++ b/drivers/leds/leds-pca955x.c
@@ -40,6 +40,7 @@
  *  bits the chip supports.
  */

+#include 
 #include 
 #include 
 #include 
@@ -100,6 +101,15 @@ struct pca955x_chipdef {
 };
 MODULE_DEVICE_TABLE(i2c, pca955x_id);

+static const struct acpi_device_id pca955x_acpi_ids[] = {
+   { .id = "PCA9550", .driver_data = pca9550 },
+   { .id = "PCA9551", .driver_data = pca9551 },
+   { .id = "PCA9552", .driver_data = pca9552 },
+   { .id = "PCA9553", .driver_data = pca9553 },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+
 struct pca955x {
struct mutex lock;
struct pca955x_led *leds;
@@ -250,7 +260,16 @@ static int pca955x_probe(struct i2c_client *client,
struct led_platform_data *pdata;
int i, err;

-   chip = _chipdefs[id->driver_data];
+   if (id) {
+   chip = _chipdefs[id->driver_data];
+   } else {
+   const struct acpi_device_id *acpi_id;
+
+   acpi_id = acpi_match_device(pca955x_acpi_ids, >dev);
+   if (!acpi_id)
+   return -ENODEV;
+   chip = _chipdefs[acpi_id->driver_data];
+   }
adapter = to_i2c_adapter(client->dev.parent);
pdata = dev_get_platdata(>dev);

@@ -358,6 +377,7 @@ static int pca955x_remove(struct i2c_client *client)
 static struct i2c_driver pca955x_driver = {
.driver = {
.name   = "leds-pca955x",
+   .acpi_match_table = ACPI_PTR(pca955x_acpi_ids),
},
.probe  = pca955x_probe,
.remove = pca955x_remove,

Re: [PATCH 17/39] mtd: nand: denali: support HW_ECC_FIXUP capability

[Boris Brezillon]

On Wed, 30 Nov 2016 15:20:10 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 
> 2016-11-28 1:09 GMT+09:00 Boris Brezillon 
> :
> _bitflips);
> >
> > Okay, so you currently have two ways of handling ECC errors. What if a
> > new revision introduces yet another way to do it?
> >
> > How about making denali_caps a structure where you have one (or several)
> > function pointers to implement operations differently depending on the
> > IP revision?
> >
> > struct denali_caps {
> > u32 feature_flags; /* If needed. */
> > bool (*handle_ecc)(...);
> > ...
> > };
> >  
> 
> I think a problem is the difference of function arguments:
> 
> static bool denali_hw_ecc_fixup(struct denali_nand_info *denali,
> unsigned int *max_bitflips)
> 
>  vs
> 
> static bool denali_sw_ecc_fixup(struct denali_nand_info *denali, u8 *buf,
> u32 irq_status, unsigned int *max_bitflips)
> 
> 
> I do not want to pass redundant arguments,
> which are used for one, but not used for the other.
> 

We do that all the time when defining generic interfaces.

> 
> We do not need to think about the situation that may not happen.
> If happens, we can refactor the code any time.
> 

Well, as I said in my other reply, I still think it's better to plan
for this now, rather than having to change a lot things when we appear
to need this. But that's only my POV, and I don't care enough to fight.

Re: [PATCH 17/39] mtd: nand: denali: support HW_ECC_FIXUP capability

[Boris Brezillon]

On Wed, 30 Nov 2016 15:20:10 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 
> 2016-11-28 1:09 GMT+09:00 Boris Brezillon 
> :
> _bitflips);
> >
> > Okay, so you currently have two ways of handling ECC errors. What if a
> > new revision introduces yet another way to do it?
> >
> > How about making denali_caps a structure where you have one (or several)
> > function pointers to implement operations differently depending on the
> > IP revision?
> >
> > struct denali_caps {
> > u32 feature_flags; /* If needed. */
> > bool (*handle_ecc)(...);
> > ...
> > };
> >  
> 
> I think a problem is the difference of function arguments:
> 
> static bool denali_hw_ecc_fixup(struct denali_nand_info *denali,
> unsigned int *max_bitflips)
> 
>  vs
> 
> static bool denali_sw_ecc_fixup(struct denali_nand_info *denali, u8 *buf,
> u32 irq_status, unsigned int *max_bitflips)
> 
> 
> I do not want to pass redundant arguments,
> which are used for one, but not used for the other.
> 

We do that all the time when defining generic interfaces.

> 
> We do not need to think about the situation that may not happen.
> If happens, we can refactor the code any time.
> 

Well, as I said in my other reply, I still think it's better to plan
for this now, rather than having to change a lot things when we appear
to need this. But that's only my POV, and I don't care enough to fight.

Re: [PATCH 04/39] mtd: nand: denali: remove more unused struct members

[Boris Brezillon]

On Wed, 30 Nov 2016 16:16:35 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 
> 2016-11-28 0:12 GMT+09:00 Boris Brezillon 
> :
> > On Sun, 27 Nov 2016 03:05:50 +0900
> > Masahiro Yamada  wrote:
> >
> > Please add a description here.
> >
> > Also, this commit tends to validate my fears: you should have wait for
> > the full rework/cleanup to be done before submitting the first round of
> > cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused
> > struct member denali_nand_info::idx") was removing one of these unused
> > fields, leaving 2 of them behind.  
> 
> Right.
> No difference except that
> denali->idx was initialized to zero(, but not referenced).
> 
> I could squash the two patches.

That's not a big deal.

> 
> 
> > While I like when things I clearly separated in different commits, when
> > you push the logic too far, you end up with big series which are not
> > necessarily easier to review, and several commits that are achieving
> > the same goal...  
> 
> 
> I must admit that I hurried up in posting the first round.
> But, please note I did not ask you to pick it up for v4.10-rc1.
> After all, it was your choice whether you picked it soon or
> waited until you saw the big picture.
> You could have postponed it until v4.11-rc1 if you had wanted.

That's true. But it was not clear from your cover letter that you
were posting this series just to get feedback and not necessarily to
get them applied.

> 
> My idea was, I'd like to get feedback earlier
> (especially from Intel engineers).
> 
> I fear that I do not reveal anything until I complete my work.
> If I am doing wrong in the early patches in my big series,
> I might end up with lots of effort to turn around.
> 
> I dropped various Intel-specific things,
> for example commit c9e025843242 ("mtd: nand: denali: remove
> detect_partition_feature()")
> removed the whole function I do not understand.
> There was possibility that it might be locally used by Intel platforms.
> 
> If I had gotten negative comments for removal, I'd have needed more efforts
> to not break any old functions.
> 
> As a result, nobody was opposed to delete such things.
> So, I can confidently continue my work on cleaner and more *stable* base.
> 
> 

Okay, got it. So, I should not apply any patches from this series until
you've completed your rework (round2+3 posted).
I think I'll still apply patch 1 early, because it's not directly
related to the denali rework, and the fix looks good.

Regards,

Boris

Re: [PATCH 04/39] mtd: nand: denali: remove more unused struct members

[Boris Brezillon]

On Wed, 30 Nov 2016 16:16:35 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 
> 2016-11-28 0:12 GMT+09:00 Boris Brezillon 
> :
> > On Sun, 27 Nov 2016 03:05:50 +0900
> > Masahiro Yamada  wrote:
> >
> > Please add a description here.
> >
> > Also, this commit tends to validate my fears: you should have wait for
> > the full rework/cleanup to be done before submitting the first round of
> > cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused
> > struct member denali_nand_info::idx") was removing one of these unused
> > fields, leaving 2 of them behind.  
> 
> Right.
> No difference except that
> denali->idx was initialized to zero(, but not referenced).
> 
> I could squash the two patches.

That's not a big deal.

> 
> 
> > While I like when things I clearly separated in different commits, when
> > you push the logic too far, you end up with big series which are not
> > necessarily easier to review, and several commits that are achieving
> > the same goal...  
> 
> 
> I must admit that I hurried up in posting the first round.
> But, please note I did not ask you to pick it up for v4.10-rc1.
> After all, it was your choice whether you picked it soon or
> waited until you saw the big picture.
> You could have postponed it until v4.11-rc1 if you had wanted.

That's true. But it was not clear from your cover letter that you
were posting this series just to get feedback and not necessarily to
get them applied.

> 
> My idea was, I'd like to get feedback earlier
> (especially from Intel engineers).
> 
> I fear that I do not reveal anything until I complete my work.
> If I am doing wrong in the early patches in my big series,
> I might end up with lots of effort to turn around.
> 
> I dropped various Intel-specific things,
> for example commit c9e025843242 ("mtd: nand: denali: remove
> detect_partition_feature()")
> removed the whole function I do not understand.
> There was possibility that it might be locally used by Intel platforms.
> 
> If I had gotten negative comments for removal, I'd have needed more efforts
> to not break any old functions.
> 
> As a result, nobody was opposed to delete such things.
> So, I can confidently continue my work on cleaner and more *stable* base.
> 
> 

Okay, got it. So, I should not apply any patches from this series until
you've completed your rework (round2+3 posted).
I think I'll still apply patch 1 early, because it's not directly
related to the denali rework, and the fix looks good.

Regards,

Boris

Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c

[Paul E. McKenney]

On Wed, Nov 30, 2016 at 08:16:02AM +0100, Michal Hocko wrote:
> On Tue 29-11-16 11:14:48, Paul E. McKenney wrote:
> > On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
> > > On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
> > >  wrote:
> > > >
> > > > FYI, we noticed the following commit:
> > > >
> > > > commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent 
> > > > __alloc_pages_nodemask() RCU CPU stall warnings")
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > > rcu/next
> > > >
> > > > in testcase: boot
> > > >
> > > > on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 
> > > > 1G
> > > >
> > > > caused below changes:
> > > >
> > > [...]
> > > 
> > > > [8.953192] BUG: sleeping function called from invalid context at 
> > > > mm/page_alloc.c:3746
> > > > [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: 
> > > > swapper/0
> > > 
> > > I am observing similar BUG/backtrace even on ARM64 platform.
> > 
> > Does the (untested) patch below help?
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > commit ccc0666e2049e5818c236e647cf20c552a7b053b
> > Author: Paul E. McKenney 
> > Date:   Tue Nov 29 11:06:05 2016 -0800
> > 
> > rcu: Allow boot-time use of cond_resched_rcu_qs()
> > 
> > The cond_resched_rcu_qs() macro is used to force RCU quiescent states 
> > into
> > long-running in-kernel loops.  However, some of these loops can execute
> > during early boot when interrupts are disabled, and during which time
> > it is therefore illegal to enter the scheduler.  This commit therefore
> > makes cond_resched_rcu_qs() be a no-op during early boot.
> > 
> > Signed-off-by: Paul E. McKenney 
> 
> This is not the problem with your "mm: Prevent __alloc_pages_nodemask()
> RCU CPU stall warnings", though. The main problem imho is that the
> allocator might be called from the atomic contexts (aka
> gfp_mask & ~__GFP_DIRECT_RECLAIM). Besides that I do not think that any
> variant of cond_resched inside the allocator hot path
> __alloc_pages_nodemask is just wrong. If anything such a scheduling/RCU
> point should be added to the slow path. But as I've said earlier we
> already have these points in that path so new ones shouldn't be really
> necessary.
> 
> Could you drop this patch Paul, please?

Good point, dropped.

Boris's test results show that something else is needed, will review
his splats and see what else presents itself.

Thanx, Paul

Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c

[Paul E. McKenney]

On Wed, Nov 30, 2016 at 08:16:02AM +0100, Michal Hocko wrote:
> On Tue 29-11-16 11:14:48, Paul E. McKenney wrote:
> > On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
> > > On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
> > >  wrote:
> > > >
> > > > FYI, we noticed the following commit:
> > > >
> > > > commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent 
> > > > __alloc_pages_nodemask() RCU CPU stall warnings")
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > > rcu/next
> > > >
> > > > in testcase: boot
> > > >
> > > > on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 
> > > > 1G
> > > >
> > > > caused below changes:
> > > >
> > > [...]
> > > 
> > > > [8.953192] BUG: sleeping function called from invalid context at 
> > > > mm/page_alloc.c:3746
> > > > [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: 
> > > > swapper/0
> > > 
> > > I am observing similar BUG/backtrace even on ARM64 platform.
> > 
> > Does the (untested) patch below help?
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > commit ccc0666e2049e5818c236e647cf20c552a7b053b
> > Author: Paul E. McKenney 
> > Date:   Tue Nov 29 11:06:05 2016 -0800
> > 
> > rcu: Allow boot-time use of cond_resched_rcu_qs()
> > 
> > The cond_resched_rcu_qs() macro is used to force RCU quiescent states 
> > into
> > long-running in-kernel loops.  However, some of these loops can execute
> > during early boot when interrupts are disabled, and during which time
> > it is therefore illegal to enter the scheduler.  This commit therefore
> > makes cond_resched_rcu_qs() be a no-op during early boot.
> > 
> > Signed-off-by: Paul E. McKenney 
> 
> This is not the problem with your "mm: Prevent __alloc_pages_nodemask()
> RCU CPU stall warnings", though. The main problem imho is that the
> allocator might be called from the atomic contexts (aka
> gfp_mask & ~__GFP_DIRECT_RECLAIM). Besides that I do not think that any
> variant of cond_resched inside the allocator hot path
> __alloc_pages_nodemask is just wrong. If anything such a scheduling/RCU
> point should be added to the slow path. But as I've said earlier we
> already have these points in that path so new ones shouldn't be really
> necessary.
> 
> Could you drop this patch Paul, please?

Good point, dropped.

Boris's test results show that something else is needed, will review
his splats and see what else presents itself.

Thanx, Paul

[PATCH] cpufreq: dt: Add support for zx296718

[Baoyou Xie]

Add the compatible string for supporting the generic cpufreq driver on
the ZTE's zx296718 SoC.

Signed-off-by: Baoyou Xie 
---
 drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 7126762..c0a28e23b 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -81,6 +81,8 @@ static const struct of_device_id machines[] __initconst = {
 
{ .compatible = "xlnx,zynq-7000", },
 
+   { .compatible = "zte,zx296718", },
+
{ }
 };
 
-- 
2.7.4

[PATCH] cpufreq: dt: Add support for zx296718

[Baoyou Xie]

Add the compatible string for supporting the generic cpufreq driver on
the ZTE's zx296718 SoC.

Signed-off-by: Baoyou Xie 
---
 drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 7126762..c0a28e23b 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -81,6 +81,8 @@ static const struct of_device_id machines[] __initconst = {
 
{ .compatible = "xlnx,zynq-7000", },
 
+   { .compatible = "zte,zx296718", },
+
{ }
 };
 
-- 
2.7.4

RE: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer

[Andy Duan]

From: Nikita Yushchenko  Sent: Wednesday, 
November 30, 2016 2:36 PM
 >To: Andy Duan ; David S. Miller
 >; Troy Kisky ;
 >Andrew Lunn ; Eric Nelson ; Philippe
 >Reynes ; Johannes Berg ;
 >net...@vger.kernel.org
 >Cc: Chris Healy ; Fabio Estevam
 >; linux-kernel@vger.kernel.org
 >Subject: Re: [patch net / RFC] net: fec: increase frame size limitation to
 >actually available buffer
 >
 >> But I think it is not necessary since the driver don't support jumbo frame.
 >
 >Hardcoded 1522 raises two separate issues.
 >
 >(1) When DSA is in use, frames processed by FEC chip contain DSA tag and
 >thus can be larger than hardcoded limit of 1522. This issue is not 
 >FEC-specific,
 >any driver that hardcodes maximum frame size to 1522 (many
 >do) will have this issue if used with DSA.
 >
 >Clean solution for this must take into account that difference between MTU
 >and max frame size is no longer known at compile time. Actually this is the
 >case even without DSA, due to VLANs: max frame size is (MTU + 18) without
 >VLANs, but (MTU + 22) with VLANs. However currently drivers tend to ignore
 >this and hardcode 22.  With DSA, 22 is not enough, need to add switch-
 >specific tag size to that.
 >
 >Not yet sure how to handle this. DSA-specific API to find out tag size could 
 >be
 >added, but generic solution should handle all cases of dynamic difference
 >between MTU and max frame size, not only DSA.
 >
 >
 >(2) There is some demand to use larger frames for optimization purposes.
 >
 >FEC register fields that limit frame size are 14-bit, thus allowing frames up 
 >to
 >(4k-1). I'm about to prepare a larger patch:
 >- add ndo_change_mtu handler, allowing MTU up to (4k - overhead),
 >- set MAX_FL / TRUNC_FL based on configured MTU,
 >- if necessary, do buffer reallocation with larger buffers.
 >
 >Is this suitable for upstreaming?
 >Is there any policy related to handling larger frames?

Of course, welcome to upstream the jumbo frame patches, but hope to also add 
the transmit jumbo frame, not only receive path, which is helpful for testing 
with two boards connection.
And, some notes need you to care:
- the maximum jumbo frame should consider the fifo size. Different chip has 
different fifo size. Like i.MX53 tx and rx share one fifo, i.mx6q/dl/sl have 
separate 4k fifo for tx and rx, i.mx6sx/i.mx7x have separate 8k fifo for tx and 
rx.
- rx fifo watermark to generate pause frame in busy loading system to avoid 
fifo overrun. In general,  little pause frames bring better performance, mass 
of pause frames cause worse performance.


Regards,
Andy

RE: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer

[Andy Duan]

From: Nikita Yushchenko  Sent: Wednesday, 
November 30, 2016 2:36 PM
 >To: Andy Duan ; David S. Miller
 >; Troy Kisky ;
 >Andrew Lunn ; Eric Nelson ; Philippe
 >Reynes ; Johannes Berg ;
 >net...@vger.kernel.org
 >Cc: Chris Healy ; Fabio Estevam
 >; linux-kernel@vger.kernel.org
 >Subject: Re: [patch net / RFC] net: fec: increase frame size limitation to
 >actually available buffer
 >
 >> But I think it is not necessary since the driver don't support jumbo frame.
 >
 >Hardcoded 1522 raises two separate issues.
 >
 >(1) When DSA is in use, frames processed by FEC chip contain DSA tag and
 >thus can be larger than hardcoded limit of 1522. This issue is not 
 >FEC-specific,
 >any driver that hardcodes maximum frame size to 1522 (many
 >do) will have this issue if used with DSA.
 >
 >Clean solution for this must take into account that difference between MTU
 >and max frame size is no longer known at compile time. Actually this is the
 >case even without DSA, due to VLANs: max frame size is (MTU + 18) without
 >VLANs, but (MTU + 22) with VLANs. However currently drivers tend to ignore
 >this and hardcode 22.  With DSA, 22 is not enough, need to add switch-
 >specific tag size to that.
 >
 >Not yet sure how to handle this. DSA-specific API to find out tag size could 
 >be
 >added, but generic solution should handle all cases of dynamic difference
 >between MTU and max frame size, not only DSA.
 >
 >
 >(2) There is some demand to use larger frames for optimization purposes.
 >
 >FEC register fields that limit frame size are 14-bit, thus allowing frames up 
 >to
 >(4k-1). I'm about to prepare a larger patch:
 >- add ndo_change_mtu handler, allowing MTU up to (4k - overhead),
 >- set MAX_FL / TRUNC_FL based on configured MTU,
 >- if necessary, do buffer reallocation with larger buffers.
 >
 >Is this suitable for upstreaming?
 >Is there any policy related to handling larger frames?

Of course, welcome to upstream the jumbo frame patches, but hope to also add 
the transmit jumbo frame, not only receive path, which is helpful for testing 
with two boards connection.
And, some notes need you to care:
- the maximum jumbo frame should consider the fifo size. Different chip has 
different fifo size. Like i.MX53 tx and rx share one fifo, i.mx6q/dl/sl have 
separate 4k fifo for tx and rx, i.mx6sx/i.mx7x have separate 8k fifo for tx and 
rx.
- rx fifo watermark to generate pause frame in busy loading system to avoid 
fifo overrun. In general,  little pause frames bring better performance, mass 
of pause frames cause worse performance.


Regards,
Andy

Re: [patch v2 1/2] mm, zone: track number of movable free pages

[Vlastimil Babka]

On 11/30/2016 01:16 AM, David Rientjes wrote:

An upcoming compaction change will need the number of movable free pages
per zone to determine if async compaction will become unnecessarily
expensive.

This patch introduces no functional change or increased memory footprint.
It simply tracks the number of free movable pages as a subset of the
total number of free pages.  This is exported to userspace as part of a
new /proc/vmstat field.

Signed-off-by: David Rientjes 
---
 v2: do not track free pages per migratetype since page allocator stress
 testing reveals this tracking can impact workloads and there is no
 substantial benefit when thp is disabled.  This occurs because
 entire pageblocks can be converted to new migratetypes and requires
 iteration of free_areas in the hotpaths for proper tracking.


Ah, right, forgot about the accuracy issue when focusing on the overhead 
issue. Unfortunately I'm afraid the NR_FREE_MOVABLE_PAGES in this patch 
will also drift uncontrollably over time. Stealing is one thing, and 
also buddy merging can silently move free pages between migratetypes. It 
already took some effort to make this accurate for MIGRATE_CMA and 
MIGRATE_ISOLATE, which has some overhead and works only thanks to 
additional constraints - CMA pageblocks don't ever get converted, and 
for ISOLATE we don't put them on pcplists, perform pcplists draining 
during isolation, and have extra code guarded by has_isolate_pageblock() 
in buddy merging. None of this would be directly viable for 
MIGRATE_MOVABLE I'm afraid.



 include/linux/mmzone.h | 1 +
 include/linux/vmstat.h | 2 ++
 mm/page_alloc.c| 8 +++-
 mm/vmstat.c| 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -138,6 +138,7 @@ enum zone_stat_item {
NUMA_OTHER, /* allocation from other node */
 #endif
NR_FREE_CMA_PAGES,
+   NR_FREE_MOVABLE_PAGES,
NR_VM_ZONE_STAT_ITEMS };

 enum node_stat_item {
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -347,6 +347,8 @@ static inline void __mod_zone_freepage_state(struct zone 
*zone, int nr_pages,
__mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages);
if (is_migrate_cma(migratetype))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES, nr_pages);
+   if (migratetype == MIGRATE_MOVABLE)
+   __mod_zone_page_state(zone, NR_FREE_MOVABLE_PAGES, nr_pages);
 }

 extern const char * const vmstat_text[];
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2197,6 +2197,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
spin_lock(>lock);
for (i = 0; i < count; ++i) {
struct page *page = __rmqueue(zone, order, migratetype);
+   int mt;
+
if (unlikely(page == NULL))
break;

@@ -2217,9 +2219,13 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
else
list_add_tail(>lru, list);
list = >lru;
-   if (is_migrate_cma(get_pcppage_migratetype(page)))
+   mt = get_pcppage_migratetype(page);
+   if (is_migrate_cma(mt))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
  -(1 << order));
+   if (mt == MIGRATE_MOVABLE)
+   __mod_zone_page_state(zone, NR_FREE_MOVABLE_PAGES,
+ -(1 << order));
}
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
spin_unlock(>lock);
diff --git a/mm/vmstat.c b/mm/vmstat.c
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -945,6 +945,7 @@ const char * const vmstat_text[] = {
"numa_other",
 #endif
"nr_free_cma",
+   "nr_free_movable",

/* Node-based counters */
"nr_inactive_anon",

[PATCH] arm64: dts: add zx296718's topcrm node

[Baoyou Xie]

Enable topcrm clock node for zx296718, which is used for
CPU's frequency change.

Furthermore, this patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.

So it can be used by cpufreq-dt driver.

Signed-off-by: Baoyou Xie 
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi 
b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..f9eb37d 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+   clocks = < A53_GATE>;
+   operating-points-v2 = <_opp>;
};
 
cpu1: cpu@1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+   operating-points-v2 = <_opp>;
};
 
cpu2: cpu@2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+   operating-points-v2 = <_opp>;
};
 
cpu3: cpu@3 {
@@ -102,6 +107,43 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+   operating-points-v2 = <_opp>;
+   };
+   };
+
+   cluster0_opp: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@10 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <857000>;
+   clock-latency-ns = <50>;
+   };
+   opp@11 {
+   opp-hz = /bits/ 64 <64800>;
+   opp-microvolt = <857000>;
+   clock-latency-ns = <50>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <882000>;
+   clock-latency-ns = <50>;
+   };
+   opp@13 {
+   opp-hz = /bits/ 64 <10>;
+   opp-microvolt = <892000>;
+   clock-latency-ns = <50>;
+   };
+   opp@14 {
+   opp-hz = /bits/ 64 <118800>;
+   opp-microvolt = <1009000>;
+   clock-latency-ns = <50>;
+   };
+   opp@15 {
+   opp-hz = /bits/ 64 <131200>;
+   opp-microvolt = <1052000>;
+   clock-latency-ns = <50>;
};
};
 
@@ -279,6 +321,12 @@
dma-requests = <32>;
};
 
+   topcrm: clock-controller@01461000 {
+   compatible = "zte,zx296718-topcrm";
+   reg = <0x01461000 0x1000>;
+   #clock-cells = <1>;
+   };
+
sysctrl: sysctrl@1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
-- 
2.7.4

Re: [patch v2 1/2] mm, zone: track number of movable free pages

[Vlastimil Babka]

On 11/30/2016 01:16 AM, David Rientjes wrote:

An upcoming compaction change will need the number of movable free pages
per zone to determine if async compaction will become unnecessarily
expensive.

This patch introduces no functional change or increased memory footprint.
It simply tracks the number of free movable pages as a subset of the
total number of free pages.  This is exported to userspace as part of a
new /proc/vmstat field.

Signed-off-by: David Rientjes 
---
 v2: do not track free pages per migratetype since page allocator stress
 testing reveals this tracking can impact workloads and there is no
 substantial benefit when thp is disabled.  This occurs because
 entire pageblocks can be converted to new migratetypes and requires
 iteration of free_areas in the hotpaths for proper tracking.


Ah, right, forgot about the accuracy issue when focusing on the overhead 
issue. Unfortunately I'm afraid the NR_FREE_MOVABLE_PAGES in this patch 
will also drift uncontrollably over time. Stealing is one thing, and 
also buddy merging can silently move free pages between migratetypes. It 
already took some effort to make this accurate for MIGRATE_CMA and 
MIGRATE_ISOLATE, which has some overhead and works only thanks to 
additional constraints - CMA pageblocks don't ever get converted, and 
for ISOLATE we don't put them on pcplists, perform pcplists draining 
during isolation, and have extra code guarded by has_isolate_pageblock() 
in buddy merging. None of this would be directly viable for 
MIGRATE_MOVABLE I'm afraid.



 include/linux/mmzone.h | 1 +
 include/linux/vmstat.h | 2 ++
 mm/page_alloc.c| 8 +++-
 mm/vmstat.c| 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -138,6 +138,7 @@ enum zone_stat_item {
NUMA_OTHER, /* allocation from other node */
 #endif
NR_FREE_CMA_PAGES,
+   NR_FREE_MOVABLE_PAGES,
NR_VM_ZONE_STAT_ITEMS };

 enum node_stat_item {
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -347,6 +347,8 @@ static inline void __mod_zone_freepage_state(struct zone 
*zone, int nr_pages,
__mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages);
if (is_migrate_cma(migratetype))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES, nr_pages);
+   if (migratetype == MIGRATE_MOVABLE)
+   __mod_zone_page_state(zone, NR_FREE_MOVABLE_PAGES, nr_pages);
 }

 extern const char * const vmstat_text[];
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2197,6 +2197,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
spin_lock(>lock);
for (i = 0; i < count; ++i) {
struct page *page = __rmqueue(zone, order, migratetype);
+   int mt;
+
if (unlikely(page == NULL))
break;

@@ -2217,9 +2219,13 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
else
list_add_tail(>lru, list);
list = >lru;
-   if (is_migrate_cma(get_pcppage_migratetype(page)))
+   mt = get_pcppage_migratetype(page);
+   if (is_migrate_cma(mt))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
  -(1 << order));
+   if (mt == MIGRATE_MOVABLE)
+   __mod_zone_page_state(zone, NR_FREE_MOVABLE_PAGES,
+ -(1 << order));
}
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
spin_unlock(>lock);
diff --git a/mm/vmstat.c b/mm/vmstat.c
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -945,6 +945,7 @@ const char * const vmstat_text[] = {
"numa_other",
 #endif
"nr_free_cma",
+   "nr_free_movable",

/* Node-based counters */
"nr_inactive_anon",

[PATCH] arm64: dts: add zx296718's topcrm node

[Baoyou Xie]

Enable topcrm clock node for zx296718, which is used for
CPU's frequency change.

Furthermore, this patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.

So it can be used by cpufreq-dt driver.

Signed-off-by: Baoyou Xie 
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi 
b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..f9eb37d 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+   clocks = < A53_GATE>;
+   operating-points-v2 = <_opp>;
};
 
cpu1: cpu@1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+   operating-points-v2 = <_opp>;
};
 
cpu2: cpu@2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+   operating-points-v2 = <_opp>;
};
 
cpu3: cpu@3 {
@@ -102,6 +107,43 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+   operating-points-v2 = <_opp>;
+   };
+   };
+
+   cluster0_opp: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@10 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <857000>;
+   clock-latency-ns = <50>;
+   };
+   opp@11 {
+   opp-hz = /bits/ 64 <64800>;
+   opp-microvolt = <857000>;
+   clock-latency-ns = <50>;
+   };
+   opp@12 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <882000>;
+   clock-latency-ns = <50>;
+   };
+   opp@13 {
+   opp-hz = /bits/ 64 <10>;
+   opp-microvolt = <892000>;
+   clock-latency-ns = <50>;
+   };
+   opp@14 {
+   opp-hz = /bits/ 64 <118800>;
+   opp-microvolt = <1009000>;
+   clock-latency-ns = <50>;
+   };
+   opp@15 {
+   opp-hz = /bits/ 64 <131200>;
+   opp-microvolt = <1052000>;
+   clock-latency-ns = <50>;
};
};
 
@@ -279,6 +321,12 @@
dma-requests = <32>;
};
 
+   topcrm: clock-controller@01461000 {
+   compatible = "zte,zx296718-topcrm";
+   reg = <0x01461000 0x1000>;
+   #clock-cells = <1>;
+   };
+
sysctrl: sysctrl@1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
-- 
2.7.4

Another kernel OOPS still not fixed

[Gerhard Wiesinger]

Hello,

There is another major kernel OOPS which is still not fixed over a year

Bug 1279188 - bind-chroot causes kernel to crash on restart (mount with 
bind option):


https://bugzilla.redhat.com/show_bug.cgi?id=1279188

Can you please fix it.

Thnx.

Ciao,

Gerhard

Another kernel OOPS still not fixed

[Gerhard Wiesinger]

Hello,

There is another major kernel OOPS which is still not fixed over a year

Bug 1279188 - bind-chroot causes kernel to crash on restart (mount with 
bind option):


https://bugzilla.redhat.com/show_bug.cgi?id=1279188

Can you please fix it.

Thnx.

Ciao,

Gerhard

[PATCH 04/11] ACPICA: Events: Fix acpi_ev_initialize_region() return value

[Lv Zheng]

ACPICA commit 543342ab7a676f4eb0c9f100d349388a84dff0e8

This patch changes acpi_ev_initialize_region(), stop returning AE_NOT_EXIST
from it so that, not only in acpi_ds_load2_end_op(), but all places invoking
this function won't emit exceptions. The exception can be seen in
acpi_ds_initialize_objects() when certain table loading mode is chosen.

This patch also removes useless acpi_ns_locked from acpi_ev_initialize_region()
as this function will always be invoked with interpreter lock held now, and
the lock granularity has been tuned to lock around _REG execution, thus it
is now handled by acpi_ex_exit_interpreter(). Lv Zheng.

Link: https://github.com/acpica/acpica/commit/543342ab
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acevents.h |4 +--
 drivers/acpi/acpica/dsopcode.c |2 +-
 drivers/acpi/acpica/dswload2.c |   13 +
 drivers/acpi/acpica/evrgnini.c |   59 
 4 files changed, 27 insertions(+), 51 deletions(-)

diff --git a/drivers/acpi/acpica/acevents.h b/drivers/acpi/acpica/acevents.h
index 92fa47c..8a0049d 100644
--- a/drivers/acpi/acpica/acevents.h
+++ b/drivers/acpi/acpica/acevents.h
@@ -243,9 +243,7 @@ union acpi_operand_object 
*acpi_ev_find_region_handler(acpi_adr_space_type
 u32 function,
 void *handler_context, void **region_context);
 
-acpi_status
-acpi_ev_initialize_region(union acpi_operand_object *region_obj,
- u8 acpi_ns_locked);
+acpi_status acpi_ev_initialize_region(union acpi_operand_object *region_obj);
 
 /*
  * evsci - SCI (System Control Interrupt) handling/dispatch
diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index 4cc9d98..77fd7c8 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -84,7 +84,7 @@ acpi_status acpi_ds_initialize_region(acpi_handle obj_handle)
 
/* Namespace is NOT locked */
 
-   status = acpi_ev_initialize_region(obj_desc, FALSE);
+   status = acpi_ev_initialize_region(obj_desc);
return (status);
 }
 
diff --git a/drivers/acpi/acpica/dswload2.c b/drivers/acpi/acpica/dswload2.c
index e362182..651f35a 100644
--- a/drivers/acpi/acpica/dswload2.c
+++ b/drivers/acpi/acpica/dswload2.c
@@ -609,18 +609,7 @@ acpi_status acpi_ds_load2_end_op(struct acpi_walk_state 
*walk_state)
 
status =
acpi_ev_initialize_region
-   (acpi_ns_get_attached_object(node), FALSE);
-
-   if (ACPI_FAILURE(status)) {
-   /*
-*  If AE_NOT_EXIST is returned, it is not fatal
-*  because many regions get created before a 
handler
-*  is installed for said region.
-*/
-   if (AE_NOT_EXIST == status) {
-   status = AE_OK;
-   }
-   }
+   (acpi_ns_get_attached_object(node));
break;
 
case AML_NAME_OP:
diff --git a/drivers/acpi/acpica/evrgnini.c b/drivers/acpi/acpica/evrgnini.c
index 75ddd16..a909225 100644
--- a/drivers/acpi/acpica/evrgnini.c
+++ b/drivers/acpi/acpica/evrgnini.c
@@ -479,7 +479,6 @@ static u8 acpi_ev_is_pci_root_bridge(struct 
acpi_namespace_node *node)
  * FUNCTION:acpi_ev_initialize_region
  *
  * PARAMETERS:  region_obj  - Region we are initializing
- *  acpi_ns_locked  - Is namespace locked?
  *
  * RETURN:  Status
  *
@@ -497,19 +496,28 @@ static u8 acpi_ev_is_pci_root_bridge(struct 
acpi_namespace_node *node)
  * MUTEX:   Interpreter should be unlocked, because we may run the _REG
  *  method for this region.
  *
+ * NOTE:Possible incompliance:
+ *  There is a behavior conflict in automatic _REG execution:
+ *  1. When the interpreter is evaluating a method, we can only
+ * automatically run _REG for the following case:
+ *   operation_region (OPR1, 0x80, 0x110, 0x4)
+ *  2. When the interpreter is loading a table, we can also
+ * automatically run _REG for the following case:
+ *   operation_region (OPR1, 0x80, 0x110, 0x4)
+ *  Though this may not be compliant to the de-facto standard, the
+ *  logic is kept in order not to trigger regressions. And keeping
+ *  this logic should be taken care by the caller of this function.
+ *
  
**/
 
-acpi_status
-acpi_ev_initialize_region(union acpi_operand_object *region_obj,
- u8 acpi_ns_locked)
+acpi_status acpi_ev_initialize_region(union 

[PATCH 08/11] ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Lv Zheng]

ACPICA commit cac6790954d4d752a083e610b8a22febcd07

This patch back ports Linux acpi_get_table_with_size() and
early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.

The 2 APIs are used by Linux as table management APIs for long time, it
contains a hidden logic that during the early stage, the mapped tables
should be unmapped before the early stage ends.

During the early stage, tables are handled by the following sequence:
 acpi_get_table_with_size();
 parse the table
 early_acpi_os_unmap_memory();
During the late stage, tables are handled by the following sequence:
 acpi_get_table();
 parse the table
Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
late stage.

The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
remember the early mapped pointer in acpi_get_table() and Linux isn't able to
prevent ACPICA from using the wrong early mapped pointer during the late
stage as there is no API provided from ACPICA to be an inverse of
acpi_get_table() to forget the early mapped pointer.

But how ACPICA can work with the early/late stage requirement? Inside of
ACPICA, tables are ensured to be remained in "INSTALLED" state during the
early stage, and they are carefully not transitioned to "VALIDATED" state
until the late stage. So the same logic is in fact implemented inside of
ACPICA in a different way. The gap is only that the feature is not provided
to the OSPMs in an accessible external API style.

It then is possible to fix the gap by providing an inverse of
acpi_get_table() from ACPICA, so that the two Linux sequences can be
combined:
 acpi_get_table();
 parse the table
 acpi_put_table();
In order to work easier with the current Linux code, acpi_get_table() and
acpi_put_table() is implemented in a usage counting based style:
 1. When the usage count of the table is increased from 0 to 1, table is
mapped and .Pointer is set with the mapping address (VALIDATED);
 2. When the usage count of the table is decreased from 1 to 0, .Pointer
is unset and the mapping address is unmapped (INVALIDATED).
So that we can deploy the new APIs to Linux with minimal effort by just
invoking acpi_get_table() in acpi_get_table_with_size() and invoking
acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.

Link: https://github.com/acpica/acpica/commit/cac67909
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/actables.h|6 ++
 drivers/acpi/acpica/tbutils.c |   85 
 drivers/acpi/acpica/tbxface.c |  130 +++--
 drivers/acpi/osl.c|   31 -
 include/acpi/acpixf.h |   12 +++-
 include/acpi/actbl.h  |1 +
 include/acpi/platform/aclinuxex.h |1 -
 7 files changed, 212 insertions(+), 54 deletions(-)

diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 7dd527f..94be8a8 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -166,6 +166,12 @@
 
 acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
 
+acpi_status
+acpi_tb_get_table(struct acpi_table_desc *table_desc,
+ struct acpi_table_header **out_table);
+
+void acpi_tb_put_table(struct acpi_table_desc *table_desc);
+
 /*
  * tbxfload
  */
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index 51eb07c..86854e8 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -381,3 +381,88 @@ struct acpi_table_header *acpi_tb_copy_dsdt(u32 
table_index)
acpi_os_unmap_memory(table, length);
return_ACPI_STATUS(AE_OK);
 }
+
+/***
+ *
+ * FUNCTION:acpi_tb_get_table
+ *
+ * PARAMETERS:  table_desc  - Table descriptor
+ *  out_table   - Where the pointer to the table is 
returned
+ *
+ * RETURN:  Status and pointer to the requested table
+ *
+ * DESCRIPTION: Increase a reference to a table descriptor and return the
+ *  validated table pointer.
+ *  If the table descriptor is an entry of the root table list,
+ *  this API must be invoked with ACPI_MTX_TABLES acquired.
+ *
+ 
**/
+
+acpi_status
+acpi_tb_get_table(struct acpi_table_desc *table_desc,
+ struct acpi_table_header **out_table)
+{
+   acpi_status status;
+
+   ACPI_FUNCTION_TRACE(acpi_tb_get_table);
+
+   if (table_desc->validation_count == 0) {
+
+   /* Table need to be "VALIDATED" */
+
+   status = acpi_tb_validate_table(table_desc);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+   }
+
+   table_desc->validation_count++;
+   if (table_desc->validation_count == 0) {

[PATCH 06/11] ACPICA: Tables: Add acpi_tb_unload_table()

[Lv Zheng]

ACPICA commit 80e24663b212daac0c32767fdbd8a46892292f1f

This patch introduces acpi_tb_unload_table() to eliminate redundant code from
acpi_ex_unload_table() and acpi_unload_parent_table().

No functional change. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/80e24663
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/actables.h |2 ++
 drivers/acpi/acpica/exconfig.c |   35 +
 drivers/acpi/acpica/tbdata.c   |   48 
 drivers/acpi/acpica/tbxfload.c |   31 +-
 4 files changed, 52 insertions(+), 64 deletions(-)

diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 1850005..7dd527f 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -130,6 +130,8 @@
 acpi_tb_install_and_load_table(acpi_physical_address address,
   u8 flags, u8 override, u32 *table_index);
 
+acpi_status acpi_tb_unload_table(u32 table_index);
+
 void acpi_tb_terminate(void);
 
 acpi_status acpi_tb_delete_namespace_by_owner(u32 table_index);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 8b8d620..c32c782 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -499,7 +499,6 @@ acpi_status acpi_ex_unload_table(union acpi_operand_object 
*ddb_handle)
acpi_status status = AE_OK;
union acpi_operand_object *table_desc = ddb_handle;
u32 table_index;
-   struct acpi_table_header *table;
 
ACPI_FUNCTION_TRACE(ex_unload_table);
 
@@ -536,39 +535,7 @@ acpi_status acpi_ex_unload_table(union acpi_operand_object 
*ddb_handle)
 * strict order requirement against it.
 */
acpi_ex_exit_interpreter();
-
-   /* Ensure the table is still loaded */
-
-   if (!acpi_tb_is_table_loaded(table_index)) {
-   status = AE_NOT_EXIST;
-   goto lock_and_exit;
-   }
-
-   /* Invoke table handler if present */
-
-   if (acpi_gbl_table_handler) {
-   status = acpi_get_table_by_index(table_index, );
-   if (ACPI_SUCCESS(status)) {
-   (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_UNLOAD,
-table,
-
acpi_gbl_table_handler_context);
-   }
-   }
-
-   /* Delete the portion of the namespace owned by this table */
-
-   status = acpi_tb_delete_namespace_by_owner(table_index);
-   if (ACPI_FAILURE(status)) {
-   goto lock_and_exit;
-   }
-
-   (void)acpi_tb_release_owner_id(table_index);
-   acpi_tb_set_table_loaded_flag(table_index, FALSE);
-
-lock_and_exit:
-
-   /* Re-acquire the interpreter lock */
-
+   status = acpi_tb_unload_table(table_index);
acpi_ex_enter_interpreter();
 
/*
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index 4cbfa30..82b0b57 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -871,3 +871,51 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
return_ACPI_STATUS(status);
 }
+
+/***
+ *
+ * FUNCTION:acpi_tb_unload_table
+ *
+ * PARAMETERS:  table_index - Table index
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Unload an ACPI table
+ *
+ 
**/
+
+acpi_status acpi_tb_unload_table(u32 table_index)
+{
+   acpi_status status = AE_OK;
+   struct acpi_table_header *table;
+
+   ACPI_FUNCTION_TRACE(tb_unload_table);
+
+   /* Ensure the table is still loaded */
+
+   if (!acpi_tb_is_table_loaded(table_index)) {
+   return_ACPI_STATUS(AE_NOT_EXIST);
+   }
+
+   /* Invoke table handler if present */
+
+   if (acpi_gbl_table_handler) {
+   status = acpi_get_table_by_index(table_index, );
+   if (ACPI_SUCCESS(status)) {
+   (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_UNLOAD,
+table,
+
acpi_gbl_table_handler_context);
+   }
+   }
+
+   /* Delete the portion of the namespace owned by this table */
+
+   status = acpi_tb_delete_namespace_by_owner(table_index);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+
+   (void)acpi_tb_release_owner_id(table_index);
+   acpi_tb_set_table_loaded_flag(table_index, FALSE);
+   return_ACPI_STATUS(status);
+}
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 77de33b..82019c0 100644
--- 

[PATCH 08/11] ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

[Lv Zheng]

ACPICA commit cac6790954d4d752a083e610b8a22febcd07

This patch back ports Linux acpi_get_table_with_size() and
early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.

The 2 APIs are used by Linux as table management APIs for long time, it
contains a hidden logic that during the early stage, the mapped tables
should be unmapped before the early stage ends.

During the early stage, tables are handled by the following sequence:
 acpi_get_table_with_size();
 parse the table
 early_acpi_os_unmap_memory();
During the late stage, tables are handled by the following sequence:
 acpi_get_table();
 parse the table
Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
late stage.

The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
remember the early mapped pointer in acpi_get_table() and Linux isn't able to
prevent ACPICA from using the wrong early mapped pointer during the late
stage as there is no API provided from ACPICA to be an inverse of
acpi_get_table() to forget the early mapped pointer.

But how ACPICA can work with the early/late stage requirement? Inside of
ACPICA, tables are ensured to be remained in "INSTALLED" state during the
early stage, and they are carefully not transitioned to "VALIDATED" state
until the late stage. So the same logic is in fact implemented inside of
ACPICA in a different way. The gap is only that the feature is not provided
to the OSPMs in an accessible external API style.

It then is possible to fix the gap by providing an inverse of
acpi_get_table() from ACPICA, so that the two Linux sequences can be
combined:
 acpi_get_table();
 parse the table
 acpi_put_table();
In order to work easier with the current Linux code, acpi_get_table() and
acpi_put_table() is implemented in a usage counting based style:
 1. When the usage count of the table is increased from 0 to 1, table is
mapped and .Pointer is set with the mapping address (VALIDATED);
 2. When the usage count of the table is decreased from 1 to 0, .Pointer
is unset and the mapping address is unmapped (INVALIDATED).
So that we can deploy the new APIs to Linux with minimal effort by just
invoking acpi_get_table() in acpi_get_table_with_size() and invoking
acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.

Link: https://github.com/acpica/acpica/commit/cac67909
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/actables.h|6 ++
 drivers/acpi/acpica/tbutils.c |   85 
 drivers/acpi/acpica/tbxface.c |  130 +++--
 drivers/acpi/osl.c|   31 -
 include/acpi/acpixf.h |   12 +++-
 include/acpi/actbl.h  |1 +
 include/acpi/platform/aclinuxex.h |1 -
 7 files changed, 212 insertions(+), 54 deletions(-)

diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 7dd527f..94be8a8 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -166,6 +166,12 @@
 
 acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
 
+acpi_status
+acpi_tb_get_table(struct acpi_table_desc *table_desc,
+ struct acpi_table_header **out_table);
+
+void acpi_tb_put_table(struct acpi_table_desc *table_desc);
+
 /*
  * tbxfload
  */
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index 51eb07c..86854e8 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -381,3 +381,88 @@ struct acpi_table_header *acpi_tb_copy_dsdt(u32 
table_index)
acpi_os_unmap_memory(table, length);
return_ACPI_STATUS(AE_OK);
 }
+
+/***
+ *
+ * FUNCTION:acpi_tb_get_table
+ *
+ * PARAMETERS:  table_desc  - Table descriptor
+ *  out_table   - Where the pointer to the table is 
returned
+ *
+ * RETURN:  Status and pointer to the requested table
+ *
+ * DESCRIPTION: Increase a reference to a table descriptor and return the
+ *  validated table pointer.
+ *  If the table descriptor is an entry of the root table list,
+ *  this API must be invoked with ACPI_MTX_TABLES acquired.
+ *
+ 
**/
+
+acpi_status
+acpi_tb_get_table(struct acpi_table_desc *table_desc,
+ struct acpi_table_header **out_table)
+{
+   acpi_status status;
+
+   ACPI_FUNCTION_TRACE(acpi_tb_get_table);
+
+   if (table_desc->validation_count == 0) {
+
+   /* Table need to be "VALIDATED" */
+
+   status = acpi_tb_validate_table(table_desc);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+   }
+
+   table_desc->validation_count++;
+   if (table_desc->validation_count == 0) {
+   ACPI_ERROR((AE_INFO,
+  

[PATCH 06/11] ACPICA: Tables: Add acpi_tb_unload_table()

[Lv Zheng]

ACPICA commit 80e24663b212daac0c32767fdbd8a46892292f1f

This patch introduces acpi_tb_unload_table() to eliminate redundant code from
acpi_ex_unload_table() and acpi_unload_parent_table().

No functional change. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/80e24663
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/actables.h |2 ++
 drivers/acpi/acpica/exconfig.c |   35 +
 drivers/acpi/acpica/tbdata.c   |   48 
 drivers/acpi/acpica/tbxfload.c |   31 +-
 4 files changed, 52 insertions(+), 64 deletions(-)

diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 1850005..7dd527f 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -130,6 +130,8 @@
 acpi_tb_install_and_load_table(acpi_physical_address address,
   u8 flags, u8 override, u32 *table_index);
 
+acpi_status acpi_tb_unload_table(u32 table_index);
+
 void acpi_tb_terminate(void);
 
 acpi_status acpi_tb_delete_namespace_by_owner(u32 table_index);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 8b8d620..c32c782 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -499,7 +499,6 @@ acpi_status acpi_ex_unload_table(union acpi_operand_object 
*ddb_handle)
acpi_status status = AE_OK;
union acpi_operand_object *table_desc = ddb_handle;
u32 table_index;
-   struct acpi_table_header *table;
 
ACPI_FUNCTION_TRACE(ex_unload_table);
 
@@ -536,39 +535,7 @@ acpi_status acpi_ex_unload_table(union acpi_operand_object 
*ddb_handle)
 * strict order requirement against it.
 */
acpi_ex_exit_interpreter();
-
-   /* Ensure the table is still loaded */
-
-   if (!acpi_tb_is_table_loaded(table_index)) {
-   status = AE_NOT_EXIST;
-   goto lock_and_exit;
-   }
-
-   /* Invoke table handler if present */
-
-   if (acpi_gbl_table_handler) {
-   status = acpi_get_table_by_index(table_index, );
-   if (ACPI_SUCCESS(status)) {
-   (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_UNLOAD,
-table,
-
acpi_gbl_table_handler_context);
-   }
-   }
-
-   /* Delete the portion of the namespace owned by this table */
-
-   status = acpi_tb_delete_namespace_by_owner(table_index);
-   if (ACPI_FAILURE(status)) {
-   goto lock_and_exit;
-   }
-
-   (void)acpi_tb_release_owner_id(table_index);
-   acpi_tb_set_table_loaded_flag(table_index, FALSE);
-
-lock_and_exit:
-
-   /* Re-acquire the interpreter lock */
-
+   status = acpi_tb_unload_table(table_index);
acpi_ex_enter_interpreter();
 
/*
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index 4cbfa30..82b0b57 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -871,3 +871,51 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
return_ACPI_STATUS(status);
 }
+
+/***
+ *
+ * FUNCTION:acpi_tb_unload_table
+ *
+ * PARAMETERS:  table_index - Table index
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Unload an ACPI table
+ *
+ 
**/
+
+acpi_status acpi_tb_unload_table(u32 table_index)
+{
+   acpi_status status = AE_OK;
+   struct acpi_table_header *table;
+
+   ACPI_FUNCTION_TRACE(tb_unload_table);
+
+   /* Ensure the table is still loaded */
+
+   if (!acpi_tb_is_table_loaded(table_index)) {
+   return_ACPI_STATUS(AE_NOT_EXIST);
+   }
+
+   /* Invoke table handler if present */
+
+   if (acpi_gbl_table_handler) {
+   status = acpi_get_table_by_index(table_index, );
+   if (ACPI_SUCCESS(status)) {
+   (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_UNLOAD,
+table,
+
acpi_gbl_table_handler_context);
+   }
+   }
+
+   /* Delete the portion of the namespace owned by this table */
+
+   status = acpi_tb_delete_namespace_by_owner(table_index);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+
+   (void)acpi_tb_release_owner_id(table_index);
+   acpi_tb_set_table_loaded_flag(table_index, FALSE);
+   return_ACPI_STATUS(status);
+}
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 77de33b..82019c0 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ 

[PATCH 04/11] ACPICA: Events: Fix acpi_ev_initialize_region() return value

[Lv Zheng]

ACPICA commit 543342ab7a676f4eb0c9f100d349388a84dff0e8

This patch changes acpi_ev_initialize_region(), stop returning AE_NOT_EXIST
from it so that, not only in acpi_ds_load2_end_op(), but all places invoking
this function won't emit exceptions. The exception can be seen in
acpi_ds_initialize_objects() when certain table loading mode is chosen.

This patch also removes useless acpi_ns_locked from acpi_ev_initialize_region()
as this function will always be invoked with interpreter lock held now, and
the lock granularity has been tuned to lock around _REG execution, thus it
is now handled by acpi_ex_exit_interpreter(). Lv Zheng.

Link: https://github.com/acpica/acpica/commit/543342ab
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acevents.h |4 +--
 drivers/acpi/acpica/dsopcode.c |2 +-
 drivers/acpi/acpica/dswload2.c |   13 +
 drivers/acpi/acpica/evrgnini.c |   59 
 4 files changed, 27 insertions(+), 51 deletions(-)

diff --git a/drivers/acpi/acpica/acevents.h b/drivers/acpi/acpica/acevents.h
index 92fa47c..8a0049d 100644
--- a/drivers/acpi/acpica/acevents.h
+++ b/drivers/acpi/acpica/acevents.h
@@ -243,9 +243,7 @@ union acpi_operand_object 
*acpi_ev_find_region_handler(acpi_adr_space_type
 u32 function,
 void *handler_context, void **region_context);
 
-acpi_status
-acpi_ev_initialize_region(union acpi_operand_object *region_obj,
- u8 acpi_ns_locked);
+acpi_status acpi_ev_initialize_region(union acpi_operand_object *region_obj);
 
 /*
  * evsci - SCI (System Control Interrupt) handling/dispatch
diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index 4cc9d98..77fd7c8 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -84,7 +84,7 @@ acpi_status acpi_ds_initialize_region(acpi_handle obj_handle)
 
/* Namespace is NOT locked */
 
-   status = acpi_ev_initialize_region(obj_desc, FALSE);
+   status = acpi_ev_initialize_region(obj_desc);
return (status);
 }
 
diff --git a/drivers/acpi/acpica/dswload2.c b/drivers/acpi/acpica/dswload2.c
index e362182..651f35a 100644
--- a/drivers/acpi/acpica/dswload2.c
+++ b/drivers/acpi/acpica/dswload2.c
@@ -609,18 +609,7 @@ acpi_status acpi_ds_load2_end_op(struct acpi_walk_state 
*walk_state)
 
status =
acpi_ev_initialize_region
-   (acpi_ns_get_attached_object(node), FALSE);
-
-   if (ACPI_FAILURE(status)) {
-   /*
-*  If AE_NOT_EXIST is returned, it is not fatal
-*  because many regions get created before a 
handler
-*  is installed for said region.
-*/
-   if (AE_NOT_EXIST == status) {
-   status = AE_OK;
-   }
-   }
+   (acpi_ns_get_attached_object(node));
break;
 
case AML_NAME_OP:
diff --git a/drivers/acpi/acpica/evrgnini.c b/drivers/acpi/acpica/evrgnini.c
index 75ddd16..a909225 100644
--- a/drivers/acpi/acpica/evrgnini.c
+++ b/drivers/acpi/acpica/evrgnini.c
@@ -479,7 +479,6 @@ static u8 acpi_ev_is_pci_root_bridge(struct 
acpi_namespace_node *node)
  * FUNCTION:acpi_ev_initialize_region
  *
  * PARAMETERS:  region_obj  - Region we are initializing
- *  acpi_ns_locked  - Is namespace locked?
  *
  * RETURN:  Status
  *
@@ -497,19 +496,28 @@ static u8 acpi_ev_is_pci_root_bridge(struct 
acpi_namespace_node *node)
  * MUTEX:   Interpreter should be unlocked, because we may run the _REG
  *  method for this region.
  *
+ * NOTE:Possible incompliance:
+ *  There is a behavior conflict in automatic _REG execution:
+ *  1. When the interpreter is evaluating a method, we can only
+ * automatically run _REG for the following case:
+ *   operation_region (OPR1, 0x80, 0x110, 0x4)
+ *  2. When the interpreter is loading a table, we can also
+ * automatically run _REG for the following case:
+ *   operation_region (OPR1, 0x80, 0x110, 0x4)
+ *  Though this may not be compliant to the de-facto standard, the
+ *  logic is kept in order not to trigger regressions. And keeping
+ *  this logic should be taken care by the caller of this function.
+ *
  
**/
 
-acpi_status
-acpi_ev_initialize_region(union acpi_operand_object *region_obj,
- u8 acpi_ns_locked)
+acpi_status acpi_ev_initialize_region(union acpi_operand_object *region_obj)
 {

[PATCH 11/11] ACPICA: Update version to 20161117

[Lv Zheng]

From: Bob Moore 

ACPICA commit 0d5a056877c2e37e0bfce8d262cec339dc8d55fd

Version 20161117.

Link: https://github.com/acpica/acpica/commit/0d5a0568
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 33828dd..0d20c53 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -46,7 +46,7 @@
 
 /* Current ACPICA subsystem version in MMDD format */
 
-#define ACPI_CA_VERSION 0x20160930
+#define ACPI_CA_VERSION 0x20161117
 
 #include 
 #include 
-- 
1.7.10

[PATCH 05/11] ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()

[Lv Zheng]

ACPICA commit 7fdac0289faa1c28b91413c8e394e87372aa69e6

acpi_tb_install_and_load_table() can invoke acpi_tb_load_table() to eliminate
redundant code.

No functional change. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/7fdac028
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/actables.h |3 +--
 drivers/acpi/acpica/exconfig.c |7 +++
 drivers/acpi/acpica/tbdata.c   |   45 +---
 drivers/acpi/acpica/tbxfload.c |7 +++
 4 files changed, 12 insertions(+), 50 deletions(-)

diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index e85953b..1850005 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -127,8 +127,7 @@
 acpi_tb_load_table(u32 table_index, struct acpi_namespace_node *parent_node);
 
 acpi_status
-acpi_tb_install_and_load_table(struct acpi_table_header *table,
-  acpi_physical_address address,
+acpi_tb_install_and_load_table(acpi_physical_address address,
   u8 flags, u8 override, u32 *table_index);
 
 void acpi_tb_terminate(void);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 718428b..8b8d620 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -437,10 +437,9 @@
 
ACPI_INFO(("Dynamic OEM Table Load:"));
acpi_ex_exit_interpreter();
-   status =
-   acpi_tb_install_and_load_table(table, ACPI_PTR_TO_PHYSADDR(table),
-  ACPI_TABLE_ORIGIN_INTERNAL_VIRTUAL,
-  TRUE, _index);
+   status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
+   
ACPI_TABLE_ORIGIN_INTERNAL_VIRTUAL,
+   TRUE, _index);
acpi_ex_enter_interpreter();
if (ACPI_FAILURE(status)) {
 
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index d9ca8c2..4cbfa30 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -832,9 +832,9 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
  *
  * FUNCTION:acpi_tb_install_and_load_table
  *
- * PARAMETERS:  table   - Pointer to the table
- *  address - Physical address of the table
+ * PARAMETERS:  address - Physical address of the table
  *  flags   - Allocation flags of the table
+ *  override- Whether override should be performed
  *  table_index - Where table index is returned
  *
  * RETURN:  Status
@@ -844,15 +844,13 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
  
**/
 
 acpi_status
-acpi_tb_install_and_load_table(struct acpi_table_header *table,
-  acpi_physical_address address,
+acpi_tb_install_and_load_table(acpi_physical_address address,
   u8 flags, u8 override, u32 *table_index)
 {
acpi_status status;
u32 i;
-   acpi_owner_id owner_id;
 
-   ACPI_FUNCTION_TRACE(acpi_load_table);
+   ACPI_FUNCTION_TRACE(tb_install_and_load_table);
 
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
 
@@ -864,41 +862,8 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
goto unlock_and_exit;
}
 
-   /*
-* Note: Now table is "INSTALLED", it must be validated before
-* using.
-*/
-   status = acpi_tb_validate_table(_gbl_root_table_list.tables[i]);
-   if (ACPI_FAILURE(status)) {
-   goto unlock_and_exit;
-   }
-
(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
-   status = acpi_ns_load_table(i, acpi_gbl_root_node);
-
-   /* Execute any module-level code that was found in the table */
-
-   if (!acpi_gbl_parse_table_as_term_list
-   && acpi_gbl_group_module_level_code) {
-   acpi_ns_exec_module_code_list();
-   }
-
-   /*
-* Update GPEs for any new _Lxx/_Exx methods. Ignore errors. The host is
-* responsible for discovering any new wake GPEs by running _PRW methods
-* that may have been loaded by this table.
-*/
-   status = acpi_tb_get_owner_id(i, _id);
-   if (ACPI_SUCCESS(status)) {
-   acpi_ev_update_gpes(owner_id);
-   }
-
-   /* Invoke table handler if present */
-
-   if (acpi_gbl_table_handler) {
-   (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_LOAD, table,
-acpi_gbl_table_handler_context);
-   }
+   status = acpi_tb_load_table(i, acpi_gbl_root_node);
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
 
 

[PATCH 01/11] ACPICA: Namespace: Add acpi_ns_handle_to_name()

[Lv Zheng]

ACPICA commit f9fe27a68a90c9d32dd3156241a5e788fb6956ea

This patch adds acpi_ns_handle_to_name() so that in the acpi_get_name():
1. Logics can be made simpler,
2. Lock held for acpi_ns_handle_to_name() can also be applied to
   acpi_ns_handle_to_pathname().
The lock might be useless (see Link 1 below), but kept as acpi_get_name() is
an external API. Except the lock correction, this patch is a functional
no-op. BZ 1182, Lv Zheng.

Link: https://github.com/acpica/acpica/commit/f9fe27a6
Link: https://bugs.acpica.org/show_bug.cgi?id=1182 [# 1]
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acnamesp.h |3 +++
 drivers/acpi/acpica/nsnames.c  |   45 
 drivers/acpi/acpica/nsxfname.c |   43 ++
 3 files changed, 59 insertions(+), 32 deletions(-)

diff --git a/drivers/acpi/acpica/acnamesp.h b/drivers/acpi/acpica/acnamesp.h
index bb7fca1..7affdcd 100644
--- a/drivers/acpi/acpica/acnamesp.h
+++ b/drivers/acpi/acpica/acnamesp.h
@@ -292,6 +292,9 @@ char *acpi_ns_get_normalized_pathname(struct 
acpi_namespace_node *node,
 char *acpi_ns_name_of_current_scope(struct acpi_walk_state *walk_state);
 
 acpi_status
+acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer);
+
+acpi_status
 acpi_ns_handle_to_pathname(acpi_handle target_handle,
   struct acpi_buffer *buffer, u8 no_trailing);
 
diff --git a/drivers/acpi/acpica/nsnames.c b/drivers/acpi/acpica/nsnames.c
index f03dd41..94d5d33 100644
--- a/drivers/acpi/acpica/nsnames.c
+++ b/drivers/acpi/acpica/nsnames.c
@@ -97,6 +97,51 @@ acpi_size acpi_ns_get_pathname_length(struct 
acpi_namespace_node *node)
 
 
/***
  *
+ * FUNCTION:acpi_ns_handle_to_name
+ *
+ * PARAMETERS:  target_handle   - Handle of named object whose name is
+ *to be found
+ *  buffer  - Where the name is returned
+ *
+ * RETURN:  Status, Buffer is filled with name if status is AE_OK
+ *
+ * DESCRIPTION: Build and return a full namespace name
+ *
+ 
**/
+
+acpi_status
+acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer)
+{
+   acpi_status status;
+   struct acpi_namespace_node *node;
+   const char *node_name;
+
+   ACPI_FUNCTION_TRACE_PTR(ns_handle_to_name, target_handle);
+
+   node = acpi_ns_validate_handle(target_handle);
+   if (!node) {
+   return_ACPI_STATUS(AE_BAD_PARAMETER);
+   }
+
+   /* Validate/Allocate/Clear caller buffer */
+
+   status = acpi_ut_initialize_buffer(buffer, ACPI_PATH_SEGMENT_LENGTH);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+
+   /* Just copy the ACPI name from the Node and zero terminate it */
+
+   node_name = acpi_ut_get_node_name(node);
+   ACPI_MOVE_NAME(buffer->pointer, node_name);
+   ((char *)buffer->pointer)[ACPI_NAME_SIZE] = 0;
+
+   ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "%4.4s\n", (char *)buffer->pointer));
+   return_ACPI_STATUS(AE_OK);
+}
+
+/***
+ *
  * FUNCTION:acpi_ns_handle_to_pathname
  *
  * PARAMETERS:  target_handle   - Handle of named object whose name is
diff --git a/drivers/acpi/acpica/nsxfname.c b/drivers/acpi/acpica/nsxfname.c
index 76a1bd4..e525cbe 100644
--- a/drivers/acpi/acpica/nsxfname.c
+++ b/drivers/acpi/acpica/nsxfname.c
@@ -158,8 +158,6 @@ static char *acpi_ns_copy_device_id(struct 
acpi_pnp_device_id *dest,
 acpi_get_name(acpi_handle handle, u32 name_type, struct acpi_buffer *buffer)
 {
acpi_status status;
-   struct acpi_namespace_node *node;
-   const char *node_name;
 
/* Parameter validation */
 
@@ -172,18 +170,6 @@ static char *acpi_ns_copy_device_id(struct 
acpi_pnp_device_id *dest,
return (status);
}
 
-   if (name_type == ACPI_FULL_PATHNAME ||
-   name_type == ACPI_FULL_PATHNAME_NO_TRAILING) {
-
-   /* Get the full pathname (From the namespace root) */
-
-   status = acpi_ns_handle_to_pathname(handle, buffer,
-   name_type ==
-   ACPI_FULL_PATHNAME ? FALSE :
-   TRUE);
-   return (status);
-   }
-
/*
 * Wants the single segment ACPI name.
 * Validate handle and convert to a namespace Node
@@ -193,27 +179,20 @@ static char *acpi_ns_copy_device_id(struct 
acpi_pnp_device_id *dest,
return (status);
}
 
-   node = acpi_ns_validate_handle(handle);
-   if (!node) {
-   status = 

[PATCH 11/11] ACPICA: Update version to 20161117

[Lv Zheng]

From: Bob Moore 

ACPICA commit 0d5a056877c2e37e0bfce8d262cec339dc8d55fd

Version 20161117.

Link: https://github.com/acpica/acpica/commit/0d5a0568
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 33828dd..0d20c53 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -46,7 +46,7 @@
 
 /* Current ACPICA subsystem version in MMDD format */
 
-#define ACPI_CA_VERSION 0x20160930
+#define ACPI_CA_VERSION 0x20161117
 
 #include 
 #include 
-- 
1.7.10

[PATCH 05/11] ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()

[Lv Zheng]

ACPICA commit 7fdac0289faa1c28b91413c8e394e87372aa69e6

acpi_tb_install_and_load_table() can invoke acpi_tb_load_table() to eliminate
redundant code.

No functional change. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/7fdac028
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/actables.h |3 +--
 drivers/acpi/acpica/exconfig.c |7 +++
 drivers/acpi/acpica/tbdata.c   |   45 +---
 drivers/acpi/acpica/tbxfload.c |7 +++
 4 files changed, 12 insertions(+), 50 deletions(-)

diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index e85953b..1850005 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -127,8 +127,7 @@
 acpi_tb_load_table(u32 table_index, struct acpi_namespace_node *parent_node);
 
 acpi_status
-acpi_tb_install_and_load_table(struct acpi_table_header *table,
-  acpi_physical_address address,
+acpi_tb_install_and_load_table(acpi_physical_address address,
   u8 flags, u8 override, u32 *table_index);
 
 void acpi_tb_terminate(void);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 718428b..8b8d620 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -437,10 +437,9 @@
 
ACPI_INFO(("Dynamic OEM Table Load:"));
acpi_ex_exit_interpreter();
-   status =
-   acpi_tb_install_and_load_table(table, ACPI_PTR_TO_PHYSADDR(table),
-  ACPI_TABLE_ORIGIN_INTERNAL_VIRTUAL,
-  TRUE, _index);
+   status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
+   
ACPI_TABLE_ORIGIN_INTERNAL_VIRTUAL,
+   TRUE, _index);
acpi_ex_enter_interpreter();
if (ACPI_FAILURE(status)) {
 
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index d9ca8c2..4cbfa30 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -832,9 +832,9 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
  *
  * FUNCTION:acpi_tb_install_and_load_table
  *
- * PARAMETERS:  table   - Pointer to the table
- *  address - Physical address of the table
+ * PARAMETERS:  address - Physical address of the table
  *  flags   - Allocation flags of the table
+ *  override- Whether override should be performed
  *  table_index - Where table index is returned
  *
  * RETURN:  Status
@@ -844,15 +844,13 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
  
**/
 
 acpi_status
-acpi_tb_install_and_load_table(struct acpi_table_header *table,
-  acpi_physical_address address,
+acpi_tb_install_and_load_table(acpi_physical_address address,
   u8 flags, u8 override, u32 *table_index)
 {
acpi_status status;
u32 i;
-   acpi_owner_id owner_id;
 
-   ACPI_FUNCTION_TRACE(acpi_load_table);
+   ACPI_FUNCTION_TRACE(tb_install_and_load_table);
 
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
 
@@ -864,41 +862,8 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded)
goto unlock_and_exit;
}
 
-   /*
-* Note: Now table is "INSTALLED", it must be validated before
-* using.
-*/
-   status = acpi_tb_validate_table(_gbl_root_table_list.tables[i]);
-   if (ACPI_FAILURE(status)) {
-   goto unlock_and_exit;
-   }
-
(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
-   status = acpi_ns_load_table(i, acpi_gbl_root_node);
-
-   /* Execute any module-level code that was found in the table */
-
-   if (!acpi_gbl_parse_table_as_term_list
-   && acpi_gbl_group_module_level_code) {
-   acpi_ns_exec_module_code_list();
-   }
-
-   /*
-* Update GPEs for any new _Lxx/_Exx methods. Ignore errors. The host is
-* responsible for discovering any new wake GPEs by running _PRW methods
-* that may have been loaded by this table.
-*/
-   status = acpi_tb_get_owner_id(i, _id);
-   if (ACPI_SUCCESS(status)) {
-   acpi_ev_update_gpes(owner_id);
-   }
-
-   /* Invoke table handler if present */
-
-   if (acpi_gbl_table_handler) {
-   (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_LOAD, table,
-acpi_gbl_table_handler_context);
-   }
+   status = acpi_tb_load_table(i, acpi_gbl_root_node);
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
 
 unlock_and_exit:
diff --git 

[PATCH 01/11] ACPICA: Namespace: Add acpi_ns_handle_to_name()

[Lv Zheng]

ACPICA commit f9fe27a68a90c9d32dd3156241a5e788fb6956ea

This patch adds acpi_ns_handle_to_name() so that in the acpi_get_name():
1. Logics can be made simpler,
2. Lock held for acpi_ns_handle_to_name() can also be applied to
   acpi_ns_handle_to_pathname().
The lock might be useless (see Link 1 below), but kept as acpi_get_name() is
an external API. Except the lock correction, this patch is a functional
no-op. BZ 1182, Lv Zheng.

Link: https://github.com/acpica/acpica/commit/f9fe27a6
Link: https://bugs.acpica.org/show_bug.cgi?id=1182 [# 1]
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/acnamesp.h |3 +++
 drivers/acpi/acpica/nsnames.c  |   45 
 drivers/acpi/acpica/nsxfname.c |   43 ++
 3 files changed, 59 insertions(+), 32 deletions(-)

diff --git a/drivers/acpi/acpica/acnamesp.h b/drivers/acpi/acpica/acnamesp.h
index bb7fca1..7affdcd 100644
--- a/drivers/acpi/acpica/acnamesp.h
+++ b/drivers/acpi/acpica/acnamesp.h
@@ -292,6 +292,9 @@ char *acpi_ns_get_normalized_pathname(struct 
acpi_namespace_node *node,
 char *acpi_ns_name_of_current_scope(struct acpi_walk_state *walk_state);
 
 acpi_status
+acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer);
+
+acpi_status
 acpi_ns_handle_to_pathname(acpi_handle target_handle,
   struct acpi_buffer *buffer, u8 no_trailing);
 
diff --git a/drivers/acpi/acpica/nsnames.c b/drivers/acpi/acpica/nsnames.c
index f03dd41..94d5d33 100644
--- a/drivers/acpi/acpica/nsnames.c
+++ b/drivers/acpi/acpica/nsnames.c
@@ -97,6 +97,51 @@ acpi_size acpi_ns_get_pathname_length(struct 
acpi_namespace_node *node)
 
 
/***
  *
+ * FUNCTION:acpi_ns_handle_to_name
+ *
+ * PARAMETERS:  target_handle   - Handle of named object whose name is
+ *to be found
+ *  buffer  - Where the name is returned
+ *
+ * RETURN:  Status, Buffer is filled with name if status is AE_OK
+ *
+ * DESCRIPTION: Build and return a full namespace name
+ *
+ 
**/
+
+acpi_status
+acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer)
+{
+   acpi_status status;
+   struct acpi_namespace_node *node;
+   const char *node_name;
+
+   ACPI_FUNCTION_TRACE_PTR(ns_handle_to_name, target_handle);
+
+   node = acpi_ns_validate_handle(target_handle);
+   if (!node) {
+   return_ACPI_STATUS(AE_BAD_PARAMETER);
+   }
+
+   /* Validate/Allocate/Clear caller buffer */
+
+   status = acpi_ut_initialize_buffer(buffer, ACPI_PATH_SEGMENT_LENGTH);
+   if (ACPI_FAILURE(status)) {
+   return_ACPI_STATUS(status);
+   }
+
+   /* Just copy the ACPI name from the Node and zero terminate it */
+
+   node_name = acpi_ut_get_node_name(node);
+   ACPI_MOVE_NAME(buffer->pointer, node_name);
+   ((char *)buffer->pointer)[ACPI_NAME_SIZE] = 0;
+
+   ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "%4.4s\n", (char *)buffer->pointer));
+   return_ACPI_STATUS(AE_OK);
+}
+
+/***
+ *
  * FUNCTION:acpi_ns_handle_to_pathname
  *
  * PARAMETERS:  target_handle   - Handle of named object whose name is
diff --git a/drivers/acpi/acpica/nsxfname.c b/drivers/acpi/acpica/nsxfname.c
index 76a1bd4..e525cbe 100644
--- a/drivers/acpi/acpica/nsxfname.c
+++ b/drivers/acpi/acpica/nsxfname.c
@@ -158,8 +158,6 @@ static char *acpi_ns_copy_device_id(struct 
acpi_pnp_device_id *dest,
 acpi_get_name(acpi_handle handle, u32 name_type, struct acpi_buffer *buffer)
 {
acpi_status status;
-   struct acpi_namespace_node *node;
-   const char *node_name;
 
/* Parameter validation */
 
@@ -172,18 +170,6 @@ static char *acpi_ns_copy_device_id(struct 
acpi_pnp_device_id *dest,
return (status);
}
 
-   if (name_type == ACPI_FULL_PATHNAME ||
-   name_type == ACPI_FULL_PATHNAME_NO_TRAILING) {
-
-   /* Get the full pathname (From the namespace root) */
-
-   status = acpi_ns_handle_to_pathname(handle, buffer,
-   name_type ==
-   ACPI_FULL_PATHNAME ? FALSE :
-   TRUE);
-   return (status);
-   }
-
/*
 * Wants the single segment ACPI name.
 * Validate handle and convert to a namespace Node
@@ -193,27 +179,20 @@ static char *acpi_ns_copy_device_id(struct 
acpi_pnp_device_id *dest,
return (status);
}
 
-   node = acpi_ns_validate_handle(handle);
-   if (!node) {
-   status = AE_BAD_PARAMETER;
-   goto 

Still OOM problems with 4.9er kernels

[Gerhard Wiesinger]

Hello,

I'm having out of memory situations with my "low memory" VMs in KVM 
under Fedora (Kernel 4.7, 4.8 and also before). They started to get more 
and more sensitive to OOM. I recently found the following info:


https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/
https://www.spinics.net/lists/linux-mm/msg113661.html

Therefore I tried the latest Fedora kernels: 4.9.0-0.rc6.git2.1.fc26.x86_64

But OOM situation is still very easy to reproduce:

1.) VM with 128-384MB under Fedora 25

2.) Having some processes run without any load (e.g. Apache)

3.) run an update with: dnf clean all; dnf update

4.) dnf python process get's killed


Please make the VM system working again in Kernel 4.9 and to use swap 
again correctly.


Thnx.

Ciao,

Gerhard

Still OOM problems with 4.9er kernels

[Gerhard Wiesinger]

Hello,

I'm having out of memory situations with my "low memory" VMs in KVM 
under Fedora (Kernel 4.7, 4.8 and also before). They started to get more 
and more sensitive to OOM. I recently found the following info:


https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/
https://www.spinics.net/lists/linux-mm/msg113661.html

Therefore I tried the latest Fedora kernels: 4.9.0-0.rc6.git2.1.fc26.x86_64

But OOM situation is still very easy to reproduce:

1.) VM with 128-384MB under Fedora 25

2.) Having some processes run without any load (e.g. Apache)

3.) run an update with: dnf clean all; dnf update

4.) dnf python process get's killed


Please make the VM system working again in Kernel 4.9 and to use swap 
again correctly.


Thnx.

Ciao,

Gerhard

Re: Still OOM problems with 4.9er kernels

[Gerhard Wiesinger]

Hello,

See also:
Bug 1314697 - Kernel 4.4.3-300.fc23.x86_64 is not stable inside a KVM VM
https://bugzilla.redhat.com/show_bug.cgi?id=1314697

Ciao,
Gerhard


On 30.11.2016 08:10, Gerhard Wiesinger wrote:

Hello,

I'm having out of memory situations with my "low memory" VMs in KVM 
under Fedora (Kernel 4.7, 4.8 and also before). They started to get 
more and more sensitive to OOM. I recently found the following info:


https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/ 


https://www.spinics.net/lists/linux-mm/msg113661.html

Therefore I tried the latest Fedora kernels: 
4.9.0-0.rc6.git2.1.fc26.x86_64


But OOM situation is still very easy to reproduce:

1.) VM with 128-384MB under Fedora 25

2.) Having some processes run without any load (e.g. Apache)

3.) run an update with: dnf clean all; dnf update

4.) dnf python process get's killed


Please make the VM system working again in Kernel 4.9 and to use swap 
again correctly.


Thnx.

Ciao,

Gerhard

Re: Still OOM problems with 4.9er kernels

[Gerhard Wiesinger]

Hello,

See also:
Bug 1314697 - Kernel 4.4.3-300.fc23.x86_64 is not stable inside a KVM VM
https://bugzilla.redhat.com/show_bug.cgi?id=1314697

Ciao,
Gerhard


On 30.11.2016 08:10, Gerhard Wiesinger wrote:

Hello,

I'm having out of memory situations with my "low memory" VMs in KVM 
under Fedora (Kernel 4.7, 4.8 and also before). They started to get 
more and more sensitive to OOM. I recently found the following info:


https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/ 


https://www.spinics.net/lists/linux-mm/msg113661.html

Therefore I tried the latest Fedora kernels: 
4.9.0-0.rc6.git2.1.fc26.x86_64


But OOM situation is still very easy to reproduce:

1.) VM with 128-384MB under Fedora 25

2.) Having some processes run without any load (e.g. Apache)

3.) run an update with: dnf clean all; dnf update

4.) dnf python process get's killed


Please make the VM system working again in Kernel 4.9 and to use swap 
again correctly.


Thnx.

Ciao,

Gerhard

[PATCH] printk: Fix spinlock deadlock in printk reenty

[linyongting]

From: Jinling Ke 

when Oops in printk, printk will call zap_locks() to reinitialize
spinlock to prevent deadlock. In arm, arm64, x86 or other
architecture smp cpu, race condition will occur in printk spinlock
logbuf_lock and then it will result other cpu that is waiting printk
spinlock in deadlock(in function raw_spin_lock). Because the cpus
deadlock, you can see the error  printk log:

"SMP: failed to stop secondary CPUs"

In arm, arm64, x86 or other architecture, spinlock variable
is divided into 2 parts, for example they are 'owner' and 'next' in arm.
When get a spinlock, the 'next' part will add 1 and wait 'next' being
equal to 'owner'. However, at this moment, the 'next' part is local
variable, but 'owner' part value is get from global variable logbuf_lock.
However,raw_spin_lock_init(_lock) will set 'owner' part and
'next' part to zero, the result is that cpu deadlock in function
raw_spin_lock( while loop in function arch_spin_lock ).

struct of arm spinlock
union {
u32 slock;
struct __raw_tickets {
u16 owner;
u16 next;
} tickets;
};
} arch_spinlock_t;
static inline void arch_spin_lock(arch_spinlock_t *lock)
{...
<--- At the moment, other cpu call 
zap_locks()->spin_lock_init(),
<--- set the 'owner' part to zero, but lockval.tickets.next is a
<--- local variable
while (lockval.tickets.next != lockval.tickets.owner) {
lockval.tickets.owner = 
ACCESS_ONCE(lock->tickets.owner);
}
...
}

The solution is that In function zap_locks(), replace
raw_spin_lock_init(_lock) with raw_spin_unlock(_lock),
to let spin_lock stay in unlocked.

Signed-off-by: Jinling Ke 
---
 kernel/printk/printk.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index f7a55e9..05b1886 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1603,7 +1603,7 @@ static void zap_locks(void)
 
debug_locks_off();
/* If a crash is occurring, make sure we can't deadlock */
-   raw_spin_lock_init(_lock);
+   raw_spin_unlock(_lock);
/* And make sure that we print immediately */
sema_init(_sem, 1);
 }
-- 
1.7.9.5

[PATCH 10/11] ACPICA: Utilities: Add new decode function for parser values

[Lv Zheng]

From: Bob Moore 

ACPICA commit 198fde8a061ac77357bcf1752e3c988fbe59f128

Implements a decode function for the ARGP_* parser info values
for all AML opcodes.

Link: https://github.com/acpica/acpica/commit/198fde8a
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acutils.h  |2 ++
 drivers/acpi/acpica/amlcode.h  |1 +
 drivers/acpi/acpica/utdecode.c |   49 
 3 files changed, 52 insertions(+)

diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index 0a1b53c..845afb1 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -232,6 +232,8 @@ struct acpi_pkg_info {
 
 const char *acpi_ut_get_event_name(u32 event_id);
 
+const char *acpi_ut_get_argument_type_name(u32 arg_type);
+
 char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
 
 acpi_status acpi_ut_ascii_to_hex_byte(char *two_ascii_chars, u8 *return_byte);
diff --git a/drivers/acpi/acpica/amlcode.h b/drivers/acpi/acpica/amlcode.h
index 04fbd88..8a0f959 100644
--- a/drivers/acpi/acpica/amlcode.h
+++ b/drivers/acpi/acpica/amlcode.h
@@ -240,6 +240,7 @@
 #define ARGP_QWORDDATA  0x11
 #define ARGP_SIMPLENAME 0x12   /* name_string | local_term | 
arg_term */
 #define ARGP_NAME_OR_REF0x13   /* For object_type only */
+#define ARGP_MAX0x13
 
 /*
  * Resolved argument types for the AML Interpreter
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 15728ad..b3d8421 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -44,6 +44,7 @@
 #include 
 #include "accommon.h"
 #include "acnamesp.h"
+#include "amlcode.h"
 
 #define _COMPONENT  ACPI_UTILITIES
 ACPI_MODULE_NAME("utdecode")
@@ -532,6 +533,54 @@ const char *acpi_ut_get_notify_name(u32 notify_value, 
acpi_object_type type)
 
return ("Hardware-Specific");
 }
+
+/***
+ *
+ * FUNCTION:acpi_ut_get_argument_type_name
+ *
+ * PARAMETERS:  arg_type- an ARGP_* parser argument type
+ *
+ * RETURN:  Decoded ARGP_* type
+ *
+ * DESCRIPTION: Decode an ARGP_* parser type, as defined in the amlcode.h file,
+ *  and used in the acopcode.h file. For example, ARGP_TERMARG.
+ *  Used for debug only.
+ *
+ 
**/
+
+static const char *acpi_gbl_argument_type[20] = {
+   /* 00 */ "Unknown ARGP",
+   /* 01 */ "ByteData",
+   /* 02 */ "ByteList",
+   /* 03 */ "CharList",
+   /* 04 */ "DataObject",
+   /* 05 */ "DataObjectList",
+   /* 06 */ "DWordData",
+   /* 07 */ "FieldList",
+   /* 08 */ "Name",
+   /* 09 */ "NameString",
+   /* 0A */ "ObjectList",
+   /* 0B */ "PackageLength",
+   /* 0C */ "SuperName",
+   /* 0D */ "Target",
+   /* 0E */ "TermArg",
+   /* 0F */ "TermList",
+   /* 10 */ "WordData",
+   /* 11 */ "QWordData",
+   /* 12 */ "SimpleName",
+   /* 13 */ "NameOrRef"
+};
+
+const char *acpi_ut_get_argument_type_name(u32 arg_type)
+{
+
+   if (arg_type > ARGP_MAX) {
+   return ("Unknown ARGP");
+   }
+
+   return (acpi_gbl_argument_type[arg_type]);
+}
+
 #endif
 
 
/***
-- 
1.7.10

Re: [PATCH 21/39] mtd: nand: denali: support 64bit capable DMA engine

[Boris Brezillon]

On Wed, 30 Nov 2016 16:11:53 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 2016-11-28 1:16 GMT+09:00 Boris Brezillon 
> :
> >
> > If you follow my suggestions of definition function pointers, you'll
> > just have to add a function pointer to the denali_caps struct:
> >
> > void (*setup_dma)(struct denali_nand_info *denali, int op);
> >  
> 
> 
> This is possible because both 32B and 64B variants have
> the same function prototype.
> 
> 
> However, I am not keen on doing so for ecc_handle(),
> so, at this moment, I am not keen on doing so only for setup_dma() either.
> 
> If I see more cases that fit in callback handler approach,
> I will think about switching to it with consistency.
> 

Pretty much all the flags you define in this series could be turned
into function pointers. I still think the function pointers approach is
more future-proof, but I won't fight on that, so do as you wish.

[PATCH] printk: Fix spinlock deadlock in printk reenty

[linyongting]

From: Jinling Ke 

when Oops in printk, printk will call zap_locks() to reinitialize
spinlock to prevent deadlock. In arm, arm64, x86 or other
architecture smp cpu, race condition will occur in printk spinlock
logbuf_lock and then it will result other cpu that is waiting printk
spinlock in deadlock(in function raw_spin_lock). Because the cpus
deadlock, you can see the error  printk log:

"SMP: failed to stop secondary CPUs"

In arm, arm64, x86 or other architecture, spinlock variable
is divided into 2 parts, for example they are 'owner' and 'next' in arm.
When get a spinlock, the 'next' part will add 1 and wait 'next' being
equal to 'owner'. However, at this moment, the 'next' part is local
variable, but 'owner' part value is get from global variable logbuf_lock.
However,raw_spin_lock_init(_lock) will set 'owner' part and
'next' part to zero, the result is that cpu deadlock in function
raw_spin_lock( while loop in function arch_spin_lock ).

struct of arm spinlock
union {
u32 slock;
struct __raw_tickets {
u16 owner;
u16 next;
} tickets;
};
} arch_spinlock_t;
static inline void arch_spin_lock(arch_spinlock_t *lock)
{...
<--- At the moment, other cpu call 
zap_locks()->spin_lock_init(),
<--- set the 'owner' part to zero, but lockval.tickets.next is a
<--- local variable
while (lockval.tickets.next != lockval.tickets.owner) {
lockval.tickets.owner = 
ACCESS_ONCE(lock->tickets.owner);
}
...
}

The solution is that In function zap_locks(), replace
raw_spin_lock_init(_lock) with raw_spin_unlock(_lock),
to let spin_lock stay in unlocked.

Signed-off-by: Jinling Ke 
---
 kernel/printk/printk.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index f7a55e9..05b1886 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1603,7 +1603,7 @@ static void zap_locks(void)
 
debug_locks_off();
/* If a crash is occurring, make sure we can't deadlock */
-   raw_spin_lock_init(_lock);
+   raw_spin_unlock(_lock);
/* And make sure that we print immediately */
sema_init(_sem, 1);
 }
-- 
1.7.9.5

[PATCH 10/11] ACPICA: Utilities: Add new decode function for parser values

[Lv Zheng]

From: Bob Moore 

ACPICA commit 198fde8a061ac77357bcf1752e3c988fbe59f128

Implements a decode function for the ARGP_* parser info values
for all AML opcodes.

Link: https://github.com/acpica/acpica/commit/198fde8a
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acutils.h  |2 ++
 drivers/acpi/acpica/amlcode.h  |1 +
 drivers/acpi/acpica/utdecode.c |   49 
 3 files changed, 52 insertions(+)

diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index 0a1b53c..845afb1 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -232,6 +232,8 @@ struct acpi_pkg_info {
 
 const char *acpi_ut_get_event_name(u32 event_id);
 
+const char *acpi_ut_get_argument_type_name(u32 arg_type);
+
 char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
 
 acpi_status acpi_ut_ascii_to_hex_byte(char *two_ascii_chars, u8 *return_byte);
diff --git a/drivers/acpi/acpica/amlcode.h b/drivers/acpi/acpica/amlcode.h
index 04fbd88..8a0f959 100644
--- a/drivers/acpi/acpica/amlcode.h
+++ b/drivers/acpi/acpica/amlcode.h
@@ -240,6 +240,7 @@
 #define ARGP_QWORDDATA  0x11
 #define ARGP_SIMPLENAME 0x12   /* name_string | local_term | 
arg_term */
 #define ARGP_NAME_OR_REF0x13   /* For object_type only */
+#define ARGP_MAX0x13
 
 /*
  * Resolved argument types for the AML Interpreter
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 15728ad..b3d8421 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -44,6 +44,7 @@
 #include 
 #include "accommon.h"
 #include "acnamesp.h"
+#include "amlcode.h"
 
 #define _COMPONENT  ACPI_UTILITIES
 ACPI_MODULE_NAME("utdecode")
@@ -532,6 +533,54 @@ const char *acpi_ut_get_notify_name(u32 notify_value, 
acpi_object_type type)
 
return ("Hardware-Specific");
 }
+
+/***
+ *
+ * FUNCTION:acpi_ut_get_argument_type_name
+ *
+ * PARAMETERS:  arg_type- an ARGP_* parser argument type
+ *
+ * RETURN:  Decoded ARGP_* type
+ *
+ * DESCRIPTION: Decode an ARGP_* parser type, as defined in the amlcode.h file,
+ *  and used in the acopcode.h file. For example, ARGP_TERMARG.
+ *  Used for debug only.
+ *
+ 
**/
+
+static const char *acpi_gbl_argument_type[20] = {
+   /* 00 */ "Unknown ARGP",
+   /* 01 */ "ByteData",
+   /* 02 */ "ByteList",
+   /* 03 */ "CharList",
+   /* 04 */ "DataObject",
+   /* 05 */ "DataObjectList",
+   /* 06 */ "DWordData",
+   /* 07 */ "FieldList",
+   /* 08 */ "Name",
+   /* 09 */ "NameString",
+   /* 0A */ "ObjectList",
+   /* 0B */ "PackageLength",
+   /* 0C */ "SuperName",
+   /* 0D */ "Target",
+   /* 0E */ "TermArg",
+   /* 0F */ "TermList",
+   /* 10 */ "WordData",
+   /* 11 */ "QWordData",
+   /* 12 */ "SimpleName",
+   /* 13 */ "NameOrRef"
+};
+
+const char *acpi_ut_get_argument_type_name(u32 arg_type)
+{
+
+   if (arg_type > ARGP_MAX) {
+   return ("Unknown ARGP");
+   }
+
+   return (acpi_gbl_argument_type[arg_type]);
+}
+
 #endif
 
 
/***
-- 
1.7.10

Re: [PATCH 21/39] mtd: nand: denali: support 64bit capable DMA engine

[Boris Brezillon]

On Wed, 30 Nov 2016 16:11:53 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 2016-11-28 1:16 GMT+09:00 Boris Brezillon 
> :
> >
> > If you follow my suggestions of definition function pointers, you'll
> > just have to add a function pointer to the denali_caps struct:
> >
> > void (*setup_dma)(struct denali_nand_info *denali, int op);
> >  
> 
> 
> This is possible because both 32B and 64B variants have
> the same function prototype.
> 
> 
> However, I am not keen on doing so for ecc_handle(),
> so, at this moment, I am not keen on doing so only for setup_dma() either.
> 
> If I see more cases that fit in callback handler approach,
> I will think about switching to it with consistency.
> 

Pretty much all the flags you define in this series could be turned
into function pointers. I still think the function pointers approach is
more future-proof, but I won't fight on that, so do as you wish.

[PATCH 00/11] ACPICA: 20161117 Release

[Lv Zheng]

The 20161117 ACPICA kernel-resident subsystem updates are linuxized based
on the linux-pm/linux-next branch.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + allyes
2. i386 + allno
3. i386 + default + ACPI_DEBUGGER=y
4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
5. i386 + default + ACPI_DEBUG=n + ACPI=y
6. i386 + default + ACPI=n
7. x86_64 + allyes
8. x86_64 + allno
9. x86_64 + default + ACPI_DEBUGGER=y
10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
12.x86_64 + default + ACPI=n
Boot tests are performed as follows:
1. i386 + default + ACPI_DEBUGGER=y
2. x86_64 + default + ACPI_DEBUGGER=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "Microsoft Surface Pro 3"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All "drivers/acpi" configurations
   All "drivers/platform" drivers
   All other drivers that link the APIs provided by ACPICA subsystem

The divergences checking result:
Before applying (20160930 Release):
  508 lines
After applying (20161117 Release):
  467 lines

Bob Moore (3):
  ACPICA: Fix for implicit result conversion for the To functions
  ACPICA: Utilities: Add new decode function for parser values
  ACPICA: Update version to 20161117

Lv Zheng (8):
  ACPICA: Namespace: Add acpi_ns_handle_to_name()
  ACPICA: Back port of "ACPICA: Dispatcher: Tune interpreter lock
around AcpiEvInitializeRegion()"
  ACPICA: Events: Fix acpi_ev_initialize_region() return value
  ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()
  ACPICA: Tables: Add acpi_tb_unload_table()
  ACPICA: Tables: Add an error message complaining driver bugs
  ACPICA: Tables: Back port acpi_get_table_with_size() and
early_acpi_os_unmap_memory() from Linux kernel
  ACPICA: Tables: Allow FADT to be customized with virtual address

 drivers/acpi/acpica/acevents.h|4 +-
 drivers/acpi/acpica/acnamesp.h|3 +
 drivers/acpi/acpica/acopcode.h|   14 ++--
 drivers/acpi/acpica/actables.h|   11 ++-
 drivers/acpi/acpica/acutils.h |2 +
 drivers/acpi/acpica/amlcode.h |   21 +-
 drivers/acpi/acpica/dsinit.c  |4 +-
 drivers/acpi/acpica/dsopcode.c|2 +-
 drivers/acpi/acpica/dswload2.c|   13 +---
 drivers/acpi/acpica/evrgnini.c|   59 ++-
 drivers/acpi/acpica/exconfig.c|   42 +--
 drivers/acpi/acpica/exconvrt.c|1 -
 drivers/acpi/acpica/exresop.c |1 -
 drivers/acpi/acpica/nsnames.c |   45 
 drivers/acpi/acpica/nsxfname.c|   43 +++
 drivers/acpi/acpica/tbdata.c  |   81 +++-
 drivers/acpi/acpica/tbfadt.c  |   14 ++--
 drivers/acpi/acpica/tbutils.c |   85 +
 drivers/acpi/acpica/tbxface.c |  146 +
 drivers/acpi/acpica/tbxfload.c|   38 +-
 drivers/acpi/acpica/utdecode.c|   49 +
 drivers/acpi/osl.c|   31 +++-
 include/acpi/acpixf.h |   14 +++-
 include/acpi/actbl.h  |1 +
 include/acpi/platform/aclinuxex.h |1 -
 25 files changed, 458 insertions(+), 267 deletions(-)

-- 
1.7.10

[PATCH 07/11] ACPICA: Tables: Add an error message complaining driver bugs

[Lv Zheng]

ACPICA commit 68af3c3aa238dd8040e846ac6b4827a016434d8d

During early OS boot stage, drivers that have mapped system memory should
unmap it during the same stage. Linux kernel has an error message
indicating the unbalanced early memory mappings.

This patch back ports such error message into ACPICA for the early table
mappings, so that ACPICA development environment is also aware of this OS
specific requirement and thus is able to ensure the consistent quality
locally. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/68af3c3a
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/tbxface.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index 4ab6b9c..d5adb7a 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -167,6 +167,7 @@ acpi_status acpi_allocate_root_table(u32 
initial_table_count)
 acpi_status ACPI_INIT_FUNCTION acpi_reallocate_root_table(void)
 {
acpi_status status;
+   u32 i;
 
ACPI_FUNCTION_TRACE(acpi_reallocate_root_table);
 
@@ -178,6 +179,21 @@ acpi_status ACPI_INIT_FUNCTION 
acpi_reallocate_root_table(void)
return_ACPI_STATUS(AE_SUPPORT);
}
 
+   /*
+* Ensure OS early boot logic, which is required by some hosts. If the
+* table state is reported to be wrong, developers should fix the
+* issue by invoking acpi_put_table() for the reported table during the
+* early stage.
+*/
+   for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) {
+   if (acpi_gbl_root_table_list.tables[i].pointer) {
+   ACPI_ERROR((AE_INFO,
+   "Table [%4.4s] is not invalidated during 
early boot stage",
+   acpi_gbl_root_table_list.tables[i].
+   signature.ascii));
+   }
+   }
+
acpi_gbl_root_table_list.flags |= ACPI_ROOT_ALLOW_RESIZE;
 
status = acpi_tb_resize_root_table_list();
-- 
1.7.10

[PATCH 02/11] ACPICA: Back port of "ACPICA: Dispatcher: Tune interpreter lock around AcpiEvInitializeRegion()"

[Lv Zheng]

ACPICA commit bc481e758e54f7644fd0b657119ca7763d8b6a9c

This is a back port result of the following commit:
  Commit: 8633db6b027952449e155a316f4ae3a530bbe18f
  Subject: ACPICA: Dispatcher: Fix interpreter locking around 
acpi_ev_initialize_region()

Link: https://github.com/acpica/acpica/commit/bc481e75
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/dsinit.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index 54d48b9..5de3f10 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -221,8 +221,8 @@
 */
status =
acpi_ns_walk_namespace(ACPI_TYPE_ANY, start_node, ACPI_UINT32_MAX,
-  0, acpi_ds_init_one_object, NULL, ,
-  NULL);
+  ACPI_NS_WALK_NO_UNLOCK,
+  acpi_ds_init_one_object, NULL, , NULL);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status, "During WalkNamespace"));
}
-- 
1.7.10

[PATCH 09/11] ACPICA: Tables: Allow FADT to be customized with virtual address

[Lv Zheng]

ACPICA commit d98de9ca14891130efc5dcdc871b97eb27b4b0f5

FADT parsing code requires FADT to be installed as
ACPI_TABLE_ORIGIN_INTERNAL_PHYSICAL, using new
acpi_tb_get_table()/acpi_tb_put_table(), other address types can also be 
allowed,
thus facilitates FADT customization with virtual address. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/d98de9ca
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/tbfadt.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 5fb838e..81473a4 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -311,6 +311,8 @@ void acpi_tb_parse_fadt(void)
 {
u32 length;
struct acpi_table_header *table;
+   struct acpi_table_desc *fadt_desc;
+   acpi_status status;
 
/*
 * The FADT has multiple versions with different lengths,
@@ -319,14 +321,12 @@ void acpi_tb_parse_fadt(void)
 * Get a local copy of the FADT and convert it to a common format
 * Map entire FADT, assumed to be smaller than one page.
 */
-   length = acpi_gbl_root_table_list.tables[acpi_gbl_fadt_index].length;
-
-   table =
-   acpi_os_map_memory(acpi_gbl_root_table_list.
-  tables[acpi_gbl_fadt_index].address, length);
-   if (!table) {
+   fadt_desc = _gbl_root_table_list.tables[acpi_gbl_fadt_index];
+   status = acpi_tb_get_table(fadt_desc, );
+   if (ACPI_FAILURE(status)) {
return;
}
+   length = fadt_desc->length;
 
/*
 * Validate the FADT checksum before we copy the table. Ignore
@@ -340,7 +340,7 @@ void acpi_tb_parse_fadt(void)
 
/* All done with the real FADT, unmap it */
 
-   acpi_os_unmap_memory(table, length);
+   acpi_tb_put_table(fadt_desc);
 
/* Obtain the DSDT and FACS tables via their addresses within the FADT 
*/
 
-- 
1.7.10

[PATCH 02/11] ACPICA: Back port of "ACPICA: Dispatcher: Tune interpreter lock around AcpiEvInitializeRegion()"

[Lv Zheng]

ACPICA commit bc481e758e54f7644fd0b657119ca7763d8b6a9c

This is a back port result of the following commit:
  Commit: 8633db6b027952449e155a316f4ae3a530bbe18f
  Subject: ACPICA: Dispatcher: Fix interpreter locking around 
acpi_ev_initialize_region()

Link: https://github.com/acpica/acpica/commit/bc481e75
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/dsinit.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index 54d48b9..5de3f10 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -221,8 +221,8 @@
 */
status =
acpi_ns_walk_namespace(ACPI_TYPE_ANY, start_node, ACPI_UINT32_MAX,
-  0, acpi_ds_init_one_object, NULL, ,
-  NULL);
+  ACPI_NS_WALK_NO_UNLOCK,
+  acpi_ds_init_one_object, NULL, , NULL);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status, "During WalkNamespace"));
}
-- 
1.7.10

[PATCH 09/11] ACPICA: Tables: Allow FADT to be customized with virtual address

[Lv Zheng]

ACPICA commit d98de9ca14891130efc5dcdc871b97eb27b4b0f5

FADT parsing code requires FADT to be installed as
ACPI_TABLE_ORIGIN_INTERNAL_PHYSICAL, using new
acpi_tb_get_table()/acpi_tb_put_table(), other address types can also be 
allowed,
thus facilitates FADT customization with virtual address. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/d98de9ca
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/tbfadt.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 5fb838e..81473a4 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -311,6 +311,8 @@ void acpi_tb_parse_fadt(void)
 {
u32 length;
struct acpi_table_header *table;
+   struct acpi_table_desc *fadt_desc;
+   acpi_status status;
 
/*
 * The FADT has multiple versions with different lengths,
@@ -319,14 +321,12 @@ void acpi_tb_parse_fadt(void)
 * Get a local copy of the FADT and convert it to a common format
 * Map entire FADT, assumed to be smaller than one page.
 */
-   length = acpi_gbl_root_table_list.tables[acpi_gbl_fadt_index].length;
-
-   table =
-   acpi_os_map_memory(acpi_gbl_root_table_list.
-  tables[acpi_gbl_fadt_index].address, length);
-   if (!table) {
+   fadt_desc = _gbl_root_table_list.tables[acpi_gbl_fadt_index];
+   status = acpi_tb_get_table(fadt_desc, );
+   if (ACPI_FAILURE(status)) {
return;
}
+   length = fadt_desc->length;
 
/*
 * Validate the FADT checksum before we copy the table. Ignore
@@ -340,7 +340,7 @@ void acpi_tb_parse_fadt(void)
 
/* All done with the real FADT, unmap it */
 
-   acpi_os_unmap_memory(table, length);
+   acpi_tb_put_table(fadt_desc);
 
/* Obtain the DSDT and FACS tables via their addresses within the FADT 
*/
 
-- 
1.7.10

[PATCH 07/11] ACPICA: Tables: Add an error message complaining driver bugs

[Lv Zheng]

ACPICA commit 68af3c3aa238dd8040e846ac6b4827a016434d8d

During early OS boot stage, drivers that have mapped system memory should
unmap it during the same stage. Linux kernel has an error message
indicating the unbalanced early memory mappings.

This patch back ports such error message into ACPICA for the early table
mappings, so that ACPICA development environment is also aware of this OS
specific requirement and thus is able to ensure the consistent quality
locally. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/68af3c3a
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/tbxface.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index 4ab6b9c..d5adb7a 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -167,6 +167,7 @@ acpi_status acpi_allocate_root_table(u32 
initial_table_count)
 acpi_status ACPI_INIT_FUNCTION acpi_reallocate_root_table(void)
 {
acpi_status status;
+   u32 i;
 
ACPI_FUNCTION_TRACE(acpi_reallocate_root_table);
 
@@ -178,6 +179,21 @@ acpi_status ACPI_INIT_FUNCTION 
acpi_reallocate_root_table(void)
return_ACPI_STATUS(AE_SUPPORT);
}
 
+   /*
+* Ensure OS early boot logic, which is required by some hosts. If the
+* table state is reported to be wrong, developers should fix the
+* issue by invoking acpi_put_table() for the reported table during the
+* early stage.
+*/
+   for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) {
+   if (acpi_gbl_root_table_list.tables[i].pointer) {
+   ACPI_ERROR((AE_INFO,
+   "Table [%4.4s] is not invalidated during 
early boot stage",
+   acpi_gbl_root_table_list.tables[i].
+   signature.ascii));
+   }
+   }
+
acpi_gbl_root_table_list.flags |= ACPI_ROOT_ALLOW_RESIZE;
 
status = acpi_tb_resize_root_table_list();
-- 
1.7.10

[PATCH 00/11] ACPICA: 20161117 Release

[Lv Zheng]

The 20161117 ACPICA kernel-resident subsystem updates are linuxized based
on the linux-pm/linux-next branch.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + allyes
2. i386 + allno
3. i386 + default + ACPI_DEBUGGER=y
4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
5. i386 + default + ACPI_DEBUG=n + ACPI=y
6. i386 + default + ACPI=n
7. x86_64 + allyes
8. x86_64 + allno
9. x86_64 + default + ACPI_DEBUGGER=y
10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
12.x86_64 + default + ACPI=n
Boot tests are performed as follows:
1. i386 + default + ACPI_DEBUGGER=y
2. x86_64 + default + ACPI_DEBUGGER=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "Microsoft Surface Pro 3"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All "drivers/acpi" configurations
   All "drivers/platform" drivers
   All other drivers that link the APIs provided by ACPICA subsystem

The divergences checking result:
Before applying (20160930 Release):
  508 lines
After applying (20161117 Release):
  467 lines

Bob Moore (3):
  ACPICA: Fix for implicit result conversion for the To functions
  ACPICA: Utilities: Add new decode function for parser values
  ACPICA: Update version to 20161117

Lv Zheng (8):
  ACPICA: Namespace: Add acpi_ns_handle_to_name()
  ACPICA: Back port of "ACPICA: Dispatcher: Tune interpreter lock
around AcpiEvInitializeRegion()"
  ACPICA: Events: Fix acpi_ev_initialize_region() return value
  ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()
  ACPICA: Tables: Add acpi_tb_unload_table()
  ACPICA: Tables: Add an error message complaining driver bugs
  ACPICA: Tables: Back port acpi_get_table_with_size() and
early_acpi_os_unmap_memory() from Linux kernel
  ACPICA: Tables: Allow FADT to be customized with virtual address

 drivers/acpi/acpica/acevents.h|4 +-
 drivers/acpi/acpica/acnamesp.h|3 +
 drivers/acpi/acpica/acopcode.h|   14 ++--
 drivers/acpi/acpica/actables.h|   11 ++-
 drivers/acpi/acpica/acutils.h |2 +
 drivers/acpi/acpica/amlcode.h |   21 +-
 drivers/acpi/acpica/dsinit.c  |4 +-
 drivers/acpi/acpica/dsopcode.c|2 +-
 drivers/acpi/acpica/dswload2.c|   13 +---
 drivers/acpi/acpica/evrgnini.c|   59 ++-
 drivers/acpi/acpica/exconfig.c|   42 +--
 drivers/acpi/acpica/exconvrt.c|1 -
 drivers/acpi/acpica/exresop.c |1 -
 drivers/acpi/acpica/nsnames.c |   45 
 drivers/acpi/acpica/nsxfname.c|   43 +++
 drivers/acpi/acpica/tbdata.c  |   81 +++-
 drivers/acpi/acpica/tbfadt.c  |   14 ++--
 drivers/acpi/acpica/tbutils.c |   85 +
 drivers/acpi/acpica/tbxface.c |  146 +
 drivers/acpi/acpica/tbxfload.c|   38 +-
 drivers/acpi/acpica/utdecode.c|   49 +
 drivers/acpi/osl.c|   31 +++-
 include/acpi/acpixf.h |   14 +++-
 include/acpi/actbl.h  |1 +
 include/acpi/platform/aclinuxex.h |1 -
 25 files changed, 458 insertions(+), 267 deletions(-)

-- 
1.7.10

Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c

[Michal Hocko]

On Tue 29-11-16 11:14:48, Paul E. McKenney wrote:
> On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
> > On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
> >  wrote:
> > >
> > > FYI, we noticed the following commit:
> > >
> > > commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent 
> > > __alloc_pages_nodemask() RCU CPU stall warnings")
> > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > rcu/next
> > >
> > > in testcase: boot
> > >
> > > on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
> > >
> > > caused below changes:
> > >
> > [...]
> > 
> > > [8.953192] BUG: sleeping function called from invalid context at 
> > > mm/page_alloc.c:3746
> > > [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
> > 
> > I am observing similar BUG/backtrace even on ARM64 platform.
> 
> Does the (untested) patch below help?
> 
>   Thanx, Paul
> 
> 
> 
> commit ccc0666e2049e5818c236e647cf20c552a7b053b
> Author: Paul E. McKenney 
> Date:   Tue Nov 29 11:06:05 2016 -0800
> 
> rcu: Allow boot-time use of cond_resched_rcu_qs()
> 
> The cond_resched_rcu_qs() macro is used to force RCU quiescent states into
> long-running in-kernel loops.  However, some of these loops can execute
> during early boot when interrupts are disabled, and during which time
> it is therefore illegal to enter the scheduler.  This commit therefore
> makes cond_resched_rcu_qs() be a no-op during early boot.
> 
> Signed-off-by: Paul E. McKenney 

This is not the problem with your "mm: Prevent __alloc_pages_nodemask()
RCU CPU stall warnings", though. The main problem imho is that the
allocator might be called from the atomic contexts (aka
gfp_mask & ~__GFP_DIRECT_RECLAIM). Besides that I do not think that any
variant of cond_resched inside the allocator hot path
__alloc_pages_nodemask is just wrong. If anything such a scheduling/RCU
point should be added to the slow path. But as I've said earlier we
already have these points in that path so new ones shouldn't be really
necessary.

Could you drop this patch Paul, please?

-- 
Michal Hocko
SUSE Labs

Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c

[Michal Hocko]

On Tue 29-11-16 11:14:48, Paul E. McKenney wrote:
> On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
> > On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
> >  wrote:
> > >
> > > FYI, we noticed the following commit:
> > >
> > > commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent 
> > > __alloc_pages_nodemask() RCU CPU stall warnings")
> > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > rcu/next
> > >
> > > in testcase: boot
> > >
> > > on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
> > >
> > > caused below changes:
> > >
> > [...]
> > 
> > > [8.953192] BUG: sleeping function called from invalid context at 
> > > mm/page_alloc.c:3746
> > > [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
> > 
> > I am observing similar BUG/backtrace even on ARM64 platform.
> 
> Does the (untested) patch below help?
> 
>   Thanx, Paul
> 
> 
> 
> commit ccc0666e2049e5818c236e647cf20c552a7b053b
> Author: Paul E. McKenney 
> Date:   Tue Nov 29 11:06:05 2016 -0800
> 
> rcu: Allow boot-time use of cond_resched_rcu_qs()
> 
> The cond_resched_rcu_qs() macro is used to force RCU quiescent states into
> long-running in-kernel loops.  However, some of these loops can execute
> during early boot when interrupts are disabled, and during which time
> it is therefore illegal to enter the scheduler.  This commit therefore
> makes cond_resched_rcu_qs() be a no-op during early boot.
> 
> Signed-off-by: Paul E. McKenney 

This is not the problem with your "mm: Prevent __alloc_pages_nodemask()
RCU CPU stall warnings", though. The main problem imho is that the
allocator might be called from the atomic contexts (aka
gfp_mask & ~__GFP_DIRECT_RECLAIM). Besides that I do not think that any
variant of cond_resched inside the allocator hot path
__alloc_pages_nodemask is just wrong. If anything such a scheduling/RCU
point should be added to the slow path. But as I've said earlier we
already have these points in that path so new ones shouldn't be really
necessary.

Could you drop this patch Paul, please?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 04/39] mtd: nand: denali: remove more unused struct members

[Masahiro Yamada]

Hi Boris,


2016-11-28 0:12 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:05:50 +0900
> Masahiro Yamada  wrote:
>
> Please add a description here.
>
> Also, this commit tends to validate my fears: you should have wait for
> the full rework/cleanup to be done before submitting the first round of
> cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused
> struct member denali_nand_info::idx") was removing one of these unused
> fields, leaving 2 of them behind.

Right.
No difference except that
denali->idx was initialized to zero(, but not referenced).

I could squash the two patches.


> While I like when things I clearly separated in different commits, when
> you push the logic too far, you end up with big series which are not
> necessarily easier to review, and several commits that are achieving
> the same goal...


I must admit that I hurried up in posting the first round.
But, please note I did not ask you to pick it up for v4.10-rc1.
After all, it was your choice whether you picked it soon or
waited until you saw the big picture.
You could have postponed it until v4.11-rc1 if you had wanted.

My idea was, I'd like to get feedback earlier
(especially from Intel engineers).

I fear that I do not reveal anything until I complete my work.
If I am doing wrong in the early patches in my big series,
I might end up with lots of effort to turn around.

I dropped various Intel-specific things,
for example commit c9e025843242 ("mtd: nand: denali: remove
detect_partition_feature()")
removed the whole function I do not understand.
There was possibility that it might be locally used by Intel platforms.

If I had gotten negative comments for removal, I'd have needed more efforts
to not break any old functions.

As a result, nobody was opposed to delete such things.
So, I can confidently continue my work on cleaner and more *stable* base.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 04/39] mtd: nand: denali: remove more unused struct members

[Masahiro Yamada]

Hi Boris,


2016-11-28 0:12 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:05:50 +0900
> Masahiro Yamada  wrote:
>
> Please add a description here.
>
> Also, this commit tends to validate my fears: you should have wait for
> the full rework/cleanup to be done before submitting the first round of
> cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused
> struct member denali_nand_info::idx") was removing one of these unused
> fields, leaving 2 of them behind.

Right.
No difference except that
denali->idx was initialized to zero(, but not referenced).

I could squash the two patches.


> While I like when things I clearly separated in different commits, when
> you push the logic too far, you end up with big series which are not
> necessarily easier to review, and several commits that are achieving
> the same goal...


I must admit that I hurried up in posting the first round.
But, please note I did not ask you to pick it up for v4.10-rc1.
After all, it was your choice whether you picked it soon or
waited until you saw the big picture.
You could have postponed it until v4.11-rc1 if you had wanted.

My idea was, I'd like to get feedback earlier
(especially from Intel engineers).

I fear that I do not reveal anything until I complete my work.
If I am doing wrong in the early patches in my big series,
I might end up with lots of effort to turn around.

I dropped various Intel-specific things,
for example commit c9e025843242 ("mtd: nand: denali: remove
detect_partition_feature()")
removed the whole function I do not understand.
There was possibility that it might be locally used by Intel platforms.

If I had gotten negative comments for removal, I'd have needed more efforts
to not break any old functions.

As a result, nobody was opposed to delete such things.
So, I can confidently continue my work on cleaner and more *stable* base.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 21/39] mtd: nand: denali: support 64bit capable DMA engine

[Masahiro Yamada]

Hi Boris,

2016-11-28 1:16 GMT+09:00 Boris Brezillon :
>
> If you follow my suggestions of definition function pointers, you'll
> just have to add a function pointer to the denali_caps struct:
>
> void (*setup_dma)(struct denali_nand_info *denali, int op);
>


This is possible because both 32B and 64B variants have
the same function prototype.


However, I am not keen on doing so for ecc_handle(),
so, at this moment, I am not keen on doing so only for setup_dma() either.

If I see more cases that fit in callback handler approach,
I will think about switching to it with consistency.

-- 
Best Regards
Masahiro Yamada

Re: [PATCH 21/39] mtd: nand: denali: support 64bit capable DMA engine

[Masahiro Yamada]

Hi Boris,

2016-11-28 1:16 GMT+09:00 Boris Brezillon :
>
> If you follow my suggestions of definition function pointers, you'll
> just have to add a function pointer to the denali_caps struct:
>
> void (*setup_dma)(struct denali_nand_info *denali, int op);
>


This is possible because both 32B and 64B variants have
the same function prototype.


However, I am not keen on doing so for ecc_handle(),
so, at this moment, I am not keen on doing so only for setup_dma() either.

If I see more cases that fit in callback handler approach,
I will think about switching to it with consistency.

-- 
Best Regards
Masahiro Yamada

[PATCH] lib/idr: trivial: Fix typo in file header

[Cao jin]

Signed-off-by: Cao jin 
---
 lib/idr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/idr.c b/lib/idr.c
index 6098336df267..69fa487dbfda 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -14,7 +14,7 @@
  * by the id to obtain the pointer.  The bitmap makes allocating
  * a new id quick.
  *
- * You call it to allocate an id (an int) an associate with that id a
+ * You call it to allocate an id (an int) and associate with that id a
  * pointer or what ever, we treat it as a (void *).  You can pass this
  * id to a user for him to pass back at a later time.  You then pass
  * that id to this code and it returns your pointer.
-- 
2.1.0

[PATCH] vfio: Fix handling of error returned by 'vfio_group_get_from_dev()'

[Christophe JAILLET]

'vfio_group_get_from_dev()' seems to return only NULL on error, not an error
pointer.

Fixes: 2169037dc322 ("vfio iommu: Added pin and unpin callback functions to 
vfio_iommu_driver_ops")
Fixes: c086de818dd8 ("vfio iommu: Add blocking notifier to notify DMA_UNMAP")

Signed-off-by: Christophe JAILLET 
---
This could be split in 2 patches in order to have only one Fixes tag in
each
---
 drivers/vfio/vfio.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 0aac3ca54a53..7b39313abf0d 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1933,8 +1933,8 @@ int vfio_pin_pages(struct device *dev, unsigned long 
*user_pfn, int npage,
return -E2BIG;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
@@ -1982,8 +1982,8 @@ int vfio_unpin_pages(struct device *dev, unsigned long 
*user_pfn, int npage)
return -E2BIG;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
@@ -2019,8 +2019,8 @@ int vfio_register_notifier(struct device *dev, struct 
notifier_block *nb)
return -EINVAL;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
@@ -2055,8 +2055,8 @@ int vfio_unregister_notifier(struct device *dev, struct 
notifier_block *nb)
return -EINVAL;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
-- 
2.9.3

[PATCH] lib/idr: trivial: Fix typo in file header

[Cao jin]

Signed-off-by: Cao jin 
---
 lib/idr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/idr.c b/lib/idr.c
index 6098336df267..69fa487dbfda 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -14,7 +14,7 @@
  * by the id to obtain the pointer.  The bitmap makes allocating
  * a new id quick.
  *
- * You call it to allocate an id (an int) an associate with that id a
+ * You call it to allocate an id (an int) and associate with that id a
  * pointer or what ever, we treat it as a (void *).  You can pass this
  * id to a user for him to pass back at a later time.  You then pass
  * that id to this code and it returns your pointer.
-- 
2.1.0

[PATCH] vfio: Fix handling of error returned by 'vfio_group_get_from_dev()'

[Christophe JAILLET]

'vfio_group_get_from_dev()' seems to return only NULL on error, not an error
pointer.

Fixes: 2169037dc322 ("vfio iommu: Added pin and unpin callback functions to 
vfio_iommu_driver_ops")
Fixes: c086de818dd8 ("vfio iommu: Add blocking notifier to notify DMA_UNMAP")

Signed-off-by: Christophe JAILLET 
---
This could be split in 2 patches in order to have only one Fixes tag in
each
---
 drivers/vfio/vfio.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 0aac3ca54a53..7b39313abf0d 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1933,8 +1933,8 @@ int vfio_pin_pages(struct device *dev, unsigned long 
*user_pfn, int npage,
return -E2BIG;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
@@ -1982,8 +1982,8 @@ int vfio_unpin_pages(struct device *dev, unsigned long 
*user_pfn, int npage)
return -E2BIG;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
@@ -2019,8 +2019,8 @@ int vfio_register_notifier(struct device *dev, struct 
notifier_block *nb)
return -EINVAL;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
@@ -2055,8 +2055,8 @@ int vfio_unregister_notifier(struct device *dev, struct 
notifier_block *nb)
return -EINVAL;
 
group = vfio_group_get_from_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   if (!group)
+   return -ENODEV;
 
ret = vfio_group_add_container_user(group);
if (ret)
-- 
2.9.3

Re: next: Commit 'mm: Prevent __alloc_pages_nodemask() RCU CPU stall ...' causing hang on sparc32 qemu

[Paul E. McKenney]

On Tue, Nov 29, 2016 at 08:32:51PM -0800, Guenter Roeck wrote:
> On 11/29/2016 05:28 PM, Paul E. McKenney wrote:
> >On Tue, Nov 29, 2016 at 01:23:08PM -0800, Guenter Roeck wrote:
> >>Hi Paul,
> >>
> >>most of my qemu tests for sparc32 targets started to fail in next-20161129.
> >>The problem is only seen in SMP builds; non-SMP builds are fine.
> >>Bisect points to commit 2d66cccd73436 ("mm: Prevent __alloc_pages_nodemask()
> >>RCU CPU stall warnings"); reverting that commit fixes the problem.
> >>
> >>Test scripts are available at:
> >>https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>Test results are at:
> >>https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>
> >>Bisect log is attached.
> >>
> >>Please let me know if there is anything I can do to help tracking down the
> >>problem.
> >
> >Apologies!!!  Does the patch below help?
> >
> No, sorry, it doesn't make a difference.

Interesting...  Could you please send me the build failure messages?

Thanx, Paul

> Guenter
> 
> > Thanx, Paul
> >
> >
> >
> >commit 97708e737e2a55fed4bdbc005bf05ea909df6b73
> >Author: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> >Date:   Tue Nov 29 11:06:05 2016 -0800
> >
> >rcu: Allow boot-time use of cond_resched_rcu_qs()
> >
> >The cond_resched_rcu_qs() macro is used to force RCU quiescent states 
> > into
> >long-running in-kernel loops.  However, some of these loops can execute
> >during early boot when interrupts are disabled, and during which time
> >it is therefore illegal to enter the scheduler.  This commit therefore
> >makes cond_resched_rcu_qs() be a no-op during early boot.
> >
> >Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> >
> >diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >index 525ca34603b7..b6944cc19a07 100644
> >--- a/include/linux/rcupdate.h
> >+++ b/include/linux/rcupdate.h
> >@@ -423,7 +423,7 @@ extern struct srcu_struct tasks_rcu_exit_srcu;
> >  */
> > #define cond_resched_rcu_qs() \
> > do { \
> >-if (!cond_resched()) \
> >+if (!is_idle_task(current) && !cond_resched()) \
> > rcu_note_voluntary_context_switch(current); \
> > } while (0)
> >
> >diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> >index 7232d199a81c..20f5990d 100644
> >--- a/include/linux/rcutiny.h
> >+++ b/include/linux/rcutiny.h
> >@@ -228,6 +228,7 @@ static inline void exit_rcu(void)
> > extern int rcu_scheduler_active __read_mostly;
> > void rcu_scheduler_starting(void);
> > #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >+#define rcu_scheduler_active false
> > static inline void rcu_scheduler_starting(void)
> > {
> > }
> >
> >
> 

Re: next: Commit 'mm: Prevent __alloc_pages_nodemask() RCU CPU stall ...' causing hang on sparc32 qemu

[Paul E. McKenney]

On Tue, Nov 29, 2016 at 08:32:51PM -0800, Guenter Roeck wrote:
> On 11/29/2016 05:28 PM, Paul E. McKenney wrote:
> >On Tue, Nov 29, 2016 at 01:23:08PM -0800, Guenter Roeck wrote:
> >>Hi Paul,
> >>
> >>most of my qemu tests for sparc32 targets started to fail in next-20161129.
> >>The problem is only seen in SMP builds; non-SMP builds are fine.
> >>Bisect points to commit 2d66cccd73436 ("mm: Prevent __alloc_pages_nodemask()
> >>RCU CPU stall warnings"); reverting that commit fixes the problem.
> >>
> >>Test scripts are available at:
> >>https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>Test results are at:
> >>https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>
> >>Bisect log is attached.
> >>
> >>Please let me know if there is anything I can do to help tracking down the
> >>problem.
> >
> >Apologies!!!  Does the patch below help?
> >
> No, sorry, it doesn't make a difference.

Interesting...  Could you please send me the build failure messages?

Thanx, Paul

> Guenter
> 
> > Thanx, Paul
> >
> >
> >
> >commit 97708e737e2a55fed4bdbc005bf05ea909df6b73
> >Author: Paul E. McKenney 
> >Date:   Tue Nov 29 11:06:05 2016 -0800
> >
> >rcu: Allow boot-time use of cond_resched_rcu_qs()
> >
> >The cond_resched_rcu_qs() macro is used to force RCU quiescent states 
> > into
> >long-running in-kernel loops.  However, some of these loops can execute
> >during early boot when interrupts are disabled, and during which time
> >it is therefore illegal to enter the scheduler.  This commit therefore
> >makes cond_resched_rcu_qs() be a no-op during early boot.
> >
> >Signed-off-by: Paul E. McKenney 
> >
> >diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >index 525ca34603b7..b6944cc19a07 100644
> >--- a/include/linux/rcupdate.h
> >+++ b/include/linux/rcupdate.h
> >@@ -423,7 +423,7 @@ extern struct srcu_struct tasks_rcu_exit_srcu;
> >  */
> > #define cond_resched_rcu_qs() \
> > do { \
> >-if (!cond_resched()) \
> >+if (!is_idle_task(current) && !cond_resched()) \
> > rcu_note_voluntary_context_switch(current); \
> > } while (0)
> >
> >diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> >index 7232d199a81c..20f5990d 100644
> >--- a/include/linux/rcutiny.h
> >+++ b/include/linux/rcutiny.h
> >@@ -228,6 +228,7 @@ static inline void exit_rcu(void)
> > extern int rcu_scheduler_active __read_mostly;
> > void rcu_scheduler_starting(void);
> > #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >+#define rcu_scheduler_active false
> > static inline void rcu_scheduler_starting(void)
> > {
> > }
> >
> >
> 

Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64

[Adam Borowski]

On Wed, Nov 30, 2016 at 10:32:09AM +0530, Yury Norov wrote:
> On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> > This series enables aarch64 with ilp32 mode, and as supporting work,
> > introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> > existing 32-bit architectures but disabled for new arches (so 64-bit
> > off_t is is used by new userspace).
> 
> Hi all,
> 
> Steve Ellcey submitted glibc patches for ILP32:
> https://www.sourceware.org/ml/libc-alpha/2016-11/msg01071.html
> It implicitly assumes that kernel clears top halves of registers for
> all syscalls in assembly entry. That patches are going to be taken.
> It it happens, we will have no choice on kernel side how to clear top
> halves anymore.

Since a while ago, there's a package "arch-test" in Debian that empirically
enumerates architectures executable by the running kernel (and loaded
binfmts), by trying small test programs for each.  The list of architectures
it knows does include arm64ilp32.

For most archs the test is just {write(1, "ok\n"); _exit(0);} unless there's
some difference from baseline that should be checked for, like dmb (ARMv7)
on armhf or mtvsrd (POWER8) on ppc64el.  I could scribble in the top half of
a register to test the delousing, but it's not like alternate versions of
the ABI are expected in the wild...


There's another issue: name.  A stalled request to add it to dpkg's cputable
(https://bugs.debian.org/824742) uses "arm64ilp32" and "arm64ilp32be" which
are unwieldy.  Even the discussion uses "ilp32" -- probably too generic. 
https://wiki.linaro.org/Platform/arm64-ilp32 mentions both.  I've heard
"a32" somewhere.  I have no stake here (I'm on the CC list as a x32 not arm
porter...), but if you want to choose a color for this bikeshed, the time
is now.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64

[Adam Borowski]

On Wed, Nov 30, 2016 at 10:32:09AM +0530, Yury Norov wrote:
> On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> > This series enables aarch64 with ilp32 mode, and as supporting work,
> > introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> > existing 32-bit architectures but disabled for new arches (so 64-bit
> > off_t is is used by new userspace).
> 
> Hi all,
> 
> Steve Ellcey submitted glibc patches for ILP32:
> https://www.sourceware.org/ml/libc-alpha/2016-11/msg01071.html
> It implicitly assumes that kernel clears top halves of registers for
> all syscalls in assembly entry. That patches are going to be taken.
> It it happens, we will have no choice on kernel side how to clear top
> halves anymore.

Since a while ago, there's a package "arch-test" in Debian that empirically
enumerates architectures executable by the running kernel (and loaded
binfmts), by trying small test programs for each.  The list of architectures
it knows does include arm64ilp32.

For most archs the test is just {write(1, "ok\n"); _exit(0);} unless there's
some difference from baseline that should be checked for, like dmb (ARMv7)
on armhf or mtvsrd (POWER8) on ppc64el.  I could scribble in the top half of
a register to test the delousing, but it's not like alternate versions of
the ABI are expected in the wild...


There's another issue: name.  A stalled request to add it to dpkg's cputable
(https://bugs.debian.org/824742) uses "arm64ilp32" and "arm64ilp32be" which
are unwieldy.  Even the discussion uses "ilp32" -- probably too generic. 
https://wiki.linaro.org/Platform/arm64-ilp32 mentions both.  I've heard
"a32" somewhere.  I have no stake here (I'm on the CC list as a x32 not arm
porter...), but if you want to choose a color for this bikeshed, the time
is now.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Re: [PATCH KERNEL] xen/events: use xen_vcpu_id mapping for EVTCHNOP_status

[Juergen Gross]

On 23/11/16 13:38, Vitaly Kuznetsov wrote:
> EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to
> compare it against xen_vcpu_id mapping, not the Linux cpu id.
> 
> Suggested-by: Radim Krcmar 
> Signed-off-by: Vitaly Kuznetsov 

Applied to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH KERNEL] xen/events: use xen_vcpu_id mapping for EVTCHNOP_status

[Juergen Gross]

On 23/11/16 13:38, Vitaly Kuznetsov wrote:
> EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to
> compare it against xen_vcpu_id mapping, not the Linux cpu id.
> 
> Suggested-by: Radim Krcmar 
> Signed-off-by: Vitaly Kuznetsov 

Applied to xen/tip.git for-linus-4.10


Juergen

Re: [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings

[Daniel Kurtz]

Hi YT,


On Fri, Nov 25, 2016 at 6:34 PM, YT Shen  wrote:
>
> There are some hardware settings changed, between MT8173 & MT2701:
> DISP_OVL address offset changed, color format definition changed.
> DISP_RDMA fifo size changed.
> DISP_COLOR offset changed.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.

Sorry, I have not had time to thoroughly review the new patch set, but
one quick comment:

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 22a33ee..cfaa760 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
>   struct drm_crtc_state *state);
>  };
>
> +struct mtk_ddp_comp_driver_data {
> +   unsigned int color_offset;
> +};
> +
>  struct mtk_ddp_comp {
> struct clk *clk;
> void __iomem *regs;
> @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> struct device *larb_dev;
> enum mtk_ddp_comp_id id;
> const struct mtk_ddp_comp_funcs *funcs;
> +   const struct mtk_ddp_comp_driver_data *data;

I want to avoid adding this generic pointer here to all mtk_ddp_comp,
since this is only used by the color component.
Instead, define color specific types:

struct mtk_disp_color_data {
   unsigned int offset;
};

struct mtk_disp_color {
   struct mtk_ddp_comp ddp_comp;
   const struct mtk_disp_color_data *data;
};

Then, add another comp_type check and fetch the dev data in
mtk_drm_probe()  or maybe mtk_ddp_comp_init().

-Dan

Re: [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings

[Daniel Kurtz]

Hi YT,


On Fri, Nov 25, 2016 at 6:34 PM, YT Shen  wrote:
>
> There are some hardware settings changed, between MT8173 & MT2701:
> DISP_OVL address offset changed, color format definition changed.
> DISP_RDMA fifo size changed.
> DISP_COLOR offset changed.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.

Sorry, I have not had time to thoroughly review the new patch set, but
one quick comment:

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 22a33ee..cfaa760 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
>   struct drm_crtc_state *state);
>  };
>
> +struct mtk_ddp_comp_driver_data {
> +   unsigned int color_offset;
> +};
> +
>  struct mtk_ddp_comp {
> struct clk *clk;
> void __iomem *regs;
> @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> struct device *larb_dev;
> enum mtk_ddp_comp_id id;
> const struct mtk_ddp_comp_funcs *funcs;
> +   const struct mtk_ddp_comp_driver_data *data;

I want to avoid adding this generic pointer here to all mtk_ddp_comp,
since this is only used by the color component.
Instead, define color specific types:

struct mtk_disp_color_data {
   unsigned int offset;
};

struct mtk_disp_color {
   struct mtk_ddp_comp ddp_comp;
   const struct mtk_disp_color_data *data;
};

Then, add another comp_type check and fetch the dev data in
mtk_drm_probe()  or maybe mtk_ddp_comp_init().

-Dan

Re: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer

[Nikita Yushchenko]

> But I think it is not necessary since the driver don't support jumbo frame.

Hardcoded 1522 raises two separate issues.

(1) When DSA is in use, frames processed by FEC chip contain DSA tag and
thus can be larger than hardcoded limit of 1522. This issue is not
FEC-specific, any driver that hardcodes maximum frame size to 1522 (many
do) will have this issue if used with DSA.

Clean solution for this must take into account that difference between
MTU and max frame size is no longer known at compile time. Actually this
is the case even without DSA, due to VLANs: max frame size is (MTU + 18)
without VLANs, but (MTU + 22) with VLANs. However currently drivers tend
to ignore this and hardcode 22.  With DSA, 22 is not enough, need to add
switch-specific tag size to that.

Not yet sure how to handle this. DSA-specific API to find out tag size
could be added, but generic solution should handle all cases of dynamic
difference between MTU and max frame size, not only DSA.


(2) There is some demand to use larger frames for optimization purposes.

FEC register fields that limit frame size are 14-bit, thus allowing
frames up to (4k-1). I'm about to prepare a larger patch:
- add ndo_change_mtu handler, allowing MTU up to (4k - overhead),
- set MAX_FL / TRUNC_FL based on configured MTU,
- if necessary, do buffer reallocation with larger buffers.

Is this suitable for upstreaming?
Is there any policy related to handling larger frames?

Re: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer

[Nikita Yushchenko]

> But I think it is not necessary since the driver don't support jumbo frame.

Hardcoded 1522 raises two separate issues.

(1) When DSA is in use, frames processed by FEC chip contain DSA tag and
thus can be larger than hardcoded limit of 1522. This issue is not
FEC-specific, any driver that hardcodes maximum frame size to 1522 (many
do) will have this issue if used with DSA.

Clean solution for this must take into account that difference between
MTU and max frame size is no longer known at compile time. Actually this
is the case even without DSA, due to VLANs: max frame size is (MTU + 18)
without VLANs, but (MTU + 22) with VLANs. However currently drivers tend
to ignore this and hardcode 22.  With DSA, 22 is not enough, need to add
switch-specific tag size to that.

Not yet sure how to handle this. DSA-specific API to find out tag size
could be added, but generic solution should handle all cases of dynamic
difference between MTU and max frame size, not only DSA.


(2) There is some demand to use larger frames for optimization purposes.

FEC register fields that limit frame size are 14-bit, thus allowing
frames up to (4k-1). I'm about to prepare a larger patch:
- add ndo_change_mtu handler, allowing MTU up to (4k - overhead),
- set MAX_FL / TRUNC_FL based on configured MTU,
- if necessary, do buffer reallocation with larger buffers.

Is this suitable for upstreaming?
Is there any policy related to handling larger frames?

RE: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit kernels.

[KY Srinivasan]

> -Original Message-
> From: Cathy Avery [mailto:cav...@redhat.com]
> Sent: Wednesday, November 23, 2016 5:47 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux-
> s...@vger.kernel.org
> Subject: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit
> kernels.
> 
> On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array
> requires. Also the buffer needs to be cleared or the upper bytes
> will contain junk.
> 
> Suggested-by: Vitaly Kuznetsov 
> Signed-off-by: Cathy Avery 

Thanks Cathy.

Reviewed-by: K. Y. Srinivasan 
> 
> ChangeLog:
> 
> v1) Initial submission
> v2) Remove memset and replace kmalloc with kzalloc.
> ---
>  drivers/scsi/storvsc_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 8ccfc9e..05526b7 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1495,9 +1495,9 @@ static int storvsc_queuecommand(struct Scsi_Host
> *host, struct scsi_cmnd *scmnd)
>   if (sg_count) {
>   if (sg_count > MAX_PAGE_BUFFER_COUNT) {
> 
> - payload_sz = (sg_count * sizeof(void *) +
> + payload_sz = (sg_count * sizeof(u64) +
> sizeof(struct vmbus_packet_mpb_array));
> - payload = kmalloc(payload_sz, GFP_ATOMIC);
> + payload = kzalloc(payload_sz, GFP_ATOMIC);
>   if (!payload)
>   return SCSI_MLQUEUE_DEVICE_BUSY;
>   }
> --
> 2.5.0

RE: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit kernels.

[KY Srinivasan]

> -Original Message-
> From: Cathy Avery [mailto:cav...@redhat.com]
> Sent: Wednesday, November 23, 2016 5:47 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux-
> s...@vger.kernel.org
> Subject: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit
> kernels.
> 
> On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array
> requires. Also the buffer needs to be cleared or the upper bytes
> will contain junk.
> 
> Suggested-by: Vitaly Kuznetsov 
> Signed-off-by: Cathy Avery 

Thanks Cathy.

Reviewed-by: K. Y. Srinivasan 
> 
> ChangeLog:
> 
> v1) Initial submission
> v2) Remove memset and replace kmalloc with kzalloc.
> ---
>  drivers/scsi/storvsc_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 8ccfc9e..05526b7 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1495,9 +1495,9 @@ static int storvsc_queuecommand(struct Scsi_Host
> *host, struct scsi_cmnd *scmnd)
>   if (sg_count) {
>   if (sg_count > MAX_PAGE_BUFFER_COUNT) {
> 
> - payload_sz = (sg_count * sizeof(void *) +
> + payload_sz = (sg_count * sizeof(u64) +
> sizeof(struct vmbus_packet_mpb_array));
> - payload = kmalloc(payload_sz, GFP_ATOMIC);
> + payload = kzalloc(payload_sz, GFP_ATOMIC);
>   if (!payload)
>   return SCSI_MLQUEUE_DEVICE_BUSY;
>   }
> --
> 2.5.0

Re: [PATCH v3 4/5] thermal: rockchip: optimize the conversion table

[Eduardo Valentin]

Hey,

On Mon, Nov 28, 2016 at 07:12:03PM +0800, Caesar Wang wrote:



> + num = abs(table->id[mid].code - table->id[mid + 1].code);
> + num *= temp - table->id[mid].temp;
> + denom = table->id[mid + 1].temp - table->id[mid].temp;


isn't the above 'mid + 1' off-by-one when mid ends being == table.length - 1?

You would be accessing table->id[table.length], which is wrong memory
access, no?

Re: [PATCH v3 4/5] thermal: rockchip: optimize the conversion table

[Eduardo Valentin]

Hey,

On Mon, Nov 28, 2016 at 07:12:03PM +0800, Caesar Wang wrote:



> + num = abs(table->id[mid].code - table->id[mid + 1].code);
> + num *= temp - table->id[mid].temp;
> + denom = table->id[mid + 1].temp - table->id[mid].temp;


isn't the above 'mid + 1' off-by-one when mid ends being == table.length - 1?

You would be accessing table->id[table.length], which is wrong memory
access, no?

Re: [PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case

[Eduardo Valentin]

Hello,

On Tue, Nov 29, 2016 at 09:59:28PM -0800, Brian Norris wrote:
> On Tue, Nov 29, 2016 at 09:02:42PM -0800, Eduardo Valentin wrote:
> > On Tue, Nov 29, 2016 at 01:57:45PM -0800, Brian Norris wrote:
> > > I was thinking while reviewing that the binary search serves more to
> > > complicate things than to help -- it's much harder to read (and validate
> > > that the loop termination logic is correct). And searching through a few
> > > dozen table entries doesn't really get much benefit from a O(n) ->
> > > O(log(n)) speed improvement.
> > 
> > true. but if in your code path you do several walks in the table just to
> > check if parameters are valid, given that you could simply decide if
> > they are valid or not with simpler if condition, then, still worth, no?
> > :-)
> 
> Yes, your suggestions seems like they would have made the code both (a
> little) more straightforward and efficient. But...
> 
> > > Anyway, I'm not sure if you were thinking along the same lines as me.
> > > 
> > 
> > Something like that, except I though of something even simpler:
> > +   if ((temp % table->step) != 0)
> > +   return -ERANGE;
> > 
> > If temp passes that check, then you go to the temp -> code conversion.
> 
> ...that check isn't valid as of patch 4, where Caesar adds handling for
> intermediate steps. We really never should have been strictly snapping
> to the 5C steps in the first place; intermediate values are OK.
> 
> So, we still need some kind of search to find the right step -- or
> closest bracketing range, to compute the interpolated value. We should
> only reject temperatures that are too high or too low for the ADC to
> represent.

Ok. got it. check small comment on patch 4 then.

> 
> 
> --- Side track ---
> 
> BTW, when we're considering rejecting temperatures here: shouldn't this
> be fed back to the upper layers more nicely? We're improving the error
> handling for this driver in this series, but it still leaves things
> behaving a little odd. When I tested, I can do:
> 
> ## set something obviously way too high
> echo 70 > trip_point_X_temp
> 
> and get a 0 (success) return code from the sysfs write() syscall, even
> though the rockchip driver rejected it with -ERANGE. Is there really no
> way to feed back thermal range limits of a sensor to the of-thermal
> framework?
> 

well, that is a bit strange to me. Are you sure you are returning the
-ERANGE? Because, my assumption is that the following of-thermal code
path would return the error code back to core:
 328 if (data->ops->set_trip_temp) {
 329 int ret;
 330 
 331 ret = data->ops->set_trip_temp(data->sensor_data, trip, 
temp);
 332 if (ret)
 333 return ret;
 334 }

And this part of thermal core would return it back to sysfs layer:
 757 ret = tz->ops->set_trip_temp(tz, trip, temperature);
 758 if (ret)
 759 return ret;

or am I missing something?

> Brian

Re: [LKP] [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c

[Fengguang Wu]

Hi Paul,

Attached is the new dmesg.

On Wed, Nov 30, 2016 at 05:39:50AM +0800, Ye Xiaolong wrote:

On 11/29, Paul E. McKenney wrote:

On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:

On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit:
>
> commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent 
__alloc_pages_nodemask() RCU CPU stall warnings")
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
>
> caused below changes:
>
[...]

> [8.953192] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3746
> [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0

I am observing similar BUG/backtrace even on ARM64 platform.


Does the (untested) patch below help?

Thanx, Paul


Hi, Paul

I applied your patch on top of 2d66ccc "mm:
Prevent__alloc_pages_nodemask() RCU CPU stall warnings"(e7c1db7 turns to
2d66ccc in rcu/next branch now), here is the comparison of 6 times
testing, seems the BUG persists.

b70fa84d2eeef5f6be25633a2b is the commit id of commit "rcu: Allow
boot-time useof cond_resched_rcu_qs()"

testcase/path_params/tbox_group/run: boot/1/vm-vp-1G

2d66cccd73436ac9  b70fa84d2eeef5f6be25633a2b
  --
 6:60%   6:6 
dmesg.BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c


The new dmesg looks like this:

[6.505611] Write protecting the kernel read-only data: 14336k
[6.507798] Freeing unused kernel memory: 544K (880001978000 - 
880001a0)
[6.515634] Freeing unused kernel memory: 240K (880001dc4000 - 
880001e0)
[6.524713] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3746
[6.527327] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: init
[6.528891] CPU: 1 PID: 1 Comm: init Not tainted 4.9.0-rc1-00048-gb70fa84 #1
[6.530604] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[6.533255]  c9197b48 81472609 8800296a 
02201200
[6.538069]  c9197b60 810a85a3 8800364bc080 
c9197bf0
[6.542821]  81190dce 8800296a 8800296a 
8800296a
[6.548618] Call Trace:
[6.550675]  [] dump_stack+0x63/0x8a
[6.554180]  [] ___might_sleep+0xd3/0x120
[6.556720]  [] __alloc_pages_nodemask+0x23e/0x300
[6.560427]  [] alloc_pages_current+0x95/0x140
[6.564063]  [] new_slab+0x3c0/0x5a0
[6.566516]  [] ___slab_alloc+0x3a0/0x4b0
[6.570114]  [] ? anon_vma_clone+0x63/0x1c0
[6.572672]  [] ? alloc_set_pte+0x4f2/0x610
[6.576273]  [] ? anon_vma_clone+0x63/0x1c0
[6.578824]  [] __slab_alloc+0x20/0x40
[6.582348]  [] kmem_cache_alloc+0x17f/0x1c0
[6.585971]  [] anon_vma_clone+0x63/0x1c0
[6.588487]  [] ? __split_vma+0x5c/0x1e0
[6.592159]  [] __split_vma+0xc4/0x1e0
[6.594746]  [] split_vma+0x24/0x30
[6.598248]  [] mprotect_fixup+0x21c/0x270
[6.601130]  [] do_mprotect_pkey+0x20c/0x300
[6.602739]  [] SyS_mprotect+0x13/0x20
[6.604328]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
SELinux:  Could not open policy file <= /etc/selinux/targeted/policy/policy.30: 
 No such file or directory
[6.609407] systemd[1]: RTC configured in localtime, applying delta of 480 
minutes to system time.
[6.637736] random: fast init done
[6.693275] ip_tables: (C) 2000-2006 Netfilter Core Team
...
[7.553423] NFS: Registering the id_resolver key type
[7.555204] Key type id_resolver registered
[7.557629] Key type id_legacy registered
[7.570901] scsi 1:0:0:0: Attached scsi generic sg0 type 5
[7.572947] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3746
[7.575717] in_atomic(): 1, irqs_disabled(): 0, pid: 251, name: modprobe
[7.577496] CPU: 1 PID: 251 Comm: modprobe Tainted: GW   
4.9.0-rc1-00048-gb70fa84 #1
[7.585286] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[7.593093]  c95e3b78 81472609 88003f33c900 
02000200
[7.597043]  c95e3b90 810a85a3 8800364bc080 
c95e3c20
[7.599790]  81190dce 88003f33c900 88003f33c900 
88003f33c900
[7.608630] Call Trace:
[7.609787]  [] dump_stack+0x63/0x8a
[7.611366]  [] ___might_sleep+0xd3/0x120
[7.614373]  [] __alloc_pages_nodemask+0x23e/0x300
[7.622141]  [] alloc_pages_current+0x95/0x140
[7.623754]  [] __get_free_pages+0xe/0x40
[7.625323]  [] __tlb_remove_page_size+0x53/0x90
[7.627086]  [] unmap_page_range+0x6cb/0x910
[7.628647]  [] ? release_pages+0x2fc/0x390
[7.630242]  [] unmap_single_vma+0x7d/0xe0
[7.631725]  [] 

Re: [PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case

[Eduardo Valentin]

Hello,

On Tue, Nov 29, 2016 at 09:59:28PM -0800, Brian Norris wrote:
> On Tue, Nov 29, 2016 at 09:02:42PM -0800, Eduardo Valentin wrote:
> > On Tue, Nov 29, 2016 at 01:57:45PM -0800, Brian Norris wrote:
> > > I was thinking while reviewing that the binary search serves more to
> > > complicate things than to help -- it's much harder to read (and validate
> > > that the loop termination logic is correct). And searching through a few
> > > dozen table entries doesn't really get much benefit from a O(n) ->
> > > O(log(n)) speed improvement.
> > 
> > true. but if in your code path you do several walks in the table just to
> > check if parameters are valid, given that you could simply decide if
> > they are valid or not with simpler if condition, then, still worth, no?
> > :-)
> 
> Yes, your suggestions seems like they would have made the code both (a
> little) more straightforward and efficient. But...
> 
> > > Anyway, I'm not sure if you were thinking along the same lines as me.
> > > 
> > 
> > Something like that, except I though of something even simpler:
> > +   if ((temp % table->step) != 0)
> > +   return -ERANGE;
> > 
> > If temp passes that check, then you go to the temp -> code conversion.
> 
> ...that check isn't valid as of patch 4, where Caesar adds handling for
> intermediate steps. We really never should have been strictly snapping
> to the 5C steps in the first place; intermediate values are OK.
> 
> So, we still need some kind of search to find the right step -- or
> closest bracketing range, to compute the interpolated value. We should
> only reject temperatures that are too high or too low for the ADC to
> represent.

Ok. got it. check small comment on patch 4 then.

> 
> 
> --- Side track ---
> 
> BTW, when we're considering rejecting temperatures here: shouldn't this
> be fed back to the upper layers more nicely? We're improving the error
> handling for this driver in this series, but it still leaves things
> behaving a little odd. When I tested, I can do:
> 
> ## set something obviously way too high
> echo 70 > trip_point_X_temp
> 
> and get a 0 (success) return code from the sysfs write() syscall, even
> though the rockchip driver rejected it with -ERANGE. Is there really no
> way to feed back thermal range limits of a sensor to the of-thermal
> framework?
> 

well, that is a bit strange to me. Are you sure you are returning the
-ERANGE? Because, my assumption is that the following of-thermal code
path would return the error code back to core:
 328 if (data->ops->set_trip_temp) {
 329 int ret;
 330 
 331 ret = data->ops->set_trip_temp(data->sensor_data, trip, 
temp);
 332 if (ret)
 333 return ret;
 334 }

And this part of thermal core would return it back to sysfs layer:
 757 ret = tz->ops->set_trip_temp(tz, trip, temperature);
 758 if (ret)
 759 return ret;

or am I missing something?

> Brian

Re: [LKP] [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c

[Fengguang Wu]

Hi Paul,

Attached is the new dmesg.

On Wed, Nov 30, 2016 at 05:39:50AM +0800, Ye Xiaolong wrote:

On 11/29, Paul E. McKenney wrote:

On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:

On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit:
>
> commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent 
__alloc_pages_nodemask() RCU CPU stall warnings")
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
>
> caused below changes:
>
[...]

> [8.953192] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3746
> [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0

I am observing similar BUG/backtrace even on ARM64 platform.


Does the (untested) patch below help?

Thanx, Paul


Hi, Paul

I applied your patch on top of 2d66ccc "mm:
Prevent__alloc_pages_nodemask() RCU CPU stall warnings"(e7c1db7 turns to
2d66ccc in rcu/next branch now), here is the comparison of 6 times
testing, seems the BUG persists.

b70fa84d2eeef5f6be25633a2b is the commit id of commit "rcu: Allow
boot-time useof cond_resched_rcu_qs()"

testcase/path_params/tbox_group/run: boot/1/vm-vp-1G

2d66cccd73436ac9  b70fa84d2eeef5f6be25633a2b
  --
 6:60%   6:6 
dmesg.BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c


The new dmesg looks like this:

[6.505611] Write protecting the kernel read-only data: 14336k
[6.507798] Freeing unused kernel memory: 544K (880001978000 - 
880001a0)
[6.515634] Freeing unused kernel memory: 240K (880001dc4000 - 
880001e0)
[6.524713] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3746
[6.527327] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: init
[6.528891] CPU: 1 PID: 1 Comm: init Not tainted 4.9.0-rc1-00048-gb70fa84 #1
[6.530604] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[6.533255]  c9197b48 81472609 8800296a 
02201200
[6.538069]  c9197b60 810a85a3 8800364bc080 
c9197bf0
[6.542821]  81190dce 8800296a 8800296a 
8800296a
[6.548618] Call Trace:
[6.550675]  [] dump_stack+0x63/0x8a
[6.554180]  [] ___might_sleep+0xd3/0x120
[6.556720]  [] __alloc_pages_nodemask+0x23e/0x300
[6.560427]  [] alloc_pages_current+0x95/0x140
[6.564063]  [] new_slab+0x3c0/0x5a0
[6.566516]  [] ___slab_alloc+0x3a0/0x4b0
[6.570114]  [] ? anon_vma_clone+0x63/0x1c0
[6.572672]  [] ? alloc_set_pte+0x4f2/0x610
[6.576273]  [] ? anon_vma_clone+0x63/0x1c0
[6.578824]  [] __slab_alloc+0x20/0x40
[6.582348]  [] kmem_cache_alloc+0x17f/0x1c0
[6.585971]  [] anon_vma_clone+0x63/0x1c0
[6.588487]  [] ? __split_vma+0x5c/0x1e0
[6.592159]  [] __split_vma+0xc4/0x1e0
[6.594746]  [] split_vma+0x24/0x30
[6.598248]  [] mprotect_fixup+0x21c/0x270
[6.601130]  [] do_mprotect_pkey+0x20c/0x300
[6.602739]  [] SyS_mprotect+0x13/0x20
[6.604328]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
SELinux:  Could not open policy file <= /etc/selinux/targeted/policy/policy.30: 
 No such file or directory
[6.609407] systemd[1]: RTC configured in localtime, applying delta of 480 
minutes to system time.
[6.637736] random: fast init done
[6.693275] ip_tables: (C) 2000-2006 Netfilter Core Team
...
[7.553423] NFS: Registering the id_resolver key type
[7.555204] Key type id_resolver registered
[7.557629] Key type id_legacy registered
[7.570901] scsi 1:0:0:0: Attached scsi generic sg0 type 5
[7.572947] BUG: sleeping function called from invalid context at 
mm/page_alloc.c:3746
[7.575717] in_atomic(): 1, irqs_disabled(): 0, pid: 251, name: modprobe
[7.577496] CPU: 1 PID: 251 Comm: modprobe Tainted: GW   
4.9.0-rc1-00048-gb70fa84 #1
[7.585286] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[7.593093]  c95e3b78 81472609 88003f33c900 
02000200
[7.597043]  c95e3b90 810a85a3 8800364bc080 
c95e3c20
[7.599790]  81190dce 88003f33c900 88003f33c900 
88003f33c900
[7.608630] Call Trace:
[7.609787]  [] dump_stack+0x63/0x8a
[7.611366]  [] ___might_sleep+0xd3/0x120
[7.614373]  [] __alloc_pages_nodemask+0x23e/0x300
[7.622141]  [] alloc_pages_current+0x95/0x140
[7.623754]  [] __get_free_pages+0xe/0x40
[7.625323]  [] __tlb_remove_page_size+0x53/0x90
[7.627086]  [] unmap_page_range+0x6cb/0x910
[7.628647]  [] ? release_pages+0x2fc/0x390
[7.630242]  [] unmap_single_vma+0x7d/0xe0
[7.631725]  [] unmap_vmas+0x51/0xa0
[

Re: bnx2 breaks Dell R815 BMC IPMI since 4.8

[Brice Goglin]

Le 30 novembre 2016 00:28:08 GMT+01:00, Gavin Shan  
a écrit :
>On Tue, Nov 29, 2016 at 07:57:51AM +0100, Brice Goglin wrote:
>>Hello
>>
>>My Dell PowerEdge R815 doesn't have IPMI anymore when I boot a 4.8
>>kernel, the BMC doesn't even ping anymore. Its Ethernet devices are 4
>of
>>those:
>>
>>01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
>Gigabit Ethernet (rev 20)
>>  DeviceName: Embedded NIC 1  
>>  Subsystem: Dell NetXtreme II BCM5709 Gigabit Ethernet
>>  Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>Stepping- SERR- FastB2B- DisINTx+
>>  Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>SERR- >  Latency: 0, Cache Line Size: 64 bytes
>>  Interrupt: pin A routed to IRQ 42
>>  Region 0: Memory at e600 (64-bit, non-prefetchable) [size=32M]
>>  Capabilities: 
>>  Kernel driver in use: bnx2
>>  Kernel modules: bnx2
>>
>>The only change in bnx2 between 4.7 and 4.8 appears to be this one:
>>
>>commit 3e1be7ad2d38c6bd6aeef96df9bd0a7822f4e51c
>>Author: Baoquan He 
>>Date:   Fri Sep 9 22:43:12 2016 +0800
>>
>>bnx2: Reset device during driver initialization
>>
>>Could you patch actually break the BMC? What do I need to further
>debug
>>this issue?
>>
>
>Brice, could you please confirm NCSI is enabled on BMC? It seems NCSI
>AEN pakets aren't handled by NCSI stack on BMC side when resetting NIC
>on host side. Those AEN packets usually help to reconfigure the
>(active)
>NCSI channel and bring it back to service after the reset.


I don't remember ever seeing the name NCSI in those Dell BMC configs. Any other 
word to look for?

By the way, the bug is gone in 4.8.11.

Brice

Re: bnx2 breaks Dell R815 BMC IPMI since 4.8

[Brice Goglin]

Le 30 novembre 2016 00:28:08 GMT+01:00, Gavin Shan  
a écrit :
>On Tue, Nov 29, 2016 at 07:57:51AM +0100, Brice Goglin wrote:
>>Hello
>>
>>My Dell PowerEdge R815 doesn't have IPMI anymore when I boot a 4.8
>>kernel, the BMC doesn't even ping anymore. Its Ethernet devices are 4
>of
>>those:
>>
>>01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
>Gigabit Ethernet (rev 20)
>>  DeviceName: Embedded NIC 1  
>>  Subsystem: Dell NetXtreme II BCM5709 Gigabit Ethernet
>>  Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>Stepping- SERR- FastB2B- DisINTx+
>>  Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>SERR- >  Latency: 0, Cache Line Size: 64 bytes
>>  Interrupt: pin A routed to IRQ 42
>>  Region 0: Memory at e600 (64-bit, non-prefetchable) [size=32M]
>>  Capabilities: 
>>  Kernel driver in use: bnx2
>>  Kernel modules: bnx2
>>
>>The only change in bnx2 between 4.7 and 4.8 appears to be this one:
>>
>>commit 3e1be7ad2d38c6bd6aeef96df9bd0a7822f4e51c
>>Author: Baoquan He 
>>Date:   Fri Sep 9 22:43:12 2016 +0800
>>
>>bnx2: Reset device during driver initialization
>>
>>Could you patch actually break the BMC? What do I need to further
>debug
>>this issue?
>>
>
>Brice, could you please confirm NCSI is enabled on BMC? It seems NCSI
>AEN pakets aren't handled by NCSI stack on BMC side when resetting NIC
>on host side. Those AEN packets usually help to reconfigure the
>(active)
>NCSI channel and bring it back to service after the reset.


I don't remember ever seeing the name NCSI in those Dell BMC configs. Any other 
word to look for?

By the way, the bug is gone in 4.8.11.

Brice

[PATCH] serial: 8250_mid fix calltrace when hotplug 8250 serial controller

[Song liwei]

From: Liwei Song 

Fix the following Calltrace:
[   77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069 
dma_async_device_unregister+0xe2/0xf0
[   77.775058] dma_async_device_unregister called while 1 clients hold a 
reference
[   77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[   77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS 
HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[   77.840396]   c90008adbc80 81403456 
c90008adbcd0
[   77.848245]   c90008adbcc0 8105e2e1 
042d08adbf20
[   77.855934]  88046a861c18 88046a85c420 820d4200 
88046ae92318
[   77.863601] Call Trace:
[   77.871113]  [] dump_stack+0x4f/0x69
[   77.878655]  [] __warn+0xd1/0xf0
[   77.886102]  [] warn_slowpath_fmt+0x4f/0x60
[   77.893508]  [] ? find_next_bit+0x19/0x20
[   77.900730]  [] ? dma_channel_rebalance+0x23e/0x270
[   77.907814]  [] dma_async_device_unregister+0xe2/0xf0
[   77.914992]  [] hsu_dma_remove+0x1a/0x60
[   77.921977]  [] dnv_exit+0x1c/0x20
[   77.928752]  [] mid8250_remove+0x26/0x40
[   77.935607]  [] pci_device_remove+0x39/0xc0
[   77.942292]  [] __device_release_driver+0x9a/0x140
[   77.948836]  [] device_release_driver+0x23/0x30
[   77.955364]  [] pci_stop_bus_device+0x8c/0xa0
[   77.961769]  [] 
pci_stop_and_remove_bus_device_locked+0x1a/0x30
[   77.968113]  [] remove_store+0x5e/0x70
[   77.974267]  [] dev_attr_store+0x18/0x30
[   77.980243]  [] sysfs_kf_write+0x3a/0x50
[   77.986180]  [] kernfs_fop_write+0x10b/0x190
[   77.992118]  [] __vfs_write+0x18/0x40
[   77.998032]  [] vfs_write+0xae/0x190
[   78.003747]  [] SyS_write+0x46/0xb0
[   78.009234]  [] entry_SYSCALL_64_fastpath+0x13/0x8f
[   78.014809] ---[ end trace 0c36dd73b7408eb2 ]---

This happens when the 8250 serial controller is hotplugged as follows:
echo 1 > /sys/bus/pci/devices/:00:1a.0/remove

This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).

To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.

Signed-off-by: Liwei Song 
---
 drivers/tty/serial/8250/8250_mid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mid.c 
b/drivers/tty/serial/8250/8250_mid.c
index 39c2324..ac013edf 100644
--- a/drivers/tty/serial/8250/8250_mid.c
+++ b/drivers/tty/serial/8250/8250_mid.c
@@ -303,10 +303,10 @@ static void mid8250_remove(struct pci_dev *pdev)
 {
struct mid8250 *mid = pci_get_drvdata(pdev);
 
+   serial8250_unregister_port(mid->line);
+
if (mid->board->exit)
mid->board->exit(mid);
-
-   serial8250_unregister_port(mid->line);
 }
 
 static const struct mid8250_board pnw_board = {
-- 
2.9.3

[PATCH] serial: 8250_mid fix calltrace when hotplug 8250 serial controller

[Song liwei]

From: Liwei Song 

Fix the following Calltrace:
[   77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069 
dma_async_device_unregister+0xe2/0xf0
[   77.775058] dma_async_device_unregister called while 1 clients hold a 
reference
[   77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[   77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS 
HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[   77.840396]   c90008adbc80 81403456 
c90008adbcd0
[   77.848245]   c90008adbcc0 8105e2e1 
042d08adbf20
[   77.855934]  88046a861c18 88046a85c420 820d4200 
88046ae92318
[   77.863601] Call Trace:
[   77.871113]  [] dump_stack+0x4f/0x69
[   77.878655]  [] __warn+0xd1/0xf0
[   77.886102]  [] warn_slowpath_fmt+0x4f/0x60
[   77.893508]  [] ? find_next_bit+0x19/0x20
[   77.900730]  [] ? dma_channel_rebalance+0x23e/0x270
[   77.907814]  [] dma_async_device_unregister+0xe2/0xf0
[   77.914992]  [] hsu_dma_remove+0x1a/0x60
[   77.921977]  [] dnv_exit+0x1c/0x20
[   77.928752]  [] mid8250_remove+0x26/0x40
[   77.935607]  [] pci_device_remove+0x39/0xc0
[   77.942292]  [] __device_release_driver+0x9a/0x140
[   77.948836]  [] device_release_driver+0x23/0x30
[   77.955364]  [] pci_stop_bus_device+0x8c/0xa0
[   77.961769]  [] 
pci_stop_and_remove_bus_device_locked+0x1a/0x30
[   77.968113]  [] remove_store+0x5e/0x70
[   77.974267]  [] dev_attr_store+0x18/0x30
[   77.980243]  [] sysfs_kf_write+0x3a/0x50
[   77.986180]  [] kernfs_fop_write+0x10b/0x190
[   77.992118]  [] __vfs_write+0x18/0x40
[   77.998032]  [] vfs_write+0xae/0x190
[   78.003747]  [] SyS_write+0x46/0xb0
[   78.009234]  [] entry_SYSCALL_64_fastpath+0x13/0x8f
[   78.014809] ---[ end trace 0c36dd73b7408eb2 ]---

This happens when the 8250 serial controller is hotplugged as follows:
echo 1 > /sys/bus/pci/devices/:00:1a.0/remove

This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).

To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.

Signed-off-by: Liwei Song 
---
 drivers/tty/serial/8250/8250_mid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mid.c 
b/drivers/tty/serial/8250/8250_mid.c
index 39c2324..ac013edf 100644
--- a/drivers/tty/serial/8250/8250_mid.c
+++ b/drivers/tty/serial/8250/8250_mid.c
@@ -303,10 +303,10 @@ static void mid8250_remove(struct pci_dev *pdev)
 {
struct mid8250 *mid = pci_get_drvdata(pdev);
 
+   serial8250_unregister_port(mid->line);
+
if (mid->board->exit)
mid->board->exit(mid);
-
-   serial8250_unregister_port(mid->line);
 }
 
 static const struct mid8250_board pnw_board = {
-- 
2.9.3

Re: [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

[Ingo Molnar]

* Alex Thorlton  wrote:

> It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
> case.  This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
> E820_X_MAX is always at least slightly larger than E820MAX.
> 
> The real motivation behind this is actually to prevent some issues in
> the Xen kernel, where the XENMEM_machine_memory_map hypercall can
> produce an e820 map larger than 128 entries, even on systems where the
> original e820 table was quite a bit smaller than that, depending on how
> many IOAPICs are installed on the system.
> 
> Signed-off-by: Alex Thorlton 
> Suggested-by: Ingo Molnar 
> Cc: Russ Anderson 
> Cc: David Vrabel 
> Cc: Ingo Molnar 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: "H. Peter Anvin" 
> Cc: Denys Vlasenko 
> Cc: Boris Ostrovsky 
> Cc: x...@kernel.org
> Cc: xen-de...@lists.xenproject.org
> ---
>  arch/x86/include/asm/e820.h | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h
> index 476b574..aa00d33 100644
> --- a/arch/x86/include/asm/e820.h
> +++ b/arch/x86/include/asm/e820.h
> @@ -1,13 +1,15 @@
>  #ifndef _ASM_X86_E820_H
>  #define _ASM_X86_E820_H
>  
> -#ifdef CONFIG_EFI
> +/*
> + * We need to make sure that E820_X_MAX is defined
> + * before we include uapi/asm/e820.h
> + */
>  #include 
>  #define E820_X_MAX (E820MAX + 3 * MAX_NUMNODES)

What we need an explanation for in the comment is what does this stand for 
(what 
does the 'X' mean?), and what is the magic 3*MAX_NUMNODES about?

Thanks,

Ingo

Re: [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

[Ingo Molnar]

* Alex Thorlton  wrote:

> It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
> case.  This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
> E820_X_MAX is always at least slightly larger than E820MAX.
> 
> The real motivation behind this is actually to prevent some issues in
> the Xen kernel, where the XENMEM_machine_memory_map hypercall can
> produce an e820 map larger than 128 entries, even on systems where the
> original e820 table was quite a bit smaller than that, depending on how
> many IOAPICs are installed on the system.
> 
> Signed-off-by: Alex Thorlton 
> Suggested-by: Ingo Molnar 
> Cc: Russ Anderson 
> Cc: David Vrabel 
> Cc: Ingo Molnar 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: "H. Peter Anvin" 
> Cc: Denys Vlasenko 
> Cc: Boris Ostrovsky 
> Cc: x...@kernel.org
> Cc: xen-de...@lists.xenproject.org
> ---
>  arch/x86/include/asm/e820.h | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h
> index 476b574..aa00d33 100644
> --- a/arch/x86/include/asm/e820.h
> +++ b/arch/x86/include/asm/e820.h
> @@ -1,13 +1,15 @@
>  #ifndef _ASM_X86_E820_H
>  #define _ASM_X86_E820_H
>  
> -#ifdef CONFIG_EFI
> +/*
> + * We need to make sure that E820_X_MAX is defined
> + * before we include uapi/asm/e820.h
> + */
>  #include 
>  #define E820_X_MAX (E820MAX + 3 * MAX_NUMNODES)

What we need an explanation for in the comment is what does this stand for 
(what 
does the 'X' mean?), and what is the magic 3*MAX_NUMNODES about?

Thanks,

Ingo

Re: [PATCH 17/39] mtd: nand: denali: support HW_ECC_FIXUP capability

[Masahiro Yamada]

Hi Boris,


2016-11-28 1:09 GMT+09:00 Boris Brezillon :
_bitflips);
>
> Okay, so you currently have two ways of handling ECC errors. What if a
> new revision introduces yet another way to do it?
>
> How about making denali_caps a structure where you have one (or several)
> function pointers to implement operations differently depending on the
> IP revision?
>
> struct denali_caps {
> u32 feature_flags; /* If needed. */
> bool (*handle_ecc)(...);
> ...
> };
>

I think a problem is the difference of function arguments:

static bool denali_hw_ecc_fixup(struct denali_nand_info *denali,
unsigned int *max_bitflips)

 vs

static bool denali_sw_ecc_fixup(struct denali_nand_info *denali, u8 *buf,
u32 irq_status, unsigned int *max_bitflips)


I do not want to pass redundant arguments,
which are used for one, but not used for the other.


We do not need to think about the situation that may not happen.
If happens, we can refactor the code any time.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 17/39] mtd: nand: denali: support HW_ECC_FIXUP capability

[Masahiro Yamada]

Hi Boris,


2016-11-28 1:09 GMT+09:00 Boris Brezillon :
_bitflips);
>
> Okay, so you currently have two ways of handling ECC errors. What if a
> new revision introduces yet another way to do it?
>
> How about making denali_caps a structure where you have one (or several)
> function pointers to implement operations differently depending on the
> IP revision?
>
> struct denali_caps {
> u32 feature_flags; /* If needed. */
> bool (*handle_ecc)(...);
> ...
> };
>

I think a problem is the difference of function arguments:

static bool denali_hw_ecc_fixup(struct denali_nand_info *denali,
unsigned int *max_bitflips)

 vs

static bool denali_sw_ecc_fixup(struct denali_nand_info *denali, u8 *buf,
u32 irq_status, unsigned int *max_bitflips)


I do not want to pass redundant arguments,
which are used for one, but not used for the other.


We do not need to think about the situation that may not happen.
If happens, we can refactor the code any time.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 20/39] mtd: nand: denali_dt: enable HW_ECC_FIXUP capability for DT platform

[Masahiro Yamada]

Hi Boris,

2016-11-28 1:14 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:06:06 +0900
> Masahiro Yamada  wrote:
>
>> The denali_dt.c was split out by Altera for the SOCFPGA port.  The
>> Denali IP on SOCFPGA incorporates the hardware ECC fixup feature.
>> Newer versions are very likely to support it.  So, it should be OK
>> to set DENALI_CAPS_HW_ECC_FIXUP for all DT platforms.
>
> Seems like a bad idea. What's the problem with setting this flag in the
> data->caps definition of each revision?

No problem.

I will follow your suggestion in v2.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 20/39] mtd: nand: denali_dt: enable HW_ECC_FIXUP capability for DT platform

[Masahiro Yamada]

Hi Boris,

2016-11-28 1:14 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:06:06 +0900
> Masahiro Yamada  wrote:
>
>> The denali_dt.c was split out by Altera for the SOCFPGA port.  The
>> Denali IP on SOCFPGA incorporates the hardware ECC fixup feature.
>> Newer versions are very likely to support it.  So, it should be OK
>> to set DENALI_CAPS_HW_ECC_FIXUP for all DT platforms.
>
> Seems like a bad idea. What's the problem with setting this flag in the
> data->caps definition of each revision?

No problem.

I will follow your suggestion in v2.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

[Joonyoung Shim]

Hi Viresh,

On 11/30/2016 12:59 PM, Viresh Kumar wrote:
> From: Stephen Boyd 
> 
> Joonyoung Shim reported an interesting problem on his ARM octa-core
> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
> was failing for a struct device for which dev_pm_opp_set_regulator() is
> called earlier.
> 
> This happened because an earlier call to
> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
> removed all the entries from opp_table->dev_list apart from the last CPU
> device in the cpumask of CPUs sharing the OPP.
> 
> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
> routines get CPU device for the first CPU in the cpumask. And so the OPP
> core failed to find the OPP table for the struct device.
> 
> In order to fix that up properly, we need to revisit APIs like
> dev_pm_opp_set_regulator() and make them talk in terms of cookies
> provided by the OPP core. But such a solution will be hard to backport
> to stable kernels.
> 
> This patch attempts to fix this problem by returning a pointer to the
> opp_table from dev_pm_opp_set_regulator() and using that as the
> parameter to dev_pm_opp_put_regulator(). This ensures that the
> dev_pm_opp_put_regulator() doesn't fail to find the opp table.
> 
> Note that similar design problem also exists with other
> dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
> so we don't need to update them for now.
> 
> [Viresh]: Written commit log, minor improvements in the patch and tested
> on exynos 5250.
> 
> Cc: # v4.4+ 
> Reported-by: Joonyoung Shim 
> Signed-off-by: Stephen Boyd 
> Signed-off-by: Viresh Kumar 
> ---
> V3->V4:
> - Completely different approach, suggested earlier by Stephen.
> - Can be merged safely now as both /me and Stephen agree to this one.
> 
> @Joonyoung: Can you please test this last patch please ?
> 

Just system suspend/resume is working but i was missing below test case
that you inform when i test for prior patches on my Odroid-XU3 board.

- offline CPU 4
- suspend the system

With this test case, now all patches posted have the problem that is
failed to get clk: -2.

If all CPUs are online, cpufreq_driver->init(policy) is called by
cpufreq_online() only for CPU0 and CPU4 during system resume but it is
called for CPU5, CPU6 and CPU7 during system resume after CPU4 is
offline, and causes error.

Please refer below logs.

# echo 0 > /sys/devices/system/cpu/cpu4/online 
[  145.438931] IRQ54 no longer affine to CPU4
[  145.439931] CPU4: shutdown
#
#
# rtcwake -m mem -s 3
wakeup from "mem" at Mon Apr  9 11:04:19 2001
[  148.708773] PM: Syncing filesystems ... done.
[  148.718591] Freezing user space processes ... (elapsed 0.005 seconds) done.
[  148.727749] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) 
done.
[  148.753406] wake enabled for irq 135
[  148.754006] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
[  148.844402] PM: suspend of devices complete after 100.196 msecs
[  148.869158] PM: late suspend of devices complete after 19.793 msecs
[  148.891948] PM: noirq suspend of devices complete after 17.803 msecs
[  148.897067] Disabling non-boot CPUs ...
[  148.920201] IRQ51 no longer affine to CPU1
[  148.921414] CPU1: shutdown
[  148.990114] IRQ52 no longer affine to CPU2
[  148.991158] CPU2: shutdown
[  149.049416] IRQ53 no longer affine to CPU3
[  149.050477] CPU3: shutdown
[  149.114297] IRQ55 no longer affine to CPU5
[  149.115318] CPU5: shutdown
[  149.184539] IRQ56 no longer affine to CPU6
[  149.185421] CPU6: shutdown
[  149.257561] IRQ57 no longer affine to CPU7
[  149.258458] CPU7: shutdown
exynos_suspend_enter: suspending the system...
exynos_suspend_enter: wakeup masks: fffd,ffef
UART[f702]: ULCON=0003, UCON=f3c5, UFCON=0131, UBRDIV=001b
[  149.295339] Enabling non-boot CPUs ...
[  149.314454] CPU1 is up
[  149.329717] CPU2 is up
[  149.350140] CPU3 is up
[  149.370365] cpu cpu5: cpufreq_init: failed to get clk: -2
[  149.374803] IRQ55 no longer affine to CPU5
[  149.375126] CPU5: shutdown
[  149.399737] Error taking CPU5 up: -2
[  149.425424] cpu cpu6: cpufreq_init: failed to get clk: -2
[  149.429886] IRQ56 no longer affine to CPU6
[  149.430242] CPU6: shutdown
[  149.454745] Error taking CPU6 up: -2
[  149.480397] cpu cpu7: cpufreq_init: failed to get clk: -2
[  149.484869] IRQ57 no longer affine to CPU7
[  149.485186] CPU7: shutdown
[  149.509718] Error taking CPU7 up: -2
[  149.512392] s3c-i2c 12c6.i2c: slave address 0x00
[  149.516787] s3c-i2c 12c6.i2c: bus frequency set to 65 KHz
[  149.522554] s3c-i2c 12c8.i2c: slave address 0x00
[  149.527461] s3c-i2c 12c8.i2c: bus frequency set to 65 KHz
[  149.535818] PM: noirq resume of devices complete after 23.970 msecs
[  149.543853] PM: early resume of devices complete after 3.020 msecs
[  149.571356] s3c2410-wdt 101d.watchdog: watchdog 

Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

[Joonyoung Shim]

Hi Viresh,

On 11/30/2016 12:59 PM, Viresh Kumar wrote:
> From: Stephen Boyd 
> 
> Joonyoung Shim reported an interesting problem on his ARM octa-core
> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
> was failing for a struct device for which dev_pm_opp_set_regulator() is
> called earlier.
> 
> This happened because an earlier call to
> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
> removed all the entries from opp_table->dev_list apart from the last CPU
> device in the cpumask of CPUs sharing the OPP.
> 
> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
> routines get CPU device for the first CPU in the cpumask. And so the OPP
> core failed to find the OPP table for the struct device.
> 
> In order to fix that up properly, we need to revisit APIs like
> dev_pm_opp_set_regulator() and make them talk in terms of cookies
> provided by the OPP core. But such a solution will be hard to backport
> to stable kernels.
> 
> This patch attempts to fix this problem by returning a pointer to the
> opp_table from dev_pm_opp_set_regulator() and using that as the
> parameter to dev_pm_opp_put_regulator(). This ensures that the
> dev_pm_opp_put_regulator() doesn't fail to find the opp table.
> 
> Note that similar design problem also exists with other
> dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
> so we don't need to update them for now.
> 
> [Viresh]: Written commit log, minor improvements in the patch and tested
> on exynos 5250.
> 
> Cc: # v4.4+ 
> Reported-by: Joonyoung Shim 
> Signed-off-by: Stephen Boyd 
> Signed-off-by: Viresh Kumar 
> ---
> V3->V4:
> - Completely different approach, suggested earlier by Stephen.
> - Can be merged safely now as both /me and Stephen agree to this one.
> 
> @Joonyoung: Can you please test this last patch please ?
> 

Just system suspend/resume is working but i was missing below test case
that you inform when i test for prior patches on my Odroid-XU3 board.

- offline CPU 4
- suspend the system

With this test case, now all patches posted have the problem that is
failed to get clk: -2.

If all CPUs are online, cpufreq_driver->init(policy) is called by
cpufreq_online() only for CPU0 and CPU4 during system resume but it is
called for CPU5, CPU6 and CPU7 during system resume after CPU4 is
offline, and causes error.

Please refer below logs.

# echo 0 > /sys/devices/system/cpu/cpu4/online 
[  145.438931] IRQ54 no longer affine to CPU4
[  145.439931] CPU4: shutdown
#
#
# rtcwake -m mem -s 3
wakeup from "mem" at Mon Apr  9 11:04:19 2001
[  148.708773] PM: Syncing filesystems ... done.
[  148.718591] Freezing user space processes ... (elapsed 0.005 seconds) done.
[  148.727749] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) 
done.
[  148.753406] wake enabled for irq 135
[  148.754006] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
[  148.844402] PM: suspend of devices complete after 100.196 msecs
[  148.869158] PM: late suspend of devices complete after 19.793 msecs
[  148.891948] PM: noirq suspend of devices complete after 17.803 msecs
[  148.897067] Disabling non-boot CPUs ...
[  148.920201] IRQ51 no longer affine to CPU1
[  148.921414] CPU1: shutdown
[  148.990114] IRQ52 no longer affine to CPU2
[  148.991158] CPU2: shutdown
[  149.049416] IRQ53 no longer affine to CPU3
[  149.050477] CPU3: shutdown
[  149.114297] IRQ55 no longer affine to CPU5
[  149.115318] CPU5: shutdown
[  149.184539] IRQ56 no longer affine to CPU6
[  149.185421] CPU6: shutdown
[  149.257561] IRQ57 no longer affine to CPU7
[  149.258458] CPU7: shutdown
exynos_suspend_enter: suspending the system...
exynos_suspend_enter: wakeup masks: fffd,ffef
UART[f702]: ULCON=0003, UCON=f3c5, UFCON=0131, UBRDIV=001b
[  149.295339] Enabling non-boot CPUs ...
[  149.314454] CPU1 is up
[  149.329717] CPU2 is up
[  149.350140] CPU3 is up
[  149.370365] cpu cpu5: cpufreq_init: failed to get clk: -2
[  149.374803] IRQ55 no longer affine to CPU5
[  149.375126] CPU5: shutdown
[  149.399737] Error taking CPU5 up: -2
[  149.425424] cpu cpu6: cpufreq_init: failed to get clk: -2
[  149.429886] IRQ56 no longer affine to CPU6
[  149.430242] CPU6: shutdown
[  149.454745] Error taking CPU6 up: -2
[  149.480397] cpu cpu7: cpufreq_init: failed to get clk: -2
[  149.484869] IRQ57 no longer affine to CPU7
[  149.485186] CPU7: shutdown
[  149.509718] Error taking CPU7 up: -2
[  149.512392] s3c-i2c 12c6.i2c: slave address 0x00
[  149.516787] s3c-i2c 12c6.i2c: bus frequency set to 65 KHz
[  149.522554] s3c-i2c 12c8.i2c: slave address 0x00
[  149.527461] s3c-i2c 12c8.i2c: bus frequency set to 65 KHz
[  149.535818] PM: noirq resume of devices complete after 23.970 msecs
[  149.543853] PM: early resume of devices complete after 3.020 msecs
[  149.571356] s3c2410-wdt 101d.watchdog: watchdog disabled
[  149.575811] usb usb1: root hub lost power or was reset
[  149.641026] usb usb2: root hub lost power or was 

RE: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit kernels.

[KY Srinivasan]

> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, November 29, 2016 8:58 AM
> To: Cathy Avery 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; linux-s...@vger.kernel.org
> Subject: Re: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32
> bit kernels.
> 
> > "Cathy" == Cathy Avery  writes:
> 
> Cathy> On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array
> Cathy> requires. Also the buffer needs to be cleared or the upper bytes
> Cathy> will contain junk.
> 
> K.Y.: Please review!

Done.

K. Y
> 
> --
> Martin K. PetersenOracle Linux Engineering

RE: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit kernels.

[KY Srinivasan]

> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, November 29, 2016 8:58 AM
> To: Cathy Avery 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; linux-s...@vger.kernel.org
> Subject: Re: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32
> bit kernels.
> 
> > "Cathy" == Cathy Avery  writes:
> 
> Cathy> On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array
> Cathy> requires. Also the buffer needs to be cleared or the upper bytes
> Cathy> will contain junk.
> 
> K.Y.: Please review!

Done.

K. Y
> 
> --
> Martin K. PetersenOracle Linux Engineering

Re: [PATCH 18/39] mtd: nand: denali: move denali_read_page_raw() above denali_read_page()

[Masahiro Yamada]

Hi Boris,

2016-11-28 1:10 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:06:04 +0900
> Masahiro Yamada  wrote:
>
>> This will be needed in the next commit to call denali_read_page_raw()
>> from denali_read_page().
>
> Please squash this change into patch 19. It's clearly useless to
> dissociate them.
>

I will.

But as I mentioned in the reply to 19/39,
I am thinking that another solution may be possible.

In that case, both 18/39 and 19/39 will be unnecessary.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 18/39] mtd: nand: denali: move denali_read_page_raw() above denali_read_page()

[Masahiro Yamada]

Hi Boris,

2016-11-28 1:10 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:06:04 +0900
> Masahiro Yamada  wrote:
>
>> This will be needed in the next commit to call denali_read_page_raw()
>> from denali_read_page().
>
> Please squash this change into patch 19. It's clearly useless to
> dissociate them.
>

I will.

But as I mentioned in the reply to 19/39,
I am thinking that another solution may be possible.

In that case, both 18/39 and 19/39 will be unnecessary.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 28/39] mtd: nand: denali: move multi NAND fixup code to a helper function

[Masahiro Yamada]

Hi Boris,


2016-11-28 1:24 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:06:14 +0900
> Masahiro Yamada  wrote:
>
>> Collect multi NAND fixups into a helper function instead of
>> scattering them in denali_init().
>
> Can you tell me more about this multi-NAND feature?
> The core is already able to detect multi-die NAND chips in a generic
> way,

This is not the case.

> but I fear this is something else, like "put two 8-bits chips on a
> 16bits bus to emulate a single 16bits chip".

Yes, it is.

(I have never used this controller like that.
But, I am pretty sure it is
from the code and the
Denali's User Guide mentions such usage.)


Just in case, I will clearly rephrase the comment block like follows in v2:

/*
 * Support for multi device:
 * When the IP configuration is x16 capable and two x8 chips are
 * connected in parallel, DEVICES_CONNECTED should be set to 2.
 * In this case, the core framework knows nothing about this fact,
 * so we should tell it the _logical_ pagesize and anything necessary.
 */




> If that's a case, and this feature is actually used, then it's a bad
> idea IMHO.
> For example, how do you handle the case where one block is bad on a
> chip but not on the other? And I fear this is not the only problem
> with this approach :-/.

As you expect, if one block is bad,
the correspond block on the other chip can not be used.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 28/39] mtd: nand: denali: move multi NAND fixup code to a helper function

[Masahiro Yamada]

Hi Boris,


2016-11-28 1:24 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:06:14 +0900
> Masahiro Yamada  wrote:
>
>> Collect multi NAND fixups into a helper function instead of
>> scattering them in denali_init().
>
> Can you tell me more about this multi-NAND feature?
> The core is already able to detect multi-die NAND chips in a generic
> way,

This is not the case.

> but I fear this is something else, like "put two 8-bits chips on a
> 16bits bus to emulate a single 16bits chip".

Yes, it is.

(I have never used this controller like that.
But, I am pretty sure it is
from the code and the
Denali's User Guide mentions such usage.)


Just in case, I will clearly rephrase the comment block like follows in v2:

/*
 * Support for multi device:
 * When the IP configuration is x16 capable and two x8 chips are
 * connected in parallel, DEVICES_CONNECTED should be set to 2.
 * In this case, the core framework knows nothing about this fact,
 * so we should tell it the _logical_ pagesize and anything necessary.
 */




> If that's a case, and this feature is actually used, then it's a bad
> idea IMHO.
> For example, how do you handle the case where one block is bad on a
> chip but not on the other? And I fear this is not the only problem
> with this approach :-/.

As you expect, if one block is bad,
the correspond block on the other chip can not be used.



-- 
Best Regards
Masahiro Yamada