Re: [RFC PATCH 04/10 v2 ] x86/fpu: eager switch PKRU state
On 18/09/2018 19:29, Rik van Riel wrote:
> On Tue, 2018-09-18 at 18:04 +0200, Sebastian Andrzej Siewior wrote:
>> On 2018-09-18 17:29:52 [+0200], Paolo Bonzini wrote:
I don't think it matters what the PKRU state is
for kernel threads, since kernel PTEs should not
be using protection keys anyway.
>>>
>>> What about copy_from/to_user?
>>
>> This doesn't work for a kernel thread, does it? I mean they share the
>> init's MM and never do copy_{from|to}_user.
>
> Indeed, copy_from/to_user only works if current->mm
> points at an mm_struct with userspace memory.
A kthread can do use_mm/unuse_mm.
Paolo
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 04/10 v2 ] x86/fpu: eager switch PKRU state
On 18/09/2018 19:29, Rik van Riel wrote:
> On Tue, 2018-09-18 at 18:04 +0200, Sebastian Andrzej Siewior wrote:
>> On 2018-09-18 17:29:52 [+0200], Paolo Bonzini wrote:
I don't think it matters what the PKRU state is
for kernel threads, since kernel PTEs should not
be using protection keys anyway.
>>>
>>> What about copy_from/to_user?
>>
>> This doesn't work for a kernel thread, does it? I mean they share the
>> init's MM and never do copy_{from|to}_user.
>
> Indeed, copy_from/to_user only works if current->mm
> points at an mm_struct with userspace memory.
A kthread can do use_mm/unuse_mm.
Paolo
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 2/3] spis: mediatek: add spi slave for Mediatek MT2712
Hi Mark,
Thanks for your comments.
On Tue, 2018-09-18 at 09:30 -0700, Mark Brown wrote:
> On Mon, Sep 17, 2018 at 10:19:21AM +0800, Leilk Liu wrote:
>
> This looks overall pretty good, a few smallish comments below:
>
> Please use subject lines matching the style for the subsystem. This
> makes it easier for people to identify relevant patches.
>
OK, I'll fix it, thanks.
> > if SPI_SLAVE
> > +config SPI_SLAVE_MT27XX
> > + tristate "MediaTek SPI slave device"
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
> > + help
> > + This selects the MediaTek(R) SPI slave device driver.
> > + If you want to use MediaTek(R) SPI slave interface,
> > + say Y or M here.If you are not sure, say N.
> > + SPI slave drivers for Mediatek MT27XX series ARM SoCs.
> >
> > config SPI_SLAVE_TIME
>
> This is a driver not a slave implementation, it should be with the other
> drivers in the Kconfig. The slave implementations are for the
> functionality that uses the drivers, not the drivers themselves.
>
OK, I'll fix it, thanks.
> > + /* set the tx/rx endian */
> > +#ifdef __LITTLE_ENDIAN
> > + reg_val &= ~SPIS_TX_ENDIAN;
> > + reg_val &= ~SPIS_RX_ENDIAN;
> > +#else
> > + reg_val |= SPIS_TX_ENDIAN;
> > + reg_val |= SPIS_RX_ENDIAN;
> > +#endif
> > + writel(reg_val, mdata->base + SPIS_CFG_REG);
>
> This seems weird - it looks like it's changing the endianess of the
> protocol based on the endianness the processor is running in. What's
> going on here? I'd expect the driver to be just treating everything as
> a byte stream and letting the protocol driver handle the endianness
> issues, otherwise we might end up with double converions.
>
OK, I'll set the endian of SPI the same with the processor. Thanks.
> > + xfer->tx_dma = dma_map_single(dev, (void *)xfer->tx_buf,
> > + xfer->len, DMA_TO_DEVICE);
>
> Why is there a cast to void here? That's usually a sign that there's a
> type safety issue, the whole point with void is that it's compatible
> with any other pointer.
>
tx_buf is a const void*, here it need a void * for the dma mapping.
And I'll remove void * from dma_map_single((void *)rx_buf).
Thanks.
> > +static irqreturn_t mtk_spi_slave_interrupt(int irq, void *dev_id)
> > +{
> > + struct spi_controller *ctlr = dev_id;
> > + struct mtk_spi_slave *mdata = spi_controller_get_devdata(ctlr);
> > + struct spi_transfer *trans = mdata->cur_transfer;
> > + u32 int_status, reg_val, cnt, remainder;
> > +
> > + int_status = readl(mdata->base + SPIS_IRQ_ST_REG);
> > + writel(int_status, mdata->base + SPIS_IRQ_CLR_REG);
> > +
> > + if (!trans)
> > + return IRQ_HANDLED;
>
> Are you sure that this is the right thing to do if we get a spurious
> interrupt - the normal thing would be to return IRQ_NONE, possibly
> logging a warning as well?
>
OK, it should reture IRQ_NONE here, thanks.
> > + if (int_status & CMD_INVALID_ST)
> > + dev_err(>dev, "cmd invalid\n");
>
> If there's an interrupt that doesn't have any of the interrupt status
> flags set I'd expect to see a warning and probably IRQ_NONE being
> returned. That way if the interrupt line is shared we work correctly
> and if something goes wrong and the interrupt gets stuck on then the
> core interrupt code's error handling can kick in.
OK, I'll fix it, thanks.
Re: [PATCH v3 2/3] spis: mediatek: add spi slave for Mediatek MT2712
Hi Mark,
Thanks for your comments.
On Tue, 2018-09-18 at 09:30 -0700, Mark Brown wrote:
> On Mon, Sep 17, 2018 at 10:19:21AM +0800, Leilk Liu wrote:
>
> This looks overall pretty good, a few smallish comments below:
>
> Please use subject lines matching the style for the subsystem. This
> makes it easier for people to identify relevant patches.
>
OK, I'll fix it, thanks.
> > if SPI_SLAVE
> > +config SPI_SLAVE_MT27XX
> > + tristate "MediaTek SPI slave device"
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
> > + help
> > + This selects the MediaTek(R) SPI slave device driver.
> > + If you want to use MediaTek(R) SPI slave interface,
> > + say Y or M here.If you are not sure, say N.
> > + SPI slave drivers for Mediatek MT27XX series ARM SoCs.
> >
> > config SPI_SLAVE_TIME
>
> This is a driver not a slave implementation, it should be with the other
> drivers in the Kconfig. The slave implementations are for the
> functionality that uses the drivers, not the drivers themselves.
>
OK, I'll fix it, thanks.
> > + /* set the tx/rx endian */
> > +#ifdef __LITTLE_ENDIAN
> > + reg_val &= ~SPIS_TX_ENDIAN;
> > + reg_val &= ~SPIS_RX_ENDIAN;
> > +#else
> > + reg_val |= SPIS_TX_ENDIAN;
> > + reg_val |= SPIS_RX_ENDIAN;
> > +#endif
> > + writel(reg_val, mdata->base + SPIS_CFG_REG);
>
> This seems weird - it looks like it's changing the endianess of the
> protocol based on the endianness the processor is running in. What's
> going on here? I'd expect the driver to be just treating everything as
> a byte stream and letting the protocol driver handle the endianness
> issues, otherwise we might end up with double converions.
>
OK, I'll set the endian of SPI the same with the processor. Thanks.
> > + xfer->tx_dma = dma_map_single(dev, (void *)xfer->tx_buf,
> > + xfer->len, DMA_TO_DEVICE);
>
> Why is there a cast to void here? That's usually a sign that there's a
> type safety issue, the whole point with void is that it's compatible
> with any other pointer.
>
tx_buf is a const void*, here it need a void * for the dma mapping.
And I'll remove void * from dma_map_single((void *)rx_buf).
Thanks.
> > +static irqreturn_t mtk_spi_slave_interrupt(int irq, void *dev_id)
> > +{
> > + struct spi_controller *ctlr = dev_id;
> > + struct mtk_spi_slave *mdata = spi_controller_get_devdata(ctlr);
> > + struct spi_transfer *trans = mdata->cur_transfer;
> > + u32 int_status, reg_val, cnt, remainder;
> > +
> > + int_status = readl(mdata->base + SPIS_IRQ_ST_REG);
> > + writel(int_status, mdata->base + SPIS_IRQ_CLR_REG);
> > +
> > + if (!trans)
> > + return IRQ_HANDLED;
>
> Are you sure that this is the right thing to do if we get a spurious
> interrupt - the normal thing would be to return IRQ_NONE, possibly
> logging a warning as well?
>
OK, it should reture IRQ_NONE here, thanks.
> > + if (int_status & CMD_INVALID_ST)
> > + dev_err(>dev, "cmd invalid\n");
>
> If there's an interrupt that doesn't have any of the interrupt status
> flags set I'd expect to see a warning and probably IRQ_NONE being
> returned. That way if the interrupt line is shared we work correctly
> and if something goes wrong and the interrupt gets stuck on then the
> core interrupt code's error handling can kick in.
OK, I'll fix it, thanks.
Re: [alsa-devel] [PATCH v4 14/14] ASoC: qcom: common: move be_hw_fixup to common
Hello Srinivas,
We will add support for vi feedback usecase in sdm845 machine driver
where we have to support 4 channel tx data for a particular backend. We
should probably keep be_hw_params_fixup in respective machine driver for
now to support such requirement.
Thanks,
Rohit
On 9/17/2018 6:27 AM, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
be_hw_fixup for qdsp is common across mutiple qcom machine drivers,
so move it to common file and remove the redundant code.
Signed-off-by: Srinivas Kandagatla
---
sound/soc/qcom/apq8096.c | 15 ---
sound/soc/qcom/common.c | 17 +
sound/soc/qcom/sdm845.c | 22 ++
3 files changed, 19 insertions(+), 35 deletions(-)
diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
index daad43f..9cb26aee 100644
--- a/sound/soc/qcom/apq8096.c
+++ b/sound/soc/qcom/apq8096.c
@@ -20,20 +20,6 @@ struct apq8096_card_data {
bool jack_setup;
};
-static int apq8096_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
- struct snd_pcm_hw_params *params)
-{
- struct snd_interval *rate = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_RATE);
- struct snd_interval *channels = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_CHANNELS);
-
- rate->min = rate->max = 48000;
- channels->min = channels->max = 2;
-
- return 0;
-}
-
static int msm_snd_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -139,7 +125,6 @@ static void apq8096_add_be_ops(struct snd_soc_card *card)
for (i = 0; i < num_links; i++) {
if (link->no_pcm == 1) {
- link->be_hw_params_fixup = apq8096_be_hw_params_fixup;
link->init = apq8096_init;
link->ops = _ops;
}
diff --git a/sound/soc/qcom/common.c b/sound/soc/qcom/common.c
index eb1b9da..ce8e759 100644
--- a/sound/soc/qcom/common.c
+++ b/sound/soc/qcom/common.c
@@ -3,8 +3,24 @@
// Copyright (c) 2018, The Linux Foundation. All rights reserved.
#include
+#include
#include "common.h"
+static int qcom_snd_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_interval *rate = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_RATE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+
+ rate->min = rate->max = 48000;
+ channels->min = channels->max = 2;
+ params_set_format(params, SNDRV_PCM_FORMAT_S16_LE);
+
+ return 0;
+}
+
int qcom_snd_parse_of(struct snd_soc_card *card)
{
struct device_node *np;
@@ -79,6 +95,7 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
}
link->no_pcm = 1;
link->ignore_pmdown_time = 1;
+ link->be_hw_params_fixup = qcom_snd_be_hw_params_fixup;
} else {
link->platform_of_node = link->cpu_of_node;
link->codec_dai_name = "snd-soc-dummy-dai";
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 2a781d8..87e150c 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -11,7 +11,6 @@
#include "common.h"
#include "qdsp6/q6afe.h"
-#define DEFAULT_SAMPLE_RATE_48K 48000
#define DEFAULT_MCLK_RATE 24576000
#define DEFAULT_BCLK_RATE 12288000
@@ -177,32 +176,15 @@ static struct snd_soc_ops sdm845_be_ops = {
.shutdown = sdm845_snd_shutdown,
};
-static int sdm845_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
- struct snd_pcm_hw_params *params)
-{
- struct snd_interval *rate = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_RATE);
- struct snd_interval *channels = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_CHANNELS);
- struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
-
- rate->min = rate->max = DEFAULT_SAMPLE_RATE_48K;
- channels->min = channels->max = 2;
- snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE);
-
- return 0;
-}
-
static void sdm845_add_be_ops(struct snd_soc_card *card)
{
struct snd_soc_dai_link *link = card->dai_link;
int i, num_links = card->num_links;
for (i = 0; i < num_links; i++) {
- if (link->no_pcm == 1) {
+ if (link->no_pcm == 1)
link->ops = _be_ops;
- link->be_hw_params_fixup = sdm845_be_hw_params_fixup;
- }
+
link++;
}
[PATCH 1/6] staging: erofs: remove redundant CONFIG_EROFS_FS_XATTRs
some CONFIG_EROFS_FS_XATTR conditions were added because of
the historial Linux kernel compatibility, which are unneeded now.
Signed-off-by: Gao Xiang
---
Hi all,
These are cleanup patches in Chao's erofs-dev test tree for a while.
Many of them are trivial.
In order for all preview patches to keep up with the staging tree,
I resend them now.
Thanks,
Gao Xiang
drivers/staging/erofs/inode.c| 6 --
drivers/staging/erofs/internal.h | 6 ++
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/erofs/inode.c b/drivers/staging/erofs/inode.c
index c46a8d4..da8693a 100644
--- a/drivers/staging/erofs/inode.c
+++ b/drivers/staging/erofs/inode.c
@@ -260,22 +260,16 @@ struct inode *erofs_iget(struct super_block *sb,
const struct inode_operations erofs_generic_xattr_iops = {
.listxattr = erofs_listxattr,
};
-#endif
-#ifdef CONFIG_EROFS_FS_XATTR
const struct inode_operations erofs_symlink_xattr_iops = {
.get_link = page_get_link,
.listxattr = erofs_listxattr,
};
-#endif
const struct inode_operations erofs_special_inode_operations = {
-#ifdef CONFIG_EROFS_FS_XATTR
.listxattr = erofs_listxattr,
-#endif
};
-#ifdef CONFIG_EROFS_FS_XATTR
const struct inode_operations erofs_fast_symlink_xattr_iops = {
.get_link = simple_get_link,
.listxattr = erofs_listxattr,
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index 0011b9d..cfcc6db 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -507,13 +507,11 @@ extern struct inode *erofs_iget(struct super_block *sb,
int erofs_namei(struct inode *dir, struct qstr *name,
erofs_nid_t *nid, unsigned *d_type);
-/* xattr.c */
#ifdef CONFIG_EROFS_FS_XATTR
+/* xattr.c */
extern const struct xattr_handler *erofs_xattr_handlers[];
-#endif
-/* symlink */
-#ifdef CONFIG_EROFS_FS_XATTR
+/* symlink and special inode */
extern const struct inode_operations erofs_symlink_xattr_iops;
extern const struct inode_operations erofs_fast_symlink_xattr_iops;
extern const struct inode_operations erofs_special_inode_operations;
--
1.9.1
Re: [REVIEW][PATCH 06/20] signal/x86: Move mpx siginfo generation into do_bounds
> +struct mpx_fault_info
> +{
Normal kernel style would be:
struct mpx_fault_info {
Re: [alsa-devel] [PATCH v4 14/14] ASoC: qcom: common: move be_hw_fixup to common
Hello Srinivas,
We will add support for vi feedback usecase in sdm845 machine driver
where we have to support 4 channel tx data for a particular backend. We
should probably keep be_hw_params_fixup in respective machine driver for
now to support such requirement.
Thanks,
Rohit
On 9/17/2018 6:27 AM, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
be_hw_fixup for qdsp is common across mutiple qcom machine drivers,
so move it to common file and remove the redundant code.
Signed-off-by: Srinivas Kandagatla
---
sound/soc/qcom/apq8096.c | 15 ---
sound/soc/qcom/common.c | 17 +
sound/soc/qcom/sdm845.c | 22 ++
3 files changed, 19 insertions(+), 35 deletions(-)
diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
index daad43f..9cb26aee 100644
--- a/sound/soc/qcom/apq8096.c
+++ b/sound/soc/qcom/apq8096.c
@@ -20,20 +20,6 @@ struct apq8096_card_data {
bool jack_setup;
};
-static int apq8096_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
- struct snd_pcm_hw_params *params)
-{
- struct snd_interval *rate = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_RATE);
- struct snd_interval *channels = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_CHANNELS);
-
- rate->min = rate->max = 48000;
- channels->min = channels->max = 2;
-
- return 0;
-}
-
static int msm_snd_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -139,7 +125,6 @@ static void apq8096_add_be_ops(struct snd_soc_card *card)
for (i = 0; i < num_links; i++) {
if (link->no_pcm == 1) {
- link->be_hw_params_fixup = apq8096_be_hw_params_fixup;
link->init = apq8096_init;
link->ops = _ops;
}
diff --git a/sound/soc/qcom/common.c b/sound/soc/qcom/common.c
index eb1b9da..ce8e759 100644
--- a/sound/soc/qcom/common.c
+++ b/sound/soc/qcom/common.c
@@ -3,8 +3,24 @@
// Copyright (c) 2018, The Linux Foundation. All rights reserved.
#include
+#include
#include "common.h"
+static int qcom_snd_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_interval *rate = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_RATE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+
+ rate->min = rate->max = 48000;
+ channels->min = channels->max = 2;
+ params_set_format(params, SNDRV_PCM_FORMAT_S16_LE);
+
+ return 0;
+}
+
int qcom_snd_parse_of(struct snd_soc_card *card)
{
struct device_node *np;
@@ -79,6 +95,7 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
}
link->no_pcm = 1;
link->ignore_pmdown_time = 1;
+ link->be_hw_params_fixup = qcom_snd_be_hw_params_fixup;
} else {
link->platform_of_node = link->cpu_of_node;
link->codec_dai_name = "snd-soc-dummy-dai";
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
index 2a781d8..87e150c 100644
--- a/sound/soc/qcom/sdm845.c
+++ b/sound/soc/qcom/sdm845.c
@@ -11,7 +11,6 @@
#include "common.h"
#include "qdsp6/q6afe.h"
-#define DEFAULT_SAMPLE_RATE_48K 48000
#define DEFAULT_MCLK_RATE 24576000
#define DEFAULT_BCLK_RATE 12288000
@@ -177,32 +176,15 @@ static struct snd_soc_ops sdm845_be_ops = {
.shutdown = sdm845_snd_shutdown,
};
-static int sdm845_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
- struct snd_pcm_hw_params *params)
-{
- struct snd_interval *rate = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_RATE);
- struct snd_interval *channels = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_CHANNELS);
- struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
-
- rate->min = rate->max = DEFAULT_SAMPLE_RATE_48K;
- channels->min = channels->max = 2;
- snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE);
-
- return 0;
-}
-
static void sdm845_add_be_ops(struct snd_soc_card *card)
{
struct snd_soc_dai_link *link = card->dai_link;
int i, num_links = card->num_links;
for (i = 0; i < num_links; i++) {
- if (link->no_pcm == 1) {
+ if (link->no_pcm == 1)
link->ops = _be_ops;
- link->be_hw_params_fixup = sdm845_be_hw_params_fixup;
- }
+
link++;
}
[PATCH 1/6] staging: erofs: remove redundant CONFIG_EROFS_FS_XATTRs
some CONFIG_EROFS_FS_XATTR conditions were added because of
the historial Linux kernel compatibility, which are unneeded now.
Signed-off-by: Gao Xiang
---
Hi all,
These are cleanup patches in Chao's erofs-dev test tree for a while.
Many of them are trivial.
In order for all preview patches to keep up with the staging tree,
I resend them now.
Thanks,
Gao Xiang
drivers/staging/erofs/inode.c| 6 --
drivers/staging/erofs/internal.h | 6 ++
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/erofs/inode.c b/drivers/staging/erofs/inode.c
index c46a8d4..da8693a 100644
--- a/drivers/staging/erofs/inode.c
+++ b/drivers/staging/erofs/inode.c
@@ -260,22 +260,16 @@ struct inode *erofs_iget(struct super_block *sb,
const struct inode_operations erofs_generic_xattr_iops = {
.listxattr = erofs_listxattr,
};
-#endif
-#ifdef CONFIG_EROFS_FS_XATTR
const struct inode_operations erofs_symlink_xattr_iops = {
.get_link = page_get_link,
.listxattr = erofs_listxattr,
};
-#endif
const struct inode_operations erofs_special_inode_operations = {
-#ifdef CONFIG_EROFS_FS_XATTR
.listxattr = erofs_listxattr,
-#endif
};
-#ifdef CONFIG_EROFS_FS_XATTR
const struct inode_operations erofs_fast_symlink_xattr_iops = {
.get_link = simple_get_link,
.listxattr = erofs_listxattr,
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index 0011b9d..cfcc6db 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -507,13 +507,11 @@ extern struct inode *erofs_iget(struct super_block *sb,
int erofs_namei(struct inode *dir, struct qstr *name,
erofs_nid_t *nid, unsigned *d_type);
-/* xattr.c */
#ifdef CONFIG_EROFS_FS_XATTR
+/* xattr.c */
extern const struct xattr_handler *erofs_xattr_handlers[];
-#endif
-/* symlink */
-#ifdef CONFIG_EROFS_FS_XATTR
+/* symlink and special inode */
extern const struct inode_operations erofs_symlink_xattr_iops;
extern const struct inode_operations erofs_fast_symlink_xattr_iops;
extern const struct inode_operations erofs_special_inode_operations;
--
1.9.1
Re: [REVIEW][PATCH 06/20] signal/x86: Move mpx siginfo generation into do_bounds
> +struct mpx_fault_info
> +{
Normal kernel style would be:
struct mpx_fault_info {
Re: [REVIEW][PATCH 02/20] signal/x86: Inline fill_sigtrap_info in it's only caller send_sigtrap
> > clear_siginfo(); > - fill_sigtrap_info(tsk, regs, error_code, si_code, ); > + tsk->thread.trap_nr = X86_TRAP_DB; > + tsk->thread.error_code = error_code; > + > + info.si_signo = SIGTRAP; > + info.si_code = si_code; > + info.si_addr = user_mode(regs) ? (void __user *)regs->ip : NULL; clear_siginfo already zeroes the whole structure, so this could be written more clearly as: if (user_mode(regs) info.si_addr = (void __user *)regs->ip;
Re: [REVIEW][PATCH 02/20] signal/x86: Inline fill_sigtrap_info in it's only caller send_sigtrap
> > clear_siginfo(); > - fill_sigtrap_info(tsk, regs, error_code, si_code, ); > + tsk->thread.trap_nr = X86_TRAP_DB; > + tsk->thread.error_code = error_code; > + > + info.si_signo = SIGTRAP; > + info.si_code = si_code; > + info.si_addr = user_mode(regs) ? (void __user *)regs->ip : NULL; clear_siginfo already zeroes the whole structure, so this could be written more clearly as: if (user_mode(regs) info.si_addr = (void __user *)regs->ip;
Re: [GIT PULL] platform-drivers-x86 for 4.19-2
On Tue, Sep 18, 2018 at 03:38:52PM -0700, Darren Hart wrote: > Hi Linus and Greg, > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.infradead.org/linux-platform-drivers-x86.git > tags/platform-drivers-x86-v4.19-2 > > for you to fetch changes up to ff0e9f26288d2daee4950f42b37a3d3d30d36ec1: > > platform/x86: alienware-wmi: Correct a memory leak (2018-09-10 13:45:43 > -0700) Now pulled, thanks. greg k-h
Re: [GIT PULL] platform-drivers-x86 for 4.19-2
On Tue, Sep 18, 2018 at 03:38:52PM -0700, Darren Hart wrote: > Hi Linus and Greg, > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.infradead.org/linux-platform-drivers-x86.git > tags/platform-drivers-x86-v4.19-2 > > for you to fetch changes up to ff0e9f26288d2daee4950f42b37a3d3d30d36ec1: > > platform/x86: alienware-wmi: Correct a memory leak (2018-09-10 13:45:43 > -0700) Now pulled, thanks. greg k-h
[PATCH] PCI: kirin: Fix section mismatch warning
WARNING: vmlinux.o(.text+0x4758cc): Section mismatch in reference from
the function kirin_pcie_probe() to the function
.init.text:kirin_add_pcie_port()
The function kirin_pcie_probe() references
the function __init kirin_add_pcie_port().
This is often because kirin_pcie_probe lacks a __init
annotation or the annotation of kirin_add_pcie_port is wrong.
Remove '__init' from kirin_add_pcie_port so there is no mismatch.
Fixes: fc5165db245a ("PCI: kirin: Add HiSilicon Kirin SoC PCIe controller
driver")
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
drivers/pci/controller/dwc/pcie-kirin.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-kirin.c
b/drivers/pci/controller/dwc/pcie-kirin.c
index 5352e0c3be82..9b599296205d 100644
--- a/drivers/pci/controller/dwc/pcie-kirin.c
+++ b/drivers/pci/controller/dwc/pcie-kirin.c
@@ -467,8 +467,8 @@ static int kirin_pcie_add_msi(struct dw_pcie *pci,
return 0;
}
-static int __init kirin_add_pcie_port(struct dw_pcie *pci,
- struct platform_device *pdev)
+static int kirin_add_pcie_port(struct dw_pcie *pci,
+ struct platform_device *pdev)
{
int ret;
--
2.19.0
[PATCH] PCI: kirin: Fix section mismatch warning
WARNING: vmlinux.o(.text+0x4758cc): Section mismatch in reference from
the function kirin_pcie_probe() to the function
.init.text:kirin_add_pcie_port()
The function kirin_pcie_probe() references
the function __init kirin_add_pcie_port().
This is often because kirin_pcie_probe lacks a __init
annotation or the annotation of kirin_add_pcie_port is wrong.
Remove '__init' from kirin_add_pcie_port so there is no mismatch.
Fixes: fc5165db245a ("PCI: kirin: Add HiSilicon Kirin SoC PCIe controller
driver")
Reported-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
---
drivers/pci/controller/dwc/pcie-kirin.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-kirin.c
b/drivers/pci/controller/dwc/pcie-kirin.c
index 5352e0c3be82..9b599296205d 100644
--- a/drivers/pci/controller/dwc/pcie-kirin.c
+++ b/drivers/pci/controller/dwc/pcie-kirin.c
@@ -467,8 +467,8 @@ static int kirin_pcie_add_msi(struct dw_pcie *pci,
return 0;
}
-static int __init kirin_add_pcie_port(struct dw_pcie *pci,
- struct platform_device *pdev)
+static int kirin_add_pcie_port(struct dw_pcie *pci,
+ struct platform_device *pdev)
{
int ret;
--
2.19.0
[PATCH] soc: qcom: cmd-db: Fix some uninitialized warning.
Fix the following compile warning:
drivers/soc/qcom/cmd-db.c:194:38: warning: ent.addr may be used uninitialized
in this function [-Wmaybe-uninitialized]
return ret < 0 ? 0 : le32_to_cpu(ent.addr);
drivers/soc/qcom/cmd-db.c:247:38: warning: ent.len may be used uninitialized
in this function [-Wmaybe-uninitialized]
return ret < 0 ? 0 : le16_to_cpu(ent.len);
drivers/soc/qcom/cmd-db.c:269:24: warning: ent.addr may be used uninitialized
in this function [-Wmaybe-uninitialized]
addr = le32_to_cpu(ent.addr);
Signed-off-by: zhong jiang
---
drivers/soc/qcom/cmd-db.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
index a6f6462..280877f 100644
--- a/drivers/soc/qcom/cmd-db.c
+++ b/drivers/soc/qcom/cmd-db.c
@@ -186,7 +186,7 @@ static int cmd_db_get_header(const char *id, struct
entry_header *eh,
u32 cmd_db_read_addr(const char *id)
{
int ret;
- struct entry_header ent;
+ struct entry_header ent = {0};
struct rsc_hdr rsc_hdr;
ret = cmd_db_get_header(id, , _hdr);
@@ -239,7 +239,7 @@ int cmd_db_read_aux_data(const char *id, u8 *data, size_t
len)
size_t cmd_db_read_aux_data_len(const char *id)
{
int ret;
- struct entry_header ent;
+ struct entry_header ent = {0};
struct rsc_hdr rsc_hdr;
ret = cmd_db_get_header(id, , _hdr);
@@ -258,7 +258,7 @@ size_t cmd_db_read_aux_data_len(const char *id)
enum cmd_db_hw_type cmd_db_read_slave_id(const char *id)
{
int ret;
- struct entry_header ent;
+ struct entry_header ent = {0};
struct rsc_hdr rsc_hdr;
u32 addr;
--
1.7.12.4
[PATCH] soc: qcom: cmd-db: Fix some uninitialized warning.
Fix the following compile warning:
drivers/soc/qcom/cmd-db.c:194:38: warning: ent.addr may be used uninitialized
in this function [-Wmaybe-uninitialized]
return ret < 0 ? 0 : le32_to_cpu(ent.addr);
drivers/soc/qcom/cmd-db.c:247:38: warning: ent.len may be used uninitialized
in this function [-Wmaybe-uninitialized]
return ret < 0 ? 0 : le16_to_cpu(ent.len);
drivers/soc/qcom/cmd-db.c:269:24: warning: ent.addr may be used uninitialized
in this function [-Wmaybe-uninitialized]
addr = le32_to_cpu(ent.addr);
Signed-off-by: zhong jiang
---
drivers/soc/qcom/cmd-db.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
index a6f6462..280877f 100644
--- a/drivers/soc/qcom/cmd-db.c
+++ b/drivers/soc/qcom/cmd-db.c
@@ -186,7 +186,7 @@ static int cmd_db_get_header(const char *id, struct
entry_header *eh,
u32 cmd_db_read_addr(const char *id)
{
int ret;
- struct entry_header ent;
+ struct entry_header ent = {0};
struct rsc_hdr rsc_hdr;
ret = cmd_db_get_header(id, , _hdr);
@@ -239,7 +239,7 @@ int cmd_db_read_aux_data(const char *id, u8 *data, size_t
len)
size_t cmd_db_read_aux_data_len(const char *id)
{
int ret;
- struct entry_header ent;
+ struct entry_header ent = {0};
struct rsc_hdr rsc_hdr;
ret = cmd_db_get_header(id, , _hdr);
@@ -258,7 +258,7 @@ size_t cmd_db_read_aux_data_len(const char *id)
enum cmd_db_hw_type cmd_db_read_slave_id(const char *id)
{
int ret;
- struct entry_header ent;
+ struct entry_header ent = {0};
struct rsc_hdr rsc_hdr;
u32 addr;
--
1.7.12.4
[PATCH 0/3] serial: 8250_uniphier: remove unused code and add auto-flow-control
- Remove never-used DT property - Refactor code - Add auto-flow-control support Dai Okamura (1): serial: 8250_uniphier: add auto-flow-control support Masahiro Yamada (2): serial: 8250_uniphier: remove unused "fifo-size" property serial: 8250_uniphier: flatten probe function .../devicetree/bindings/serial/uniphier-uart.txt | 3 +- drivers/tty/serial/8250/8250_uniphier.c| 62 -- 2 files changed, 22 insertions(+), 43 deletions(-) -- 2.7.4
[PATCH 3/3] serial: 8250_uniphier: add auto-flow-control support
From: Dai Okamura
Add selective auto-flow-control support for UniPhier serial driver.
Signed-off-by: Dai Okamura
Signed-off-by: Masahiro Yamada
---
Documentation/devicetree/bindings/serial/uniphier-uart.txt | 3 +++
drivers/tty/serial/8250/8250_uniphier.c| 3 +++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
index 811c479..7a1bf02 100644
--- a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
+++ b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
@@ -6,6 +6,9 @@ Required properties:
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
+Optional properties:
+-auto-flow-control: enable automatic flow control support.
+
Example:
aliases {
serial0 =
diff --git a/drivers/tty/serial/8250/8250_uniphier.c
b/drivers/tty/serial/8250/8250_uniphier.c
index 1028c02..164ba13 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -222,6 +222,9 @@ static int uniphier_uart_probe(struct platform_device *pdev)
up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE;
up.capabilities = UART_CAP_FIFO;
+ if (of_property_read_bool(dev->of_node, "auto-flow-control"))
+ up.capabilities |= UART_CAP_AFE;
+
up.port.serial_in = uniphier_serial_in;
up.port.serial_out = uniphier_serial_out;
up.dl_read = uniphier_serial_dl_read;
--
2.7.4
[PATCH 1/3] serial: 8250_uniphier: remove unused "fifo-size" property
The FIFO size of the UART devices is 64 on almost all UniPhier SoCs
with the exception Pro4TV SoC (MN2WS0230), which used 128 FIFO size.
However, Pro4TV SoC was never upstreamed, and out of production.
So, this property has never been used in a useful way.
Let's remove old unused code.
Signed-off-by: Masahiro Yamada
---
Documentation/devicetree/bindings/serial/uniphier-uart.txt | 4
drivers/tty/serial/8250/8250_uniphier.c| 10 +-
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
index 0b3892a..811c479 100644
--- a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
+++ b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
@@ -6,9 +6,6 @@ Required properties:
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
-Optional properties:
-- fifo-size: the RX/TX FIFO size. Defaults to 64 if not specified.
-
Example:
aliases {
serial0 =
@@ -19,5 +16,4 @@ Example:
reg = <0x54006800 0x40>;
interrupts = <0 33 4>;
clocks = <_clk>;
- fifo-size = <64>;
};
diff --git a/drivers/tty/serial/8250/8250_uniphier.c
b/drivers/tty/serial/8250/8250_uniphier.c
index 28d88ccf..d292654 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -12,9 +12,6 @@
#include "8250.h"
-/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
-#define UNIPHIER_UART_DEFAULT_FIFO_SIZE64
-
/*
* This hardware is similar to 8250, but its register map is a bit different:
* - MMIO32 (regshift = 2)
@@ -185,12 +182,6 @@ static int uniphier_of_serial_setup(struct device *dev,
struct uart_port *port,
port->uartclk = clk_get_rate(priv->clk);
- /* Check for fifo size */
- if (of_property_read_u32(np, "fifo-size", ) == 0)
- port->fifosize = prop;
- else
- port->fifosize = UNIPHIER_UART_DEFAULT_FIFO_SIZE;
-
return 0;
}
@@ -241,6 +232,7 @@ static int uniphier_uart_probe(struct platform_device *pdev)
up.port.type = PORT_16550A;
up.port.iotype = UPIO_MEM32;
+ up.port.fifosize = 64;
up.port.regshift = UNIPHIER_UART_REGSHIFT;
up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE;
up.capabilities = UART_CAP_FIFO;
--
2.7.4
[PATCH 0/3] serial: 8250_uniphier: remove unused code and add auto-flow-control
- Remove never-used DT property - Refactor code - Add auto-flow-control support Dai Okamura (1): serial: 8250_uniphier: add auto-flow-control support Masahiro Yamada (2): serial: 8250_uniphier: remove unused "fifo-size" property serial: 8250_uniphier: flatten probe function .../devicetree/bindings/serial/uniphier-uart.txt | 3 +- drivers/tty/serial/8250/8250_uniphier.c| 62 -- 2 files changed, 22 insertions(+), 43 deletions(-) -- 2.7.4
[PATCH 3/3] serial: 8250_uniphier: add auto-flow-control support
From: Dai Okamura
Add selective auto-flow-control support for UniPhier serial driver.
Signed-off-by: Dai Okamura
Signed-off-by: Masahiro Yamada
---
Documentation/devicetree/bindings/serial/uniphier-uart.txt | 3 +++
drivers/tty/serial/8250/8250_uniphier.c| 3 +++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
index 811c479..7a1bf02 100644
--- a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
+++ b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
@@ -6,6 +6,9 @@ Required properties:
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
+Optional properties:
+-auto-flow-control: enable automatic flow control support.
+
Example:
aliases {
serial0 =
diff --git a/drivers/tty/serial/8250/8250_uniphier.c
b/drivers/tty/serial/8250/8250_uniphier.c
index 1028c02..164ba13 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -222,6 +222,9 @@ static int uniphier_uart_probe(struct platform_device *pdev)
up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE;
up.capabilities = UART_CAP_FIFO;
+ if (of_property_read_bool(dev->of_node, "auto-flow-control"))
+ up.capabilities |= UART_CAP_AFE;
+
up.port.serial_in = uniphier_serial_in;
up.port.serial_out = uniphier_serial_out;
up.dl_read = uniphier_serial_dl_read;
--
2.7.4
[PATCH 1/3] serial: 8250_uniphier: remove unused "fifo-size" property
The FIFO size of the UART devices is 64 on almost all UniPhier SoCs
with the exception Pro4TV SoC (MN2WS0230), which used 128 FIFO size.
However, Pro4TV SoC was never upstreamed, and out of production.
So, this property has never been used in a useful way.
Let's remove old unused code.
Signed-off-by: Masahiro Yamada
---
Documentation/devicetree/bindings/serial/uniphier-uart.txt | 4
drivers/tty/serial/8250/8250_uniphier.c| 10 +-
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
index 0b3892a..811c479 100644
--- a/Documentation/devicetree/bindings/serial/uniphier-uart.txt
+++ b/Documentation/devicetree/bindings/serial/uniphier-uart.txt
@@ -6,9 +6,6 @@ Required properties:
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
-Optional properties:
-- fifo-size: the RX/TX FIFO size. Defaults to 64 if not specified.
-
Example:
aliases {
serial0 =
@@ -19,5 +16,4 @@ Example:
reg = <0x54006800 0x40>;
interrupts = <0 33 4>;
clocks = <_clk>;
- fifo-size = <64>;
};
diff --git a/drivers/tty/serial/8250/8250_uniphier.c
b/drivers/tty/serial/8250/8250_uniphier.c
index 28d88ccf..d292654 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -12,9 +12,6 @@
#include "8250.h"
-/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
-#define UNIPHIER_UART_DEFAULT_FIFO_SIZE64
-
/*
* This hardware is similar to 8250, but its register map is a bit different:
* - MMIO32 (regshift = 2)
@@ -185,12 +182,6 @@ static int uniphier_of_serial_setup(struct device *dev,
struct uart_port *port,
port->uartclk = clk_get_rate(priv->clk);
- /* Check for fifo size */
- if (of_property_read_u32(np, "fifo-size", ) == 0)
- port->fifosize = prop;
- else
- port->fifosize = UNIPHIER_UART_DEFAULT_FIFO_SIZE;
-
return 0;
}
@@ -241,6 +232,7 @@ static int uniphier_uart_probe(struct platform_device *pdev)
up.port.type = PORT_16550A;
up.port.iotype = UPIO_MEM32;
+ up.port.fifosize = 64;
up.port.regshift = UNIPHIER_UART_REGSHIFT;
up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE;
up.capabilities = UART_CAP_FIFO;
--
2.7.4
[PATCH 2/3] serial: 8250_uniphier: flatten probe function
Currently, the DT-related settings are split out to
uniphier_of_serial_setup(), but it turned out to be not nice.
The next commit will add a DT property, but it will not fit in
the helper. Merge the helper into the probe function.
Signed-off-by: Masahiro Yamada
---
drivers/tty/serial/8250/8250_uniphier.c | 49 -
1 file changed, 17 insertions(+), 32 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c
b/drivers/tty/serial/8250/8250_uniphier.c
index d292654..1028c02 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -155,36 +155,6 @@ static void uniphier_serial_dl_write(struct uart_8250_port
*up, int value)
writel(value, up->port.membase + UNIPHIER_UART_DLR);
}
-static int uniphier_of_serial_setup(struct device *dev, struct uart_port *port,
- struct uniphier8250_priv *priv)
-{
- int ret;
- u32 prop;
- struct device_node *np = dev->of_node;
-
- ret = of_alias_get_id(np, "serial");
- if (ret < 0) {
- dev_err(dev, "failed to get alias id\n");
- return ret;
- }
- port->line = ret;
-
- /* Get clk rate through clk driver */
- priv->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(priv->clk)) {
- dev_err(dev, "failed to get clock\n");
- return PTR_ERR(priv->clk);
- }
-
- ret = clk_prepare_enable(priv->clk);
- if (ret < 0)
- return ret;
-
- port->uartclk = clk_get_rate(priv->clk);
-
- return 0;
-}
-
static int uniphier_uart_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -217,9 +187,24 @@ static int uniphier_uart_probe(struct platform_device
*pdev)
memset(, 0, sizeof(up));
- ret = uniphier_of_serial_setup(dev, , priv);
- if (ret < 0)
+ ret = of_alias_get_id(dev->of_node, "serial");
+ if (ret < 0) {
+ dev_err(dev, "failed to get alias id\n");
return ret;
+ }
+ up.port.line = ret;
+
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev, "failed to get clock\n");
+ return PTR_ERR(priv->clk);
+ }
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ return ret;
+
+ up.port.uartclk = clk_get_rate(priv->clk);
spin_lock_init(>atomic_write_lock);
--
2.7.4
[PATCH 2/3] serial: 8250_uniphier: flatten probe function
Currently, the DT-related settings are split out to
uniphier_of_serial_setup(), but it turned out to be not nice.
The next commit will add a DT property, but it will not fit in
the helper. Merge the helper into the probe function.
Signed-off-by: Masahiro Yamada
---
drivers/tty/serial/8250/8250_uniphier.c | 49 -
1 file changed, 17 insertions(+), 32 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c
b/drivers/tty/serial/8250/8250_uniphier.c
index d292654..1028c02 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -155,36 +155,6 @@ static void uniphier_serial_dl_write(struct uart_8250_port
*up, int value)
writel(value, up->port.membase + UNIPHIER_UART_DLR);
}
-static int uniphier_of_serial_setup(struct device *dev, struct uart_port *port,
- struct uniphier8250_priv *priv)
-{
- int ret;
- u32 prop;
- struct device_node *np = dev->of_node;
-
- ret = of_alias_get_id(np, "serial");
- if (ret < 0) {
- dev_err(dev, "failed to get alias id\n");
- return ret;
- }
- port->line = ret;
-
- /* Get clk rate through clk driver */
- priv->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(priv->clk)) {
- dev_err(dev, "failed to get clock\n");
- return PTR_ERR(priv->clk);
- }
-
- ret = clk_prepare_enable(priv->clk);
- if (ret < 0)
- return ret;
-
- port->uartclk = clk_get_rate(priv->clk);
-
- return 0;
-}
-
static int uniphier_uart_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -217,9 +187,24 @@ static int uniphier_uart_probe(struct platform_device
*pdev)
memset(, 0, sizeof(up));
- ret = uniphier_of_serial_setup(dev, , priv);
- if (ret < 0)
+ ret = of_alias_get_id(dev->of_node, "serial");
+ if (ret < 0) {
+ dev_err(dev, "failed to get alias id\n");
return ret;
+ }
+ up.port.line = ret;
+
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev, "failed to get clock\n");
+ return PTR_ERR(priv->clk);
+ }
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ return ret;
+
+ up.port.uartclk = clk_get_rate(priv->clk);
spin_lock_init(>atomic_write_lock);
--
2.7.4
[PATCH] sched: psi: Fix a GCC uninitialized warning
I find the following warning when compiling the kernel.
kernel/sched/psi.c:639:13: warning: 'rq' may be used uninitialized in this
function [-Wmaybe-uninitialized]
struct rq *rq;
Signed-off-by: zhong jiang
---
kernel/sched/psi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7cdecfc..2d8a1f2 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -636,7 +636,7 @@ void cgroup_move_task(struct task_struct *task, struct
css_set *to)
bool move_psi = !psi_disabled;
unsigned int task_flags = 0;
struct rq_flags rf;
- struct rq *rq;
+ struct rq *rq = NULL;
if (move_psi) {
rq = task_rq_lock(task, );
--
1.7.12.4
[PATCH] sched: psi: Fix a GCC uninitialized warning
I find the following warning when compiling the kernel.
kernel/sched/psi.c:639:13: warning: 'rq' may be used uninitialized in this
function [-Wmaybe-uninitialized]
struct rq *rq;
Signed-off-by: zhong jiang
---
kernel/sched/psi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7cdecfc..2d8a1f2 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -636,7 +636,7 @@ void cgroup_move_task(struct task_struct *task, struct
css_set *to)
bool move_psi = !psi_disabled;
unsigned int task_flags = 0;
struct rq_flags rf;
- struct rq *rq;
+ struct rq *rq = NULL;
if (move_psi) {
rq = task_rq_lock(task, );
--
1.7.12.4
[PATCH] zram: fix missing zero pages for memory tracking
We need to count zero filled pages as well as other pages in zram.
Otherwise, it doesn't match swap page count via pagemap of process
so that memory tracking feature in zram doesn't provide accurate
information.
Cc: Sergey Senozhatsky
Cc: [4.18+]
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index a1d6b5597c17..40d303d8826f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -71,7 +71,7 @@ static inline bool init_done(struct zram *zram)
static inline bool zram_allocated(struct zram *zram, u32 index)
{
- return (zram->table[index].value >> (ZRAM_FLAG_SHIFT + 1)) ||
+ return zram->table[index].value >> ZRAM_FLAG_SHIFT ||
zram->table[index].handle;
}
--
2.19.0.397.gdd90340f6a-goog
[PATCH] zram: fix missing zero pages for memory tracking
We need to count zero filled pages as well as other pages in zram.
Otherwise, it doesn't match swap page count via pagemap of process
so that memory tracking feature in zram doesn't provide accurate
information.
Cc: Sergey Senozhatsky
Cc: [4.18+]
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index a1d6b5597c17..40d303d8826f 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -71,7 +71,7 @@ static inline bool init_done(struct zram *zram)
static inline bool zram_allocated(struct zram *zram, u32 index)
{
- return (zram->table[index].value >> (ZRAM_FLAG_SHIFT + 1)) ||
+ return zram->table[index].value >> ZRAM_FLAG_SHIFT ||
zram->table[index].handle;
}
--
2.19.0.397.gdd90340f6a-goog
Re: i2c:ocores: fixes and polling mechanism
> "Wolfram" == Wolfram Sang writes: >> Thanks! I'll take a look at the patches now. > Ping :) I'm terribly sorry. I didn't manage to review before leaving on travel. I'm back next week and then I'll review, OK? -- Bye, Peter Korsgaard
Re: i2c:ocores: fixes and polling mechanism
> "Wolfram" == Wolfram Sang writes: >> Thanks! I'll take a look at the patches now. > Ping :) I'm terribly sorry. I didn't manage to review before leaving on travel. I'm back next week and then I'll review, OK? -- Bye, Peter Korsgaard
RE: [PATCH v7 2/7] edac: synps: Add platform specific structures for ddrc controller
Hi Boris,
Thanks for your continuous guidance.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, September 18, 2018 1:25 PM
> To: Manish Narani
> Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org;
> Michal Simek ; leoyang...@nxp.com;
> sudeep.ho...@arm.com; amit.kuche...@linaro.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v7 2/7] edac: synps: Add platform specific structures for
> ddrc controller
>
> On Mon, Sep 17, 2018 at 07:55:00PM +0530, Manish Narani wrote:
> > Add platform specific structures, so that we can add different IP
> > support later using quirks.
> >
> > Signed-off-by: Manish Narani
> > ---
> > drivers/edac/synopsys_edac.c | 91
> > +++-
> > 1 file changed, 65 insertions(+), 26 deletions(-)
>
> ...
>
> > @@ -423,6 +465,7 @@ static void edac_mc_init(struct mem_ctl_info *mci,
> > */
> > static int synps_edac_mc_probe(struct platform_device *pdev) {
> > + const struct synps_platform_data *p_data;
> > struct edac_mc_layer layers[2];
> > struct synps_edac_priv *priv;
> > struct mem_ctl_info *mci;
> > @@ -435,7 +478,8 @@ static int synps_edac_mc_probe(struct
> platform_device *pdev)
> > if (IS_ERR(baseaddr))
> > return PTR_ERR(baseaddr);
> >
> > - if (!edac_get_eccstate(baseaddr)) {
> > + p_data = of_device_get_match_data(>dev);
> > + if (!(p_data->get_eccstate(baseaddr))) {
>
> From last review round:
>
> "Too many parentheses:
>
> if (!p_data->...
>
> is enough."
>
> So I'm going to stop reviewing this patchset until you go through the old
> review
> round again and make sure you've incorporated *all* review feedback and
> haven't forgotten some, like the one above.
>
Okay, I will double check again for the comments from previous review and
rectify the same in v8. Can you please review the remaining patches so that I
can accommodate any changes for them in v8? I regret the inconvenience caused
to you in this.
Thanks,
Manish
RE: [PATCH v7 2/7] edac: synps: Add platform specific structures for ddrc controller
Hi Boris,
Thanks for your continuous guidance.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, September 18, 2018 1:25 PM
> To: Manish Narani
> Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org;
> Michal Simek ; leoyang...@nxp.com;
> sudeep.ho...@arm.com; amit.kuche...@linaro.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v7 2/7] edac: synps: Add platform specific structures for
> ddrc controller
>
> On Mon, Sep 17, 2018 at 07:55:00PM +0530, Manish Narani wrote:
> > Add platform specific structures, so that we can add different IP
> > support later using quirks.
> >
> > Signed-off-by: Manish Narani
> > ---
> > drivers/edac/synopsys_edac.c | 91
> > +++-
> > 1 file changed, 65 insertions(+), 26 deletions(-)
>
> ...
>
> > @@ -423,6 +465,7 @@ static void edac_mc_init(struct mem_ctl_info *mci,
> > */
> > static int synps_edac_mc_probe(struct platform_device *pdev) {
> > + const struct synps_platform_data *p_data;
> > struct edac_mc_layer layers[2];
> > struct synps_edac_priv *priv;
> > struct mem_ctl_info *mci;
> > @@ -435,7 +478,8 @@ static int synps_edac_mc_probe(struct
> platform_device *pdev)
> > if (IS_ERR(baseaddr))
> > return PTR_ERR(baseaddr);
> >
> > - if (!edac_get_eccstate(baseaddr)) {
> > + p_data = of_device_get_match_data(>dev);
> > + if (!(p_data->get_eccstate(baseaddr))) {
>
> From last review round:
>
> "Too many parentheses:
>
> if (!p_data->...
>
> is enough."
>
> So I'm going to stop reviewing this patchset until you go through the old
> review
> round again and make sure you've incorporated *all* review feedback and
> haven't forgotten some, like the one above.
>
Okay, I will double check again for the comments from previous review and
rectify the same in v8. Can you please review the remaining patches so that I
can accommodate any changes for them in v8? I regret the inconvenience caused
to you in this.
Thanks,
Manish
RE: [PATCH v7 1/7] edac: synopsys: Fix code comments and naming convention
Hi Boris, Thanks a lot for the review. > -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Tuesday, September 18, 2018 1:23 PM > To: Manish Narani > Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org; > Michal Simek ; leoyang...@nxp.com; > sudeep.ho...@arm.com; amit.kuche...@linaro.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v7 1/7] edac: synopsys: Fix code comments and naming > convention > > On Mon, Sep 17, 2018 at 07:54:59PM +0530, Manish Narani wrote: > > Update the comments in the Synopsys EDAC driver. Minor changes to > > function names and return types are also included. > > > > Signed-off-by: Manish Narani > > --- > > drivers/edac/synopsys_edac.c | 176 > > --- > > 1 file changed, 80 insertions(+), 96 deletions(-) > > So this patch does a bunch of things together and should be split into: > > * functional changes like code cleanup > * functions renaming > * comments cleanup > > Maybe in that order. > > This way you'll have one logical set of changes per patch and review will be > almost trivial. > Okay, I will do that in v8. Thanks, Manish
RE: [PATCH v7 1/7] edac: synopsys: Fix code comments and naming convention
Hi Boris, Thanks a lot for the review. > -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Tuesday, September 18, 2018 1:23 PM > To: Manish Narani > Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org; > Michal Simek ; leoyang...@nxp.com; > sudeep.ho...@arm.com; amit.kuche...@linaro.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v7 1/7] edac: synopsys: Fix code comments and naming > convention > > On Mon, Sep 17, 2018 at 07:54:59PM +0530, Manish Narani wrote: > > Update the comments in the Synopsys EDAC driver. Minor changes to > > function names and return types are also included. > > > > Signed-off-by: Manish Narani > > --- > > drivers/edac/synopsys_edac.c | 176 > > --- > > 1 file changed, 80 insertions(+), 96 deletions(-) > > So this patch does a bunch of things together and should be split into: > > * functional changes like code cleanup > * functions renaming > * comments cleanup > > Maybe in that order. > > This way you'll have one logical set of changes per patch and review will be > almost trivial. > Okay, I will do that in v8. Thanks, Manish
Re: [PATCH 4/5] gpio: davinci: Remove unneeded GPIO macro
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> This macro does nothing and has only one user, remove it.
Tested for gpio interrupts on k2g and da850-lcdk
Tested-by: Keerthy
Acked-by: Keerthy
>
> Signed-off-by: Andrew F. Davis
> ---
> arch/arm/mach-davinci/board-neuros-osd2.c | 8
> include/linux/platform_data/gpio-davinci.h | 5 -
> 2 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c
> b/arch/arm/mach-davinci/board-neuros-osd2.c
> index 353f9e5a1454..efdaa27241c5 100644
> --- a/arch/arm/mach-davinci/board-neuros-osd2.c
> +++ b/arch/arm/mach-davinci/board-neuros-osd2.c
> @@ -130,10 +130,10 @@ static struct platform_device davinci_fb_device = {
> };
>
> static const struct gpio_led ntosd2_leds[] = {
> - { .name = "led1_green", .gpio = GPIO(10), },
> - { .name = "led1_red", .gpio = GPIO(11), },
> - { .name = "led2_green", .gpio = GPIO(12), },
> - { .name = "led2_red", .gpio = GPIO(13), },
> + { .name = "led1_green", .gpio = 10, },
> + { .name = "led1_red", .gpio = 11, },
> + { .name = "led2_green", .gpio = 12, },
> + { .name = "led2_red", .gpio = 13, },
> };
>
> static struct gpio_led_platform_data ntosd2_leds_data = {
> diff --git a/include/linux/platform_data/gpio-davinci.h
> b/include/linux/platform_data/gpio-davinci.h
> index b8e4957e7568..47695b342883 100644
> --- a/include/linux/platform_data/gpio-davinci.h
> +++ b/include/linux/platform_data/gpio-davinci.h
> @@ -45,11 +45,6 @@ struct davinci_gpio_controller {
> int irqs[MAX_INT_PER_BANK];
> };
>
> -/*
> - * basic gpio routines
> - */
> -#define GPIO(X) (X) /* 0 <= X <= (DAVINCI_N_GPIO - 1) */
> -
> /* Convert GPIO signal to GPIO pin number */
> #define GPIO_TO_PIN(bank, gpio) (16 * (bank) + (gpio))
>
>
Re: [PATCH 5/5] gpio: davinci: Move driver local definitions to driver
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> These defines, structs and inline functions are used only internally by
> the driver, they do not belong in platform_data. Move them.
Tested for gpio interrupts on k2g and da850-lcdk
Tested-by: Keerthy
Acked-by: Keerthy
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/gpio/gpio-davinci.c| 28 ++
> include/linux/platform_data/gpio-davinci.h | 28 --
> 2 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index 121a7948f785..5c1564fcc24e 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -9,6 +9,7 @@
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> */
> +
> #include
> #include
> #include
> @@ -24,6 +25,12 @@
> #include
> #include
> #include
> +#include
> +
> +#include
> +
> +#define MAX_REGS_BANKS 5
> +#define MAX_INT_PER_BANK 32
>
> struct davinci_gpio_regs {
> u32 dir;
> @@ -45,6 +52,27 @@ typedef struct irq_chip
> *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
> static void __iomem *gpio_base;
> static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
>
> +struct davinci_gpio_irq_data {
> + void __iomem*regs;
> + struct davinci_gpio_controller *chip;
> + int bank_num;
> +};
> +
> +struct davinci_gpio_controller {
> + struct gpio_chipchip;
> + struct irq_domain *irq_domain;
> + /* Serialize access to GPIO registers */
> + spinlock_t lock;
> + void __iomem*regs[MAX_REGS_BANKS];
> + int gpio_unbanked;
> + int irqs[MAX_INT_PER_BANK];
> +};
> +
> +static inline u32 __gpio_mask(unsigned gpio)
> +{
> + return 1 << (gpio % 32);
> +}
> +
> static inline struct davinci_gpio_regs __iomem *irq2regs(struct irq_data *d)
> {
> struct davinci_gpio_regs __iomem *g;
> diff --git a/include/linux/platform_data/gpio-davinci.h
> b/include/linux/platform_data/gpio-davinci.h
> index 47695b342883..f92a47e18034 100644
> --- a/include/linux/platform_data/gpio-davinci.h
> +++ b/include/linux/platform_data/gpio-davinci.h
> @@ -16,40 +16,12 @@
> #ifndef __DAVINCI_GPIO_PLATFORM_H
> #define __DAVINCI_GPIO_PLATFORM_H
>
> -#include
> -#include
> -
> -#include
> -
> -#define MAX_REGS_BANKS 5
> -#define MAX_INT_PER_BANK 32
> -
> struct davinci_gpio_platform_data {
> u32 ngpio;
> u32 gpio_unbanked;
> };
>
> -struct davinci_gpio_irq_data {
> - void __iomem*regs;
> - struct davinci_gpio_controller *chip;
> - int bank_num;
> -};
> -
> -struct davinci_gpio_controller {
> - struct gpio_chipchip;
> - struct irq_domain *irq_domain;
> - /* Serialize access to GPIO registers */
> - spinlock_t lock;
> - void __iomem*regs[MAX_REGS_BANKS];
> - int gpio_unbanked;
> - int irqs[MAX_INT_PER_BANK];
> -};
> -
> /* Convert GPIO signal to GPIO pin number */
> #define GPIO_TO_PIN(bank, gpio) (16 * (bank) + (gpio))
>
> -static inline u32 __gpio_mask(unsigned gpio)
> -{
> - return 1 << (gpio % 32);
> -}
> #endif
>
Re: [PATCH 3/5] gpio: davinci: Allocate the correct amount of memory for controller
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> Previously we created a controller structure per bank of GPIO pins. This
> has since been changed to one per controller, but the allocation size
> was not changed. Fix this here.
>
> This also leaves the variable 'nbank' unused, instead of removing it,
> move it down and use it to clean up a loop. For loops with multiple
> initializers and/or iteration expressions, especially ones that don't
> use those loop counters are quite hard to follow, fix this.
>
Tested for gpio interrupts on k2g and da850-lcdk
Tested-by: Keerthy
Acked-by: Keerthy
> Signed-off-by: Andrew F. Davis
> ---
> drivers/gpio/gpio-davinci.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index 14d1729927d3..121a7948f785 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -165,7 +165,7 @@ davinci_gpio_get_pdata(struct platform_device *pdev)
>
> static int davinci_gpio_probe(struct platform_device *pdev)
> {
> - int gpio, bank, i, ret = 0;
> + int bank, i, ret = 0;
> unsigned int ngpio, nbank, nirq;
> struct davinci_gpio_controller *chips;
> struct davinci_gpio_platform_data *pdata;
> @@ -204,10 +204,7 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> else
> nirq = DIV_ROUND_UP(ngpio, 16);
>
> - nbank = DIV_ROUND_UP(ngpio, 32);
> - chips = devm_kcalloc(dev,
> - nbank, sizeof(struct davinci_gpio_controller),
> - GFP_KERNEL);
> + chips = devm_kzalloc(dev, sizeof(*chips), GFP_KERNEL);
> if (!chips)
> return -ENOMEM;
>
> @@ -247,7 +244,8 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> #endif
> spin_lock_init(>lock);
>
> - for (gpio = 0, bank = 0; gpio < ngpio; gpio += 32, bank++)
> + nbank = DIV_ROUND_UP(ngpio, 32);
> + for (bank = 0; bank < nbank; bank++)
> chips->regs[bank] = gpio_base + offset_array[bank];
>
> ret = devm_gpiochip_add_data(dev, >chip, chips);
>
Re: [PATCH 4/5] gpio: davinci: Remove unneeded GPIO macro
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> This macro does nothing and has only one user, remove it.
Tested for gpio interrupts on k2g and da850-lcdk
Tested-by: Keerthy
Acked-by: Keerthy
>
> Signed-off-by: Andrew F. Davis
> ---
> arch/arm/mach-davinci/board-neuros-osd2.c | 8
> include/linux/platform_data/gpio-davinci.h | 5 -
> 2 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c
> b/arch/arm/mach-davinci/board-neuros-osd2.c
> index 353f9e5a1454..efdaa27241c5 100644
> --- a/arch/arm/mach-davinci/board-neuros-osd2.c
> +++ b/arch/arm/mach-davinci/board-neuros-osd2.c
> @@ -130,10 +130,10 @@ static struct platform_device davinci_fb_device = {
> };
>
> static const struct gpio_led ntosd2_leds[] = {
> - { .name = "led1_green", .gpio = GPIO(10), },
> - { .name = "led1_red", .gpio = GPIO(11), },
> - { .name = "led2_green", .gpio = GPIO(12), },
> - { .name = "led2_red", .gpio = GPIO(13), },
> + { .name = "led1_green", .gpio = 10, },
> + { .name = "led1_red", .gpio = 11, },
> + { .name = "led2_green", .gpio = 12, },
> + { .name = "led2_red", .gpio = 13, },
> };
>
> static struct gpio_led_platform_data ntosd2_leds_data = {
> diff --git a/include/linux/platform_data/gpio-davinci.h
> b/include/linux/platform_data/gpio-davinci.h
> index b8e4957e7568..47695b342883 100644
> --- a/include/linux/platform_data/gpio-davinci.h
> +++ b/include/linux/platform_data/gpio-davinci.h
> @@ -45,11 +45,6 @@ struct davinci_gpio_controller {
> int irqs[MAX_INT_PER_BANK];
> };
>
> -/*
> - * basic gpio routines
> - */
> -#define GPIO(X) (X) /* 0 <= X <= (DAVINCI_N_GPIO - 1) */
> -
> /* Convert GPIO signal to GPIO pin number */
> #define GPIO_TO_PIN(bank, gpio) (16 * (bank) + (gpio))
>
>
Re: [PATCH 5/5] gpio: davinci: Move driver local definitions to driver
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> These defines, structs and inline functions are used only internally by
> the driver, they do not belong in platform_data. Move them.
Tested for gpio interrupts on k2g and da850-lcdk
Tested-by: Keerthy
Acked-by: Keerthy
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/gpio/gpio-davinci.c| 28 ++
> include/linux/platform_data/gpio-davinci.h | 28 --
> 2 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index 121a7948f785..5c1564fcc24e 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -9,6 +9,7 @@
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> */
> +
> #include
> #include
> #include
> @@ -24,6 +25,12 @@
> #include
> #include
> #include
> +#include
> +
> +#include
> +
> +#define MAX_REGS_BANKS 5
> +#define MAX_INT_PER_BANK 32
>
> struct davinci_gpio_regs {
> u32 dir;
> @@ -45,6 +52,27 @@ typedef struct irq_chip
> *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
> static void __iomem *gpio_base;
> static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
>
> +struct davinci_gpio_irq_data {
> + void __iomem*regs;
> + struct davinci_gpio_controller *chip;
> + int bank_num;
> +};
> +
> +struct davinci_gpio_controller {
> + struct gpio_chipchip;
> + struct irq_domain *irq_domain;
> + /* Serialize access to GPIO registers */
> + spinlock_t lock;
> + void __iomem*regs[MAX_REGS_BANKS];
> + int gpio_unbanked;
> + int irqs[MAX_INT_PER_BANK];
> +};
> +
> +static inline u32 __gpio_mask(unsigned gpio)
> +{
> + return 1 << (gpio % 32);
> +}
> +
> static inline struct davinci_gpio_regs __iomem *irq2regs(struct irq_data *d)
> {
> struct davinci_gpio_regs __iomem *g;
> diff --git a/include/linux/platform_data/gpio-davinci.h
> b/include/linux/platform_data/gpio-davinci.h
> index 47695b342883..f92a47e18034 100644
> --- a/include/linux/platform_data/gpio-davinci.h
> +++ b/include/linux/platform_data/gpio-davinci.h
> @@ -16,40 +16,12 @@
> #ifndef __DAVINCI_GPIO_PLATFORM_H
> #define __DAVINCI_GPIO_PLATFORM_H
>
> -#include
> -#include
> -
> -#include
> -
> -#define MAX_REGS_BANKS 5
> -#define MAX_INT_PER_BANK 32
> -
> struct davinci_gpio_platform_data {
> u32 ngpio;
> u32 gpio_unbanked;
> };
>
> -struct davinci_gpio_irq_data {
> - void __iomem*regs;
> - struct davinci_gpio_controller *chip;
> - int bank_num;
> -};
> -
> -struct davinci_gpio_controller {
> - struct gpio_chipchip;
> - struct irq_domain *irq_domain;
> - /* Serialize access to GPIO registers */
> - spinlock_t lock;
> - void __iomem*regs[MAX_REGS_BANKS];
> - int gpio_unbanked;
> - int irqs[MAX_INT_PER_BANK];
> -};
> -
> /* Convert GPIO signal to GPIO pin number */
> #define GPIO_TO_PIN(bank, gpio) (16 * (bank) + (gpio))
>
> -static inline u32 __gpio_mask(unsigned gpio)
> -{
> - return 1 << (gpio % 32);
> -}
> #endif
>
Re: [PATCH 3/5] gpio: davinci: Allocate the correct amount of memory for controller
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> Previously we created a controller structure per bank of GPIO pins. This
> has since been changed to one per controller, but the allocation size
> was not changed. Fix this here.
>
> This also leaves the variable 'nbank' unused, instead of removing it,
> move it down and use it to clean up a loop. For loops with multiple
> initializers and/or iteration expressions, especially ones that don't
> use those loop counters are quite hard to follow, fix this.
>
Tested for gpio interrupts on k2g and da850-lcdk
Tested-by: Keerthy
Acked-by: Keerthy
> Signed-off-by: Andrew F. Davis
> ---
> drivers/gpio/gpio-davinci.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index 14d1729927d3..121a7948f785 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -165,7 +165,7 @@ davinci_gpio_get_pdata(struct platform_device *pdev)
>
> static int davinci_gpio_probe(struct platform_device *pdev)
> {
> - int gpio, bank, i, ret = 0;
> + int bank, i, ret = 0;
> unsigned int ngpio, nbank, nirq;
> struct davinci_gpio_controller *chips;
> struct davinci_gpio_platform_data *pdata;
> @@ -204,10 +204,7 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> else
> nirq = DIV_ROUND_UP(ngpio, 16);
>
> - nbank = DIV_ROUND_UP(ngpio, 32);
> - chips = devm_kcalloc(dev,
> - nbank, sizeof(struct davinci_gpio_controller),
> - GFP_KERNEL);
> + chips = devm_kzalloc(dev, sizeof(*chips), GFP_KERNEL);
> if (!chips)
> return -ENOMEM;
>
> @@ -247,7 +244,8 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> #endif
> spin_lock_init(>lock);
>
> - for (gpio = 0, bank = 0; gpio < ngpio; gpio += 32, bank++)
> + nbank = DIV_ROUND_UP(ngpio, 32);
> + for (bank = 0; bank < nbank; bank++)
> chips->regs[bank] = gpio_base + offset_array[bank];
>
> ret = devm_gpiochip_add_data(dev, >chip, chips);
>
[RESEND PATCH 1/2] mtd: spi-nor: add macros related to MICRON flash
Some MICRON related macros in spi-nor domain were ST.
Rename entries related to STMicroelectronics under macro SNOR_MFR_ST.
Added entry of MFR Id for Micron flashes, 0x002C.
Signed-off-by: Yogesh Gaur
---
drivers/mtd/spi-nor/spi-nor.c | 9 ++---
include/linux/mtd/cfi.h | 1 +
include/linux/mtd/spi-nor.h | 3 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f028277..33a55bc 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -271,6 +271,7 @@ static inline int set_4byte(struct spi_nor *nor, const
struct flash_info *info,
u8 cmd;
switch (JEDEC_MFR(info)) {
+ case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
/* Some Micron need WREN command; all will accept it */
need_wren = true;
@@ -1096,7 +1097,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
{ "mx66l1g45g", INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ)
},
- /* Micron */
+ /* Micron <--> ST Micro */
{ "n25q016a",INFO(0x20bb15, 0, 64 * 1024, 32, SECT_4K |
SPI_NOR_QUAD_READ) },
{ "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
},
{ "n25q032a",INFO(0x20bb16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
},
@@ -2502,6 +2503,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
params->quad_enable = macronix_quad_enable;
break;
+ case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
break;
@@ -2876,8 +2878,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
mtd->_resume = spi_nor_resume;
/* NOR protection support for STmicro/Micron chips and similar */
- if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
- info->flags & SPI_NOR_HAS_LOCK) {
+ if (JEDEC_MFR(info) == SNOR_MFR_ST ||
+ JEDEC_MFR(info) == SNOR_MFR_MICRON ||
+ info->flags & SPI_NOR_HAS_LOCK) {
nor->flash_lock = stm_lock;
nor->flash_unlock = stm_unlock;
nor->flash_is_locked = stm_is_locked;
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..cbf7716 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -377,6 +377,7 @@ struct cfi_fixup {
#define CFI_MFR_SHARP 0x00B0
#define CFI_MFR_SST0x00BF
#define CFI_MFR_ST 0x0020 /* STMicroelectronics */
+#define CFI_MFR_MICRON 0x002C /* Micron */
#define CFI_MFR_TOSHIBA0x0098
#define CFI_MFR_WINBOND0x00DA
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index c922e97..f43bfc5 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -23,7 +23,8 @@
#define SNOR_MFR_ATMEL CFI_MFR_ATMEL
#define SNOR_MFR_GIGADEVICE0xc8
#define SNOR_MFR_INTEL CFI_MFR_INTEL
-#define SNOR_MFR_MICRONCFI_MFR_ST /* ST Micro <--> Micron */
+#define SNOR_MFR_STCFI_MFR_ST /* ST Micro */
+#define SNOR_MFR_MICRONCFI_MFR_MICRON /* Micron */
#define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX
#define SNOR_MFR_SPANSION CFI_MFR_AMD
#define SNOR_MFR_SST CFI_MFR_SST
--
1.9.1
[RESEND PATCH 0/2] mtd: spi-nor: add entry for mt35xu512aba flash
Add MFR_ID information, 0x002C, related to the Micron flash. Currently, MFR_ID 0x0020 is being specified as Micron flash ID but these are actually CFI ID of STMicro flashes. Rename SNOR_MFR_MICRON to SNOR_MFR_ST and add entry for SNOR_MFR_MICRON having CFI ID value of Micron flash. Add entry of mt35xu512aba flash in spi_nor_ids table. Yogesh Gaur (2): mtd: spi-nor: add macros related to MICRON flash mtd: spi-nor: add entry for mt35xu512aba flash drivers/mtd/spi-nor/spi-nor.c | 12 +--- include/linux/mtd/cfi.h | 1 + include/linux/mtd/spi-nor.h | 3 ++- 3 files changed, 12 insertions(+), 4 deletions(-) -- 1.9.1
[RESEND PATCH 2/2] mtd: spi-nor: add entry for mt35xu512aba flash
Add entry for mt35xu512aba Micron NOR flash.
This flash is having uniform sector erase size of 128KB, have
support of FSR(flag status register), flash size is 64MB and
supports 4-byte commands.
Signed-off-by: Yogesh Gaur
---
drivers/mtd/spi-nor/spi-nor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 33a55bc..6042df8 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1113,6 +1113,9 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
{ "n25q00a", INFO(0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+ /* Micron */
+ { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR
| SPI_NOR_4B_OPCODES) },
+
/* PMC */
{ "pm25lv512", INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
{ "pm25lv010", INFO(0,0, 32 * 1024,4, SECT_4K_PMC) },
--
1.9.1
[RESEND PATCH 0/2] mtd: spi-nor: add entry for mt35xu512aba flash
Add MFR_ID information, 0x002C, related to the Micron flash. Currently, MFR_ID 0x0020 is being specified as Micron flash ID but these are actually CFI ID of STMicro flashes. Rename SNOR_MFR_MICRON to SNOR_MFR_ST and add entry for SNOR_MFR_MICRON having CFI ID value of Micron flash. Add entry of mt35xu512aba flash in spi_nor_ids table. Yogesh Gaur (2): mtd: spi-nor: add macros related to MICRON flash mtd: spi-nor: add entry for mt35xu512aba flash drivers/mtd/spi-nor/spi-nor.c | 12 +--- include/linux/mtd/cfi.h | 1 + include/linux/mtd/spi-nor.h | 3 ++- 3 files changed, 12 insertions(+), 4 deletions(-) -- 1.9.1
[RESEND PATCH 2/2] mtd: spi-nor: add entry for mt35xu512aba flash
Add entry for mt35xu512aba Micron NOR flash.
This flash is having uniform sector erase size of 128KB, have
support of FSR(flag status register), flash size is 64MB and
supports 4-byte commands.
Signed-off-by: Yogesh Gaur
---
drivers/mtd/spi-nor/spi-nor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 33a55bc..6042df8 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1113,6 +1113,9 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
{ "n25q00a", INFO(0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+ /* Micron */
+ { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR
| SPI_NOR_4B_OPCODES) },
+
/* PMC */
{ "pm25lv512", INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
{ "pm25lv010", INFO(0,0, 32 * 1024,4, SECT_4K_PMC) },
--
1.9.1
[RESEND PATCH 1/2] mtd: spi-nor: add macros related to MICRON flash
Some MICRON related macros in spi-nor domain were ST.
Rename entries related to STMicroelectronics under macro SNOR_MFR_ST.
Added entry of MFR Id for Micron flashes, 0x002C.
Signed-off-by: Yogesh Gaur
---
drivers/mtd/spi-nor/spi-nor.c | 9 ++---
include/linux/mtd/cfi.h | 1 +
include/linux/mtd/spi-nor.h | 3 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f028277..33a55bc 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -271,6 +271,7 @@ static inline int set_4byte(struct spi_nor *nor, const
struct flash_info *info,
u8 cmd;
switch (JEDEC_MFR(info)) {
+ case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
/* Some Micron need WREN command; all will accept it */
need_wren = true;
@@ -1096,7 +1097,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
{ "mx66l1g45g", INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ)
},
- /* Micron */
+ /* Micron <--> ST Micro */
{ "n25q016a",INFO(0x20bb15, 0, 64 * 1024, 32, SECT_4K |
SPI_NOR_QUAD_READ) },
{ "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
},
{ "n25q032a",INFO(0x20bb16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
},
@@ -2502,6 +2503,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
params->quad_enable = macronix_quad_enable;
break;
+ case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
break;
@@ -2876,8 +2878,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
mtd->_resume = spi_nor_resume;
/* NOR protection support for STmicro/Micron chips and similar */
- if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
- info->flags & SPI_NOR_HAS_LOCK) {
+ if (JEDEC_MFR(info) == SNOR_MFR_ST ||
+ JEDEC_MFR(info) == SNOR_MFR_MICRON ||
+ info->flags & SPI_NOR_HAS_LOCK) {
nor->flash_lock = stm_lock;
nor->flash_unlock = stm_unlock;
nor->flash_is_locked = stm_is_locked;
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..cbf7716 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -377,6 +377,7 @@ struct cfi_fixup {
#define CFI_MFR_SHARP 0x00B0
#define CFI_MFR_SST0x00BF
#define CFI_MFR_ST 0x0020 /* STMicroelectronics */
+#define CFI_MFR_MICRON 0x002C /* Micron */
#define CFI_MFR_TOSHIBA0x0098
#define CFI_MFR_WINBOND0x00DA
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index c922e97..f43bfc5 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -23,7 +23,8 @@
#define SNOR_MFR_ATMEL CFI_MFR_ATMEL
#define SNOR_MFR_GIGADEVICE0xc8
#define SNOR_MFR_INTEL CFI_MFR_INTEL
-#define SNOR_MFR_MICRONCFI_MFR_ST /* ST Micro <--> Micron */
+#define SNOR_MFR_STCFI_MFR_ST /* ST Micro */
+#define SNOR_MFR_MICRONCFI_MFR_MICRON /* Micron */
#define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX
#define SNOR_MFR_SPANSION CFI_MFR_AMD
#define SNOR_MFR_SST CFI_MFR_SST
--
1.9.1
Re: [PATCH v2 00/22] Unify MediaTek pinctrl in preparation for MT8183 and MT6765
On Wed, Sep 19, 2018 at 10:54:10AM +0800, Sean Wang wrote: > On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote: > > On Sat, Sep 8, 2018 at 4:07 AM wrote: > > > > > v2 and changes since v1: > > > > I had trouble applying the last patches in the series so I applied > > all on an immutable branch (ib-mtk) then merged that into devel > > and added a patch on top to fix up some GPIO includes (just sent). > > > > Please check the result! > > > > Sure, I'll take a look and and test on the devel branch. > > On the top, I'll add a fix for the issue recently reported by kbuild > test robot about implicit declaration and a new MT6765 driver based > on the series. > Hi Sean, Do you have any plans to add support for MT6797? Thanks, Mani > > Yours, > > Linus Walleij > >
Re: [PATCH v2 00/22] Unify MediaTek pinctrl in preparation for MT8183 and MT6765
On Wed, Sep 19, 2018 at 10:54:10AM +0800, Sean Wang wrote: > On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote: > > On Sat, Sep 8, 2018 at 4:07 AM wrote: > > > > > v2 and changes since v1: > > > > I had trouble applying the last patches in the series so I applied > > all on an immutable branch (ib-mtk) then merged that into devel > > and added a patch on top to fix up some GPIO includes (just sent). > > > > Please check the result! > > > > Sure, I'll take a look and and test on the devel branch. > > On the top, I'll add a fix for the issue recently reported by kbuild > test robot about implicit declaration and a new MT6765 driver based > on the series. > Hi Sean, Do you have any plans to add support for MT6797? Thanks, Mani > > Yours, > > Linus Walleij > >
ATTENZIONE
ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti informazioni qui di seguito: nome: Nome utente: Password: Conferma Password: E-mail: telefono: Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi posta sarà disabilitato! Ci dispiace per l'inconvenienza. Codice di verifica: en:45tryjl;08fxagklt.0.2018 Mail Technical Support ©2018 grazie Sistemi amministratore --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
ATTENZIONE
ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti informazioni qui di seguito: nome: Nome utente: Password: Conferma Password: E-mail: telefono: Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi posta sarà disabilitato! Ci dispiace per l'inconvenienza. Codice di verifica: en:45tryjl;08fxagklt.0.2018 Mail Technical Support ©2018 grazie Sistemi amministratore --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Greetings
TO WHOM IT MAY CONCERN Greetings, Opportunity for you, I am well recognized and Public Figure occupying a top Government position in Federal Republic of Nigerian. I am hereby requiring An International expatriates with professional experience in all kind, Contractors, Investors and Partnership in any infrastructures projects. For further inquiries contact: centuryinvestments...@gmail.com Thanks
Greetings
TO WHOM IT MAY CONCERN Greetings, Opportunity for you, I am well recognized and Public Figure occupying a top Government position in Federal Republic of Nigerian. I am hereby requiring An International expatriates with professional experience in all kind, Contractors, Investors and Partnership in any infrastructures projects. For further inquiries contact: centuryinvestments...@gmail.com Thanks
Re: [PATCH 2/5] gpio: davinci: Use dev name for label and automatic base selection
On Wednesday 19 September 2018 12:56 AM, Linus Walleij wrote: > On Fri, Aug 31, 2018 at 12:13 PM Andrew F. Davis wrote: > >> Use dev_name to get a unique label and use -1 for a base to get our >> selection automatically. We pull in all GPIOs per chip now so this >> does not have the effect of out of order labels like before. >> >> We do these both together so we can drop all the static data in one >> patch. This also lets us normalize the return paths as we don't need >> any cleanup after this change. >> >> Signed-off-by: Andrew F. Davis > > I have tentatively applied this patch set as we seem to have rough > consensus that it will be OK. > > We can always pull it out or revert it if things break. Okay. If that is the case then i have already tested the entire series. Apart from gpio numbering different, i have tested toggling and interrupts with k2g-evm and omapl138. > > Yours, > Linus Walleij >
Re: [PATCH 2/5] gpio: davinci: Use dev name for label and automatic base selection
On Wednesday 19 September 2018 12:56 AM, Linus Walleij wrote: > On Fri, Aug 31, 2018 at 12:13 PM Andrew F. Davis wrote: > >> Use dev_name to get a unique label and use -1 for a base to get our >> selection automatically. We pull in all GPIOs per chip now so this >> does not have the effect of out of order labels like before. >> >> We do these both together so we can drop all the static data in one >> patch. This also lets us normalize the return paths as we don't need >> any cleanup after this change. >> >> Signed-off-by: Andrew F. Davis > > I have tentatively applied this patch set as we seem to have rough > consensus that it will be OK. > > We can always pull it out or revert it if things break. Okay. If that is the case then i have already tested the entire series. Apart from gpio numbering different, i have tested toggling and interrupts with k2g-evm and omapl138. > > Yours, > Linus Walleij >
Re: [PATCH] gpiolib: Show correct direction from the beginning
Hi Linus On Wed, Sep 19, 2018 at 12:40 AM Linus Walleij wrote: > > On Fri, Sep 14, 2018 at 12:08 AM Ricardo Ribalda Delgado > wrote: > > > Current code assumes that the direction is input if direction_input > > function is set. > > This might not be the case on GPIOs with programmable direction. > > > > Signed-off-by: Ricardo Ribalda Delgado > > --- > > drivers/gpio/gpiolib.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > > index a57300c1d649..af853749e0bb 100644 > > --- a/drivers/gpio/gpiolib.c > > +++ b/drivers/gpio/gpiolib.c > > @@ -1352,7 +1352,12 @@ int gpiochip_add_data_with_key(struct gpio_chip > > *chip, void *data, > > * it does, and in case chip->get_direction is not set, we > > may > > * expose the wrong direction in sysfs. > > */ > > - desc->flags = !chip->direction_input ? (1 << FLAG_IS_OUT) : > > 0; > > + if (chip->get_direction) > > + desc->flags = !chip->get_direction(chip, i) ? > > + (1 << FLAG_IS_OUT) : 0; > > + else > > + desc->flags = !chip->direction_input ? > > + (1 << FLAG_IS_OUT) : 0; > > We used to do this. > > But it breaks Qualcomm hardware. And should't that be tacked in qcom hardware with something like: if (!priv->initialized) return INPUT; if you or Timur point me to the harware that was crashing I would not mind looking into that, but the current situations seems to me like a hack. Other option would be to implement a new function get_direction_fast() (the name could be better). I can also try to implement something in that direction if you want. Thanks for your review. > > commit 1ca2a92b2a99323f666f1b669b7484df4bda05e4 > Author: Timur Tabi > Date: Wed Dec 20 13:10:31 2017 -0600 > > Revert "gpio: set up initial state from .get_direction()" > > This reverts commit 72d3200061776264941be1b5a9bb8e926b3b30a5. > > We cannot blindly query the direction of all GPIOs when the pins are > first registered. The get_direction callback normally triggers a > read/write to hardware, but we shouldn't be touching the hardware for > an individual GPIO until after it's been properly claimed. > > Signed-off-by: Timur Tabi > Reviewed-by: Stephen Boyd > Signed-off-by: Linus Walleij > > Yours, > Linus Walleij -- Ricardo Ribalda
Re: [PATCH] gpiolib: Show correct direction from the beginning
Hi Linus On Wed, Sep 19, 2018 at 12:40 AM Linus Walleij wrote: > > On Fri, Sep 14, 2018 at 12:08 AM Ricardo Ribalda Delgado > wrote: > > > Current code assumes that the direction is input if direction_input > > function is set. > > This might not be the case on GPIOs with programmable direction. > > > > Signed-off-by: Ricardo Ribalda Delgado > > --- > > drivers/gpio/gpiolib.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > > index a57300c1d649..af853749e0bb 100644 > > --- a/drivers/gpio/gpiolib.c > > +++ b/drivers/gpio/gpiolib.c > > @@ -1352,7 +1352,12 @@ int gpiochip_add_data_with_key(struct gpio_chip > > *chip, void *data, > > * it does, and in case chip->get_direction is not set, we > > may > > * expose the wrong direction in sysfs. > > */ > > - desc->flags = !chip->direction_input ? (1 << FLAG_IS_OUT) : > > 0; > > + if (chip->get_direction) > > + desc->flags = !chip->get_direction(chip, i) ? > > + (1 << FLAG_IS_OUT) : 0; > > + else > > + desc->flags = !chip->direction_input ? > > + (1 << FLAG_IS_OUT) : 0; > > We used to do this. > > But it breaks Qualcomm hardware. And should't that be tacked in qcom hardware with something like: if (!priv->initialized) return INPUT; if you or Timur point me to the harware that was crashing I would not mind looking into that, but the current situations seems to me like a hack. Other option would be to implement a new function get_direction_fast() (the name could be better). I can also try to implement something in that direction if you want. Thanks for your review. > > commit 1ca2a92b2a99323f666f1b669b7484df4bda05e4 > Author: Timur Tabi > Date: Wed Dec 20 13:10:31 2017 -0600 > > Revert "gpio: set up initial state from .get_direction()" > > This reverts commit 72d3200061776264941be1b5a9bb8e926b3b30a5. > > We cannot blindly query the direction of all GPIOs when the pins are > first registered. The get_direction callback normally triggers a > read/write to hardware, but we shouldn't be touching the hardware for > an individual GPIO until after it's been properly claimed. > > Signed-off-by: Timur Tabi > Reviewed-by: Stephen Boyd > Signed-off-by: Linus Walleij > > Yours, > Linus Walleij -- Ricardo Ribalda
arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error: linux/crc32poly.h: No such file or directory
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5211da9ca526a5adddee1ccd078e6e33a583ab36 commit: faa16bc404d72a5afb857c924c83a5f691f83386 lib: Use existing define with polynomial date: 8 weeks ago config: powerpc-skiroot_defconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout faa16bc404d72a5afb857c924c83a5f691f83386 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All errors (new ones prefixed by >>): In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0, from arch/powerpc/boot/decompress.c:42: >> arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error: >> linux/crc32poly.h: No such file or directory #include ^~~ compilation terminated. vim +18 arch/powerpc/boot/../../../lib/xz/xz_crc32.c > 18 #include 19 #include "xz_private.h" 20 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error: linux/crc32poly.h: No such file or directory
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 5211da9ca526a5adddee1ccd078e6e33a583ab36 commit: faa16bc404d72a5afb857c924c83a5f691f83386 lib: Use existing define with polynomial date: 8 weeks ago config: powerpc-skiroot_defconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout faa16bc404d72a5afb857c924c83a5f691f83386 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All errors (new ones prefixed by >>): In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0, from arch/powerpc/boot/decompress.c:42: >> arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error: >> linux/crc32poly.h: No such file or directory #include ^~~ compilation terminated. vim +18 arch/powerpc/boot/../../../lib/xz/xz_crc32.c > 18 #include 19 #include "xz_private.h" 20 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/3] drivers/base: move device_shutdown() to base/power
On Fri, Sep 14, 2018 at 5:10 PM Rafael J. Wysocki wrote: > > On Monday, August 20, 2018 11:18:35 AM CEST Pingfan Liu wrote: > > Consider the shutdown as a system state transition, i.e. something like > > suspend, hibernate, hence move it under the base/power. (This is a first > > step to unify the duplicate code logic on devices_kset and dpm_list.) > > I don't really think that device_shutodwn() belongs in base/power/. > > Moving it to a separate file sounds like a good idea, but let that file > reside in base/ proper. > > Then, I would separate the dpm_list definition, locking etc out of > base/power/, move it to the new file containing device_shutdown() and > make the code in base/power/ refer to it (you may want to move the list > entry list head from dev_pm_info to struct device directly while at that > too). > > Then, it should be straightforward enough to switch device_shutdown() over to > using it. > Thanks for your advice. I will find a time slot to redo it. Regards, Pingfan
Re: [PATCH 1/3] drivers/base: move device_shutdown() to base/power
On Fri, Sep 14, 2018 at 5:10 PM Rafael J. Wysocki wrote: > > On Monday, August 20, 2018 11:18:35 AM CEST Pingfan Liu wrote: > > Consider the shutdown as a system state transition, i.e. something like > > suspend, hibernate, hence move it under the base/power. (This is a first > > step to unify the duplicate code logic on devices_kset and dpm_list.) > > I don't really think that device_shutodwn() belongs in base/power/. > > Moving it to a separate file sounds like a good idea, but let that file > reside in base/ proper. > > Then, I would separate the dpm_list definition, locking etc out of > base/power/, move it to the new file containing device_shutdown() and > make the code in base/power/ refer to it (you may want to move the list > entry list head from dev_pm_info to struct device directly while at that > too). > > Then, it should be straightforward enough to switch device_shutdown() over to > using it. > Thanks for your advice. I will find a time slot to redo it. Regards, Pingfan
[PATCH 2/2] ARM: mvebu: Enable ARCH_WANT_LIBATA_LEDS in Armada 38x
Enable hidden symbol ARCH_WANT_LIBATA_LEDS so CONFIG_ATA_LEDS can be used in kernel configuration. URL: https://lists.openwrt.org/pipermail/openwrt- devel/2017-March/006582.html Signed-off-by: Aditya Prayoga --- arch/arm/mach-mvebu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 2c20599..51f3256 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -68,6 +68,7 @@ config MACH_ARMADA_38X select HAVE_SMP select MACH_MVEBU_V7 select PINCTRL_ARMADA_38X + select ARCH_WANT_LIBATA_LEDS help Say 'Y' here if you want your kernel to support boards based on the Marvell Armada 380/385 SoC with device tree. -- 2.7.4
[PATCH 2/2] ARM: mvebu: Enable ARCH_WANT_LIBATA_LEDS in Armada 38x
Enable hidden symbol ARCH_WANT_LIBATA_LEDS so CONFIG_ATA_LEDS can be used in kernel configuration. URL: https://lists.openwrt.org/pipermail/openwrt- devel/2017-March/006582.html Signed-off-by: Aditya Prayoga --- arch/arm/mach-mvebu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 2c20599..51f3256 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -68,6 +68,7 @@ config MACH_ARMADA_38X select HAVE_SMP select MACH_MVEBU_V7 select PINCTRL_ARMADA_38X + select ARCH_WANT_LIBATA_LEDS help Say 'Y' here if you want your kernel to support boards based on the Marvell Armada 380/385 SoC with device tree. -- 2.7.4
[PATCH 1/2] libata: add ledtrig support
From: Daniel Golle
This adds a LED trigger for each ATA port indicating disk activity.
As this is needed only on specific platforms (NAS SoCs and such),
these platforms should define ARCH_WANTS_LIBATA_LEDS if there
are boards with LED(s) intended to indicate ATA disk activity and
need the OS to take care of that.
In that way, if not selected, LED trigger support not will be
included in libata-core and both, codepaths and structures remain
untouched.
I'm currently deploying this for the oxnas target in OpenWrt
https://dev.openwrt.org/changeset/43675/
v2: rebased to kernel/git/tj/libata.git
plus small corrections and comments added
Signed-off-by: Daniel Golle
URL: https://patchwork.ozlabs.org/patch/420733/
[Aditya Prayoga:
* Port forward
* Change ATA_LEDS default to no
* Reduce performance impact by moving ata_led_act() call from
ata_qc_new() to ata_qc_complete()]
Signed-off-by: Aditya Prayoga
---
If there is anything fundamentally wrong with that approach, I'd be
glad for some advise on how to do it better.
I conciously choose an #ifdev approach to make sure performance will
not be affected for non-users of that code.
Thanks
Daniel
---
---
drivers/ata/Kconfig | 16 ++
drivers/ata/libata-core.c | 56 +++
include/linux/libata.h| 7 ++
3 files changed, 79 insertions(+)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 39b181d..a2c64ce 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -46,6 +46,22 @@ config ATA_VERBOSE_ERROR
If unsure, say Y.
+config ARCH_WANT_LIBATA_LEDS
+ bool
+
+config ATA_LEDS
+ bool "support ATA port LED triggers"
+ depends on ARCH_WANT_LIBATA_LEDS
+ select NEW_LEDS
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
+ default n
+ help
+ This option adds a LED trigger for each registered ATA port.
+ It is used to drive disk activity leds connected via GPIO.
+
+ If unsure, say N.
+
config ATA_ACPI
bool "ATA ACPI Support"
depends on ACPI
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 599e01b..65228f5 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5105,6 +5105,30 @@ void swap_buf_le16(u16 *buf, unsigned int buf_words)
}
/**
+ * ata_led_act - Trigger port activity LED
+ * @ap: indicating port
+ *
+ * Blinks any LEDs registered to the trigger.
+ * Commonly used with leds-gpio on NAS systems with disk activity
+ * indicator LEDs.
+ *
+ * LOCKING:
+ * None.
+ */
+static inline void ata_led_act(struct ata_port *ap)
+{
+#ifdef CONFIG_ATA_LEDS
+#define LIBATA_BLINK_DELAY 20 /* ms */
+ unsigned long led_delay = LIBATA_BLINK_DELAY;
+
+ if (unlikely(!ap->ledtrig))
+ return;
+
+ led_trigger_blink_oneshot(ap->ledtrig, _delay, _delay, 0);
+#endif /* CONFIG_ATA_LEDS */
+}
+
+/**
* ata_qc_new_init - Request an available ATA command, and initialize it
* @dev: Device from whom we request an available command structure
* @tag: tag
@@ -5249,6 +5273,10 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
/* Trigger the LED (if available) */
ledtrig_disk_activity(!!(qc->tf.flags & ATA_TFLAG_WRITE));
+#ifdef CONFIG_ATA_LEDS
+ ata_led_act(ap);
+#endif
+
/* XXX: New EH and old EH use different mechanisms to
* synchronize EH with regular execution path.
*
@@ -6028,6 +6056,9 @@ struct ata_port *ata_port_alloc(struct ata_host *host)
ap->stats.unhandled_irq = 1;
ap->stats.idle_irq = 1;
#endif
+#ifdef CONFIG_ATA_LEDS
+ ap->ledtrig = kzalloc(sizeof(struct led_trigger), GFP_KERNEL);
+#endif
ata_sff_port_init(ap);
return ap;
@@ -6063,6 +6094,12 @@ static void ata_host_release(struct kref *kref)
kfree(ap->pmp_link);
kfree(ap->slave_link);
+#ifdef CONFIG_ATA_LEDS
+ if (ap->ledtrig) {
+ led_trigger_unregister(ap->ledtrig);
+ kfree(ap->ledtrig);
+ };
+#endif
kfree(ap);
host->ports[i] = NULL;
}
@@ -6527,6 +6564,25 @@ int ata_host_register(struct ata_host *host, struct
scsi_host_template *sht)
host->ports[i]->local_port_no = i + 1;
}
+#ifdef CONFIG_ATA_LEDS
+ /* register LED triggers for all ports */
+ for (i = 0; i < host->n_ports; i++) {
+ if (unlikely(!host->ports[i]->ledtrig))
+ continue;
+
+ snprintf(host->ports[i]->ledtrig_name,
+ sizeof(host->ports[i]->ledtrig_name), "ata%u",
+ host->ports[i]->print_id);
+
+ host->ports[i]->ledtrig->name = host->ports[i]->ledtrig_name;
+
+ if (led_trigger_register(host->ports[i]->ledtrig)) {
+ kfree(host->ports[i]->ledtrig);
+
[PATCH 1/2] libata: add ledtrig support
From: Daniel Golle
This adds a LED trigger for each ATA port indicating disk activity.
As this is needed only on specific platforms (NAS SoCs and such),
these platforms should define ARCH_WANTS_LIBATA_LEDS if there
are boards with LED(s) intended to indicate ATA disk activity and
need the OS to take care of that.
In that way, if not selected, LED trigger support not will be
included in libata-core and both, codepaths and structures remain
untouched.
I'm currently deploying this for the oxnas target in OpenWrt
https://dev.openwrt.org/changeset/43675/
v2: rebased to kernel/git/tj/libata.git
plus small corrections and comments added
Signed-off-by: Daniel Golle
URL: https://patchwork.ozlabs.org/patch/420733/
[Aditya Prayoga:
* Port forward
* Change ATA_LEDS default to no
* Reduce performance impact by moving ata_led_act() call from
ata_qc_new() to ata_qc_complete()]
Signed-off-by: Aditya Prayoga
---
If there is anything fundamentally wrong with that approach, I'd be
glad for some advise on how to do it better.
I conciously choose an #ifdev approach to make sure performance will
not be affected for non-users of that code.
Thanks
Daniel
---
---
drivers/ata/Kconfig | 16 ++
drivers/ata/libata-core.c | 56 +++
include/linux/libata.h| 7 ++
3 files changed, 79 insertions(+)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 39b181d..a2c64ce 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -46,6 +46,22 @@ config ATA_VERBOSE_ERROR
If unsure, say Y.
+config ARCH_WANT_LIBATA_LEDS
+ bool
+
+config ATA_LEDS
+ bool "support ATA port LED triggers"
+ depends on ARCH_WANT_LIBATA_LEDS
+ select NEW_LEDS
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
+ default n
+ help
+ This option adds a LED trigger for each registered ATA port.
+ It is used to drive disk activity leds connected via GPIO.
+
+ If unsure, say N.
+
config ATA_ACPI
bool "ATA ACPI Support"
depends on ACPI
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 599e01b..65228f5 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5105,6 +5105,30 @@ void swap_buf_le16(u16 *buf, unsigned int buf_words)
}
/**
+ * ata_led_act - Trigger port activity LED
+ * @ap: indicating port
+ *
+ * Blinks any LEDs registered to the trigger.
+ * Commonly used with leds-gpio on NAS systems with disk activity
+ * indicator LEDs.
+ *
+ * LOCKING:
+ * None.
+ */
+static inline void ata_led_act(struct ata_port *ap)
+{
+#ifdef CONFIG_ATA_LEDS
+#define LIBATA_BLINK_DELAY 20 /* ms */
+ unsigned long led_delay = LIBATA_BLINK_DELAY;
+
+ if (unlikely(!ap->ledtrig))
+ return;
+
+ led_trigger_blink_oneshot(ap->ledtrig, _delay, _delay, 0);
+#endif /* CONFIG_ATA_LEDS */
+}
+
+/**
* ata_qc_new_init - Request an available ATA command, and initialize it
* @dev: Device from whom we request an available command structure
* @tag: tag
@@ -5249,6 +5273,10 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
/* Trigger the LED (if available) */
ledtrig_disk_activity(!!(qc->tf.flags & ATA_TFLAG_WRITE));
+#ifdef CONFIG_ATA_LEDS
+ ata_led_act(ap);
+#endif
+
/* XXX: New EH and old EH use different mechanisms to
* synchronize EH with regular execution path.
*
@@ -6028,6 +6056,9 @@ struct ata_port *ata_port_alloc(struct ata_host *host)
ap->stats.unhandled_irq = 1;
ap->stats.idle_irq = 1;
#endif
+#ifdef CONFIG_ATA_LEDS
+ ap->ledtrig = kzalloc(sizeof(struct led_trigger), GFP_KERNEL);
+#endif
ata_sff_port_init(ap);
return ap;
@@ -6063,6 +6094,12 @@ static void ata_host_release(struct kref *kref)
kfree(ap->pmp_link);
kfree(ap->slave_link);
+#ifdef CONFIG_ATA_LEDS
+ if (ap->ledtrig) {
+ led_trigger_unregister(ap->ledtrig);
+ kfree(ap->ledtrig);
+ };
+#endif
kfree(ap);
host->ports[i] = NULL;
}
@@ -6527,6 +6564,25 @@ int ata_host_register(struct ata_host *host, struct
scsi_host_template *sht)
host->ports[i]->local_port_no = i + 1;
}
+#ifdef CONFIG_ATA_LEDS
+ /* register LED triggers for all ports */
+ for (i = 0; i < host->n_ports; i++) {
+ if (unlikely(!host->ports[i]->ledtrig))
+ continue;
+
+ snprintf(host->ports[i]->ledtrig_name,
+ sizeof(host->ports[i]->ledtrig_name), "ata%u",
+ host->ports[i]->print_id);
+
+ host->ports[i]->ledtrig->name = host->ports[i]->ledtrig_name;
+
+ if (led_trigger_register(host->ports[i]->ledtrig)) {
+ kfree(host->ports[i]->ledtrig);
+
[PATCH 0/2] Add support per ATA port ledtrigger on armada 38x
Hi everyone, This series adds support LED trigger for each ATA port indicating disk activity in Armada 38x. I pick up the work done by Daniel Golle which can be found at [1] Helios4 which is based on Armada 388, has four LEDs designed to indicate disk activity on each SATA ports. As the final switch (CONFIG_ATA_LEDS) to enable the codepath by default is no, it should not affect the rest of Armada 38x based boards. [1] https://patchwork.ozlabs.org/patch/420733/ --- Notes checkpatch.pl complains about "WARNING: please write a paragraph that describes the config symbol fully" but I think the description is clear enough to ignore the warning. Some performance number tested on Western Digital Red 2TB WD20EFRX using fio randrw * CONFIG_ATA_LEDS disabled and selected trigger is none read : iops=326 write : iops=109 * CONFIG_ATA_LEDS disabled and selected trigger is disk-activity read : iops=325 write : iops=108 * CONFIG_ATA_LEDS enabled and selected trigger is ata1 read : iops=325 write : iops=108 --- Aditya Prayoga (1): ARM: mvebu: Enable ARCH_WANT_LIBATA_LEDS in Armada 38x Daniel Golle (1): libata: add ledtrig support arch/arm/mach-mvebu/Kconfig | 1 + drivers/ata/Kconfig | 16 + drivers/ata/libata-core.c | 56 + include/linux/libata.h | 7 ++ 4 files changed, 80 insertions(+) -- 2.7.4
[PATCH 0/2] Add support per ATA port ledtrigger on armada 38x
Hi everyone, This series adds support LED trigger for each ATA port indicating disk activity in Armada 38x. I pick up the work done by Daniel Golle which can be found at [1] Helios4 which is based on Armada 388, has four LEDs designed to indicate disk activity on each SATA ports. As the final switch (CONFIG_ATA_LEDS) to enable the codepath by default is no, it should not affect the rest of Armada 38x based boards. [1] https://patchwork.ozlabs.org/patch/420733/ --- Notes checkpatch.pl complains about "WARNING: please write a paragraph that describes the config symbol fully" but I think the description is clear enough to ignore the warning. Some performance number tested on Western Digital Red 2TB WD20EFRX using fio randrw * CONFIG_ATA_LEDS disabled and selected trigger is none read : iops=326 write : iops=109 * CONFIG_ATA_LEDS disabled and selected trigger is disk-activity read : iops=325 write : iops=108 * CONFIG_ATA_LEDS enabled and selected trigger is ata1 read : iops=325 write : iops=108 --- Aditya Prayoga (1): ARM: mvebu: Enable ARCH_WANT_LIBATA_LEDS in Armada 38x Daniel Golle (1): libata: add ledtrig support arch/arm/mach-mvebu/Kconfig | 1 + drivers/ata/Kconfig | 16 + drivers/ata/libata-core.c | 56 + include/linux/libata.h | 7 ++ 4 files changed, 80 insertions(+) -- 2.7.4
[LKP] [x86/pci] 7ffb31888c: PANIC:early_exception
FYI, we noticed the following commit (built with gcc-7):
commit: 7ffb31888cbaab36ec464fc43ecf5ddecdbd55ac ("[PATCH v7 07/16] x86/pci:
Add Hygon Dhyana support to PCI and north bridge")
url:
https://github.com/0day-ci/linux/commits/Pu-Wen/Add-support-for-Hygon-Dhyana-Family-18h-processor/20180917-214606
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+-+++
| | 89989434ce | 7ffb31888c |
+-+++
| boot_successes | 5 | 6 |
| boot_failures | 1 | 4 |
| BUG:kernel_reboot-without-warning_in_boot_stage | 1 ||
| PANIC:early_exception | 0 | 4 |
| RIP:early_is_amd_nb | 0 | 4 |
| BUG:kernel_hang_in_boot_stage | 0 | 4 |
+-+++
[0.009828] clocksource: kvm-clock: mask: 0x max_cycles:
0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.037528] tsc: Detected 2260.998 MHz processor
[0.057832] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.069238] e820: remove [mem 0x000a-0x000f] usable
[0.800215] AGP: No AGP bridge found
PANIC: early exception 0xe3 IP 10:8294623f error 0 cr2 0x0
[0.815262] CPU: 0 PID: 0 Comm: swapper Not tainted
4.19.0-rc2-00018-g7ffb318 #1
[0.826860] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[0.839894] RIP: 0010:early_is_amd_nb+0x30/0x4b
[0.846986] Code: 15 07 3e c8 ff 0f b7 cf 48 c7 c0 c0 6a 01 82 80 fa 02 74
13 80 fa 09 48 c7 c0 20 69 01 82 ba 00 00 00 00 48 0f 45 c2 c1 ef 10 <8b> 10 85
d2 74 0f 39 ca 75 05 39 78 04 74 09 48 83 c0 20 eb eb 31
[0.876321] RSP: :82403e38 EFLAGS: 00010017 ORIG_RAX:
[0.888131] RAX: RBX: RCX:
[0.899187] RDX: RSI: c000 RDI:
[0.910233] RBP: 0018 R08: 0002 R09:
[0.921388] R10: 829ecc40 R11: 82aeed87 R12:
[0.932476] R13: R14: R15:
[0.943658] FS: () GS:82909000()
knlGS:
[0.956271] CS: 0010 DS: ES: CR0: 80050033
[0.965216] CR2: CR3: 029a2000 CR4: 06a0
[0.976358] Call Trace:
[0.980238] ? early_gart_iommu_check+0xef/0x2c5
[0.987493] ? setup_arch+0x4fa/0xc67
[0.993231] ? printk+0x52/0x6e
[0.998157] ? start_kernel+0x6e/0x4dc
[1.004044] ? load_ucode_bsp+0x42/0x12e
[1.010145] ? secondary_startup_64+0xa4/0xb0
BUG: kernel hang in boot stage
Elapsed time: 700
#!/bin/bash
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.19.0-rc2 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70300
CONFIG_CLANG_VERSION=0
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
[LKP] [x86/pci] 7ffb31888c: PANIC:early_exception
FYI, we noticed the following commit (built with gcc-7):
commit: 7ffb31888cbaab36ec464fc43ecf5ddecdbd55ac ("[PATCH v7 07/16] x86/pci:
Add Hygon Dhyana support to PCI and north bridge")
url:
https://github.com/0day-ci/linux/commits/Pu-Wen/Add-support-for-Hygon-Dhyana-Family-18h-processor/20180917-214606
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+-+++
| | 89989434ce | 7ffb31888c |
+-+++
| boot_successes | 5 | 6 |
| boot_failures | 1 | 4 |
| BUG:kernel_reboot-without-warning_in_boot_stage | 1 ||
| PANIC:early_exception | 0 | 4 |
| RIP:early_is_amd_nb | 0 | 4 |
| BUG:kernel_hang_in_boot_stage | 0 | 4 |
+-+++
[0.009828] clocksource: kvm-clock: mask: 0x max_cycles:
0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.037528] tsc: Detected 2260.998 MHz processor
[0.057832] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.069238] e820: remove [mem 0x000a-0x000f] usable
[0.800215] AGP: No AGP bridge found
PANIC: early exception 0xe3 IP 10:8294623f error 0 cr2 0x0
[0.815262] CPU: 0 PID: 0 Comm: swapper Not tainted
4.19.0-rc2-00018-g7ffb318 #1
[0.826860] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[0.839894] RIP: 0010:early_is_amd_nb+0x30/0x4b
[0.846986] Code: 15 07 3e c8 ff 0f b7 cf 48 c7 c0 c0 6a 01 82 80 fa 02 74
13 80 fa 09 48 c7 c0 20 69 01 82 ba 00 00 00 00 48 0f 45 c2 c1 ef 10 <8b> 10 85
d2 74 0f 39 ca 75 05 39 78 04 74 09 48 83 c0 20 eb eb 31
[0.876321] RSP: :82403e38 EFLAGS: 00010017 ORIG_RAX:
[0.888131] RAX: RBX: RCX:
[0.899187] RDX: RSI: c000 RDI:
[0.910233] RBP: 0018 R08: 0002 R09:
[0.921388] R10: 829ecc40 R11: 82aeed87 R12:
[0.932476] R13: R14: R15:
[0.943658] FS: () GS:82909000()
knlGS:
[0.956271] CS: 0010 DS: ES: CR0: 80050033
[0.965216] CR2: CR3: 029a2000 CR4: 06a0
[0.976358] Call Trace:
[0.980238] ? early_gart_iommu_check+0xef/0x2c5
[0.987493] ? setup_arch+0x4fa/0xc67
[0.993231] ? printk+0x52/0x6e
[0.998157] ? start_kernel+0x6e/0x4dc
[1.004044] ? load_ucode_bsp+0x42/0x12e
[1.010145] ? secondary_startup_64+0xa4/0xb0
BUG: kernel hang in boot stage
Elapsed time: 700
#!/bin/bash
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.19.0-rc2 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70300
CONFIG_CLANG_VERSION=0
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
linux-next: build warning after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but
not used [-Wunused-function]
static int kgdboc_option_setup(char *opt)
^~~
Introduced by commit
2dd453168643 ("kgdboc: Fix restrict error")
--
Cheers,
Stephen Rothwell
pgpqCp4ZgBnER.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but
not used [-Wunused-function]
static int kgdboc_option_setup(char *opt)
^~~
Introduced by commit
2dd453168643 ("kgdboc: Fix restrict error")
--
Cheers,
Stephen Rothwell
pgpqCp4ZgBnER.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On Wed, 19 Sep 2018 11:47:54 +0900 Sergey Senozhatsky wrote: > On (09/18/18 22:43), Steven Rostedt wrote: > > > First - switch to u64 size. > > > Second - check for NULL str. > > > > > I think I would switch it around. Check for NULL first, and then switch > > to u64. It was always an int, do we need to backport converting it to > > u64 to stable? The NULL check is a definite, the overflow of int > > shouldn't crash anything. > > Agreed. This order makes much more sense. Do you mind, tho, to have > "unsigned int size" in the first patch along with NULL str check? > Just to silent the checkpatch. > I guess that doesn't hurt. I'd personally would keep it separate (just fix what's broken), but it's such a slight change, I don't have any strong feelings about it. Thanks, -- Steve
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On Wed, 19 Sep 2018 11:47:54 +0900 Sergey Senozhatsky wrote: > On (09/18/18 22:43), Steven Rostedt wrote: > > > First - switch to u64 size. > > > Second - check for NULL str. > > > > > I think I would switch it around. Check for NULL first, and then switch > > to u64. It was always an int, do we need to backport converting it to > > u64 to stable? The NULL check is a definite, the overflow of int > > shouldn't crash anything. > > Agreed. This order makes much more sense. Do you mind, tho, to have > "unsigned int size" in the first patch along with NULL str check? > Just to silent the checkpatch. > I guess that doesn't hurt. I'd personally would keep it separate (just fix what's broken), but it's such a slight change, I don't have any strong feelings about it. Thanks, -- Steve
Re: [PATCH v2 00/22] Unify MediaTek pinctrl in preparation for MT8183 and MT6765
On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote: > On Sat, Sep 8, 2018 at 4:07 AM wrote: > > > v2 and changes since v1: > > I had trouble applying the last patches in the series so I applied > all on an immutable branch (ib-mtk) then merged that into devel > and added a patch on top to fix up some GPIO includes (just sent). > > Please check the result! > Sure, I'll take a look and and test on the devel branch. On the top, I'll add a fix for the issue recently reported by kbuild test robot about implicit declaration and a new MT6765 driver based on the series. > Yours, > Linus Walleij
Re: [PATCH v2 00/22] Unify MediaTek pinctrl in preparation for MT8183 and MT6765
On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote: > On Sat, Sep 8, 2018 at 4:07 AM wrote: > > > v2 and changes since v1: > > I had trouble applying the last patches in the series so I applied > all on an immutable branch (ib-mtk) then merged that into devel > and added a patch on top to fix up some GPIO includes (just sent). > > Please check the result! > Sure, I'll take a look and and test on the devel branch. On the top, I'll add a fix for the issue recently reported by kbuild test robot about implicit declaration and a new MT6765 driver based on the series. > Yours, > Linus Walleij
Re: [PATCH V5 2/3] dt-bindings: interrupt-controller: C-SKY APB intc
On Tue, Sep 18, 2018 at 05:56:50PM -0700, Rob Herring wrote: > > > but does need a vendor prefix. > > vendor prefix? Em ... it's just used in fpga now. > > What I mean is make it: csky,support-pulse-signal Ok. no problem. Best Regards Guo Ren
Re: [PATCH V5 2/3] dt-bindings: interrupt-controller: C-SKY APB intc
On Tue, Sep 18, 2018 at 05:56:50PM -0700, Rob Herring wrote: > > > but does need a vendor prefix. > > vendor prefix? Em ... it's just used in fpga now. > > What I mean is make it: csky,support-pulse-signal Ok. no problem. Best Regards Guo Ren
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On (09/18/18 22:43), Steven Rostedt wrote: > > First - switch to u64 size. > > Second - check for NULL str. > > > I think I would switch it around. Check for NULL first, and then switch > to u64. It was always an int, do we need to backport converting it to > u64 to stable? The NULL check is a definite, the overflow of int > shouldn't crash anything. Agreed. This order makes much more sense. Do you mind, tho, to have "unsigned int size" in the first patch along with NULL str check? Just to silent the checkpatch. -ss
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On (09/18/18 22:43), Steven Rostedt wrote: > > First - switch to u64 size. > > Second - check for NULL str. > > > I think I would switch it around. Check for NULL first, and then switch > to u64. It was always an int, do we need to backport converting it to > u64 to stable? The NULL check is a definite, the overflow of int > shouldn't crash anything. Agreed. This order makes much more sense. Do you mind, tho, to have "unsigned int size" in the first patch along with NULL str check? Just to silent the checkpatch. -ss
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On Wed, 19 Sep 2018 11:39:32 +0900
Sergey Senozhatsky wrote:
> On (09/19/18 10:27), He Zhe wrote:
> > On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > > On (09/19/18 01:17), zhe...@windriver.com wrote:
> > >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned
> > >> size)
> > >> /* save requested log_buf_len since it's too early to process it */
> > >> static int __init log_buf_len_setup(char *str)
> > >> {
> > >> -unsigned size = memparse(str, );
> > >> +unsigned size;
> > > unsigned int size;
> >
> > This is in v1 but then Steven suggested that it should be split out
> > and only keep the pure fix part here.
>
> Ah, I see.
>
> Hmm... memparse() returns u64 value. A user *probably* can ask the kernel
> to allocate log_buf larger than 'unsigned int'.
>
> So may be I'd do two fixes here:
>
> First - switch to u64 size.
> Second - check for NULL str.
>
>
> Steven, Petr, what do you think?
>
I think I would switch it around. Check for NULL first, and then switch
to u64. It was always an int, do we need to backport converting it to
u64 to stable? The NULL check is a definite, the overflow of int
shouldn't crash anything.
-- Steve
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On Wed, 19 Sep 2018 11:39:32 +0900
Sergey Senozhatsky wrote:
> On (09/19/18 10:27), He Zhe wrote:
> > On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > > On (09/19/18 01:17), zhe...@windriver.com wrote:
> > >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned
> > >> size)
> > >> /* save requested log_buf_len since it's too early to process it */
> > >> static int __init log_buf_len_setup(char *str)
> > >> {
> > >> -unsigned size = memparse(str, );
> > >> +unsigned size;
> > > unsigned int size;
> >
> > This is in v1 but then Steven suggested that it should be split out
> > and only keep the pure fix part here.
>
> Ah, I see.
>
> Hmm... memparse() returns u64 value. A user *probably* can ask the kernel
> to allocate log_buf larger than 'unsigned int'.
>
> So may be I'd do two fixes here:
>
> First - switch to u64 size.
> Second - check for NULL str.
>
>
> Steven, Petr, what do you think?
>
I think I would switch it around. Check for NULL first, and then switch
to u64. It was always an int, do we need to backport converting it to
u64 to stable? The NULL check is a definite, the overflow of int
shouldn't crash anything.
-- Steve
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len since it's too early to process it */
> >> static int __init log_buf_len_setup(char *str)
> >> {
> >> - unsigned size = memparse(str, );
> >> + unsigned size;
> > unsigned int size;
>
> This is in v1 but then Steven suggested that it should be split out
> and only keep the pure fix part here.
Ah, I see.
Hmm... memparse() returns u64 value. A user *probably* can ask the kernel
to allocate log_buf larger than 'unsigned int'.
So may be I'd do two fixes here:
First - switch to u64 size.
Second - check for NULL str.
Steven, Petr, what do you think?
-ss
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On (09/19/18 10:27), He Zhe wrote:
> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> > On (09/19/18 01:17), zhe...@windriver.com wrote:
> >> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> >> /* save requested log_buf_len since it's too early to process it */
> >> static int __init log_buf_len_setup(char *str)
> >> {
> >> - unsigned size = memparse(str, );
> >> + unsigned size;
> > unsigned int size;
>
> This is in v1 but then Steven suggested that it should be split out
> and only keep the pure fix part here.
Ah, I see.
Hmm... memparse() returns u64 value. A user *probably* can ask the kernel
to allocate log_buf larger than 'unsigned int'.
So may be I'd do two fixes here:
First - switch to u64 size.
Second - check for NULL str.
Steven, Petr, what do you think?
-ss
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> On (09/19/18 01:17), zhe...@windriver.com wrote:
>> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
>> /* save requested log_buf_len since it's too early to process it */
>> static int __init log_buf_len_setup(char *str)
>> {
>> -unsigned size = memparse(str, );
>> +unsigned size;
> unsigned int size;
This is in v1 but then Steven suggested that it should be split out
and only keep the pure fix part here.
>
>> +if (!str) {
>> +pr_err("Config string not provided\n");
> pr_debug() may be?
>
> It's not clear from this error message which one of the "config strings"
> was not provided. Besides, I think "config string" is misleading and in
> fact it's a "boot command line parameter". But, dunno, I guess I'd just
> drop that print out.
I'm OK with dropping it. Anyway it'd get "Malformed early
option 'log_buf_len'" from early_param later.
I'll send v3. Thank you.
Zhe
>
> Otherwise,
>
> Acked-by: Sergey Senozhatsky
>
> -ss
>
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> On (09/19/18 01:17), zhe...@windriver.com wrote:
>> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
>> /* save requested log_buf_len since it's too early to process it */
>> static int __init log_buf_len_setup(char *str)
>> {
>> -unsigned size = memparse(str, );
>> +unsigned size;
> unsigned int size;
This is in v1 but then Steven suggested that it should be split out
and only keep the pure fix part here.
>
>> +if (!str) {
>> +pr_err("Config string not provided\n");
> pr_debug() may be?
>
> It's not clear from this error message which one of the "config strings"
> was not provided. Besides, I think "config string" is misleading and in
> fact it's a "boot command line parameter". But, dunno, I guess I'd just
> drop that print out.
I'm OK with dropping it. Anyway it'd get "Malformed early
option 'log_buf_len'" from early_param later.
I'll send v3. Thank you.
Zhe
>
> Otherwise,
>
> Acked-by: Sergey Senozhatsky
>
> -ss
>
Re: [PATCH v2 2/2] printk: Add KBUILD_MODNAME and correct bare use of unsigned
On (09/19/18 01:17), zhe...@windriver.com wrote:
> Add KBUILD_MODNAME to make prints more clear.
No strong opinion. I'm OK with this change.
> And use 'unsigned int' intead of 'unsigned' according to
> checkpatch.pl's suggestion.
I don't think that "unsigned int" is the right thing to use there.
> if (console_seq < log_first_seq) {
> len = sprintf(text, "** %u printk messages dropped
> **\n",
> - (unsigned)(log_first_seq - console_seq));
> +(unsigned int)(log_first_seq - console_seq));
Both log_first_seq and console_seq are u64.
log_first_seq - console_seq
thus, *in theory*, can be larger than "unsigned int". So I'd just avoid cast
and use an appropriate for u64 %llu sprintf() specifier. Something like below,
perhaps:
---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index f73ea9dd6f46..4b8c5832bf14 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2408,8 +2408,9 @@ void console_unlock(void)
printk_safe_enter_irqsave(flags);
raw_spin_lock(_lock);
if (console_seq < log_first_seq) {
- len = sprintf(text, "** %u printk messages dropped
**\n",
- (unsigned int)(log_first_seq - console_seq));
+ len = sprintf(text,
+ "** %llu printk messages dropped **\n",
+ log_first_seq - console_seq);
/* messages are gone, move to first one */
console_seq = log_first_seq;
---
Steven, Petr, any objections?
-ss
Re: [PATCH v2 2/2] printk: Add KBUILD_MODNAME and correct bare use of unsigned
On (09/19/18 01:17), zhe...@windriver.com wrote:
> Add KBUILD_MODNAME to make prints more clear.
No strong opinion. I'm OK with this change.
> And use 'unsigned int' intead of 'unsigned' according to
> checkpatch.pl's suggestion.
I don't think that "unsigned int" is the right thing to use there.
> if (console_seq < log_first_seq) {
> len = sprintf(text, "** %u printk messages dropped
> **\n",
> - (unsigned)(log_first_seq - console_seq));
> +(unsigned int)(log_first_seq - console_seq));
Both log_first_seq and console_seq are u64.
log_first_seq - console_seq
thus, *in theory*, can be larger than "unsigned int". So I'd just avoid cast
and use an appropriate for u64 %llu sprintf() specifier. Something like below,
perhaps:
---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index f73ea9dd6f46..4b8c5832bf14 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2408,8 +2408,9 @@ void console_unlock(void)
printk_safe_enter_irqsave(flags);
raw_spin_lock(_lock);
if (console_seq < log_first_seq) {
- len = sprintf(text, "** %u printk messages dropped
**\n",
- (unsigned int)(log_first_seq - console_seq));
+ len = sprintf(text,
+ "** %llu printk messages dropped **\n",
+ log_first_seq - console_seq);
/* messages are gone, move to first one */
console_seq = log_first_seq;
---
Steven, Petr, any objections?
-ss
[PATCH v5] EDAC, ghes: use CPER module handles to locate DIMMs
For platforms whose firmwares provide valid module handles
(SMBIOS type 17) in error records, this patch uses the module
handles to locate corresponding DIMMs and enables per-DIMM
error counter update.
Signed-off-by: Fan Wu
Reviewed-by: Tyler Baicar
Reviewed-by: James Morse
Tested-by: Toshi Kani
---
Changes from v4:
Changes from v3:
* Updated Reviewed-by list
Changes from v2:
* Fixed coding style glitch
* Added Tested-by/Reviewed-by
Changes from v1:
* Changed the new function name to get_dimm_smbios_index
* Removed unnecessary checks inside get_dimm_smbios_index
* Reverted the change of the DMI handle print
* Updated commit message
---
drivers/edac/ghes_edac.c | 23 +++
include/linux/edac.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 473aeec..ba46160 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -81,6 +81,18 @@ static void ghes_edac_count_dimms(const struct dmi_header
*dh, void *arg)
(*num_dimm)++;
}
+static int get_dimm_smbios_index(u16 handle)
+{
+ int i;
+ struct mem_ctl_info *mci = ghes_pvt->mci;
+
+ for (i = 0; i < mci->tot_dimms; i++) {
+ if (mci->dimms[i]->smbios_handle == handle)
+ return i;
+ }
+ return -1;
+}
+
static void ghes_edac_dmidecode(const struct dmi_header *dh, void *arg)
{
struct ghes_edac_dimm_fill *dimm_fill = arg;
@@ -177,6 +189,8 @@ static void ghes_edac_dmidecode(const struct dmi_header
*dh, void *arg)
entry->total_width, entry->data_width);
}
+ dimm->smbios_handle = entry->handle;
+
dimm_fill->count++;
}
}
@@ -327,12 +341,21 @@ void ghes_edac_report_mem_error(int sev, struct
cper_sec_mem_err *mem_err)
p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
if (mem_err->validation_bits & CPER_MEM_VALID_MODULE_HANDLE) {
const char *bank = NULL, *device = NULL;
+ int index = -1;
+
dmi_memdev_name(mem_err->mem_dev_handle, , );
if (bank != NULL && device != NULL)
p += sprintf(p, "DIMM location:%s %s ", bank, device);
else
p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
mem_err->mem_dev_handle);
+
+ index = get_dimm_smbios_index(mem_err->mem_dev_handle);
+ if (index >= 0) {
+ e->top_layer = index;
+ e->enable_per_layer_report = true;
+ }
+
}
if (p > e->location)
*(p - 1) = '\0';
diff --git a/include/linux/edac.h b/include/linux/edac.h
index bffb978..a45ce1f 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -451,6 +451,8 @@ struct dimm_info {
u32 nr_pages; /* number of pages on this dimm */
unsigned csrow, cschannel; /* Points to the old API data */
+
+ u16 smbios_handle; /* Handle for SMBIOS type 17 */
};
/**
--
2.7.4
[PATCH v5] EDAC, ghes: use CPER module handles to locate DIMMs
For platforms whose firmwares provide valid module handles
(SMBIOS type 17) in error records, this patch uses the module
handles to locate corresponding DIMMs and enables per-DIMM
error counter update.
Signed-off-by: Fan Wu
Reviewed-by: Tyler Baicar
Reviewed-by: James Morse
Tested-by: Toshi Kani
---
Changes from v4:
Changes from v3:
* Updated Reviewed-by list
Changes from v2:
* Fixed coding style glitch
* Added Tested-by/Reviewed-by
Changes from v1:
* Changed the new function name to get_dimm_smbios_index
* Removed unnecessary checks inside get_dimm_smbios_index
* Reverted the change of the DMI handle print
* Updated commit message
---
drivers/edac/ghes_edac.c | 23 +++
include/linux/edac.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 473aeec..ba46160 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -81,6 +81,18 @@ static void ghes_edac_count_dimms(const struct dmi_header
*dh, void *arg)
(*num_dimm)++;
}
+static int get_dimm_smbios_index(u16 handle)
+{
+ int i;
+ struct mem_ctl_info *mci = ghes_pvt->mci;
+
+ for (i = 0; i < mci->tot_dimms; i++) {
+ if (mci->dimms[i]->smbios_handle == handle)
+ return i;
+ }
+ return -1;
+}
+
static void ghes_edac_dmidecode(const struct dmi_header *dh, void *arg)
{
struct ghes_edac_dimm_fill *dimm_fill = arg;
@@ -177,6 +189,8 @@ static void ghes_edac_dmidecode(const struct dmi_header
*dh, void *arg)
entry->total_width, entry->data_width);
}
+ dimm->smbios_handle = entry->handle;
+
dimm_fill->count++;
}
}
@@ -327,12 +341,21 @@ void ghes_edac_report_mem_error(int sev, struct
cper_sec_mem_err *mem_err)
p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
if (mem_err->validation_bits & CPER_MEM_VALID_MODULE_HANDLE) {
const char *bank = NULL, *device = NULL;
+ int index = -1;
+
dmi_memdev_name(mem_err->mem_dev_handle, , );
if (bank != NULL && device != NULL)
p += sprintf(p, "DIMM location:%s %s ", bank, device);
else
p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
mem_err->mem_dev_handle);
+
+ index = get_dimm_smbios_index(mem_err->mem_dev_handle);
+ if (index >= 0) {
+ e->top_layer = index;
+ e->enable_per_layer_report = true;
+ }
+
}
if (p > e->location)
*(p - 1) = '\0';
diff --git a/include/linux/edac.h b/include/linux/edac.h
index bffb978..a45ce1f 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -451,6 +451,8 @@ struct dimm_info {
u32 nr_pages; /* number of pages on this dimm */
unsigned csrow, cschannel; /* Points to the old API data */
+
+ u16 smbios_handle; /* Handle for SMBIOS type 17 */
};
/**
--
2.7.4
Re: [PATCH 2/2] mm: zero remaining unavailable struct pages
On Mon, Sep 17, 2018 at 09:26:07AM -0400, Masayoshi Mizuma wrote:
> On Fri, Aug 31, 2018 at 02:55:36AM +, Naoya Horiguchi wrote:
> > On Wed, Aug 29, 2018 at 11:16:30AM -0400, Masayoshi Mizuma wrote:
> > > Hi Horiguchi-san and Pavel
> > >
> > > Thank you for your comments!
> > > The Pavel's additional patch looks good to me, so I will add it to this
> > > series.
> > >
> > > However, unfortunately, the movable_node option has something wrong yet...
> > > When I offline the memory which belongs to movable zone, I got the
> > > following
> > > warning. I'm trying to debug it.
> > >
> > > I try to describe the issue as following.
> > > If you have any comments, please let me know.
> > >
> > > WARNING: CPU: 156 PID: 25611 at mm/page_alloc.c:7730
> > > has_unmovable_pages+0x1bf/0x200
> > > RIP: 0010:has_unmovable_pages+0x1bf/0x200
> > > ...
> > > Call Trace:
> > > is_mem_section_removable+0xd3/0x160
> > > show_mem_removable+0x8e/0xb0
> > > dev_attr_show+0x1c/0x50
> > > sysfs_kf_seq_show+0xb3/0x110
> > > seq_read+0xee/0x480
> > > __vfs_read+0x36/0x190
> > > vfs_read+0x89/0x130
> > > ksys_read+0x52/0xc0
> > > do_syscall_64+0x5b/0x180
> > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7fe7b7823f70
> > > ...
> > >
> > > I added a printk to catch the unmovable page.
> > > ---
> > > @@ -7713,8 +7719,12 @@ bool has_unmovable_pages(struct zone *zone, struct
> > > page *page, int count,
> > > * is set to both of a memory hole page and a _used_
> > > kernel
> > > * page at boot.
> > > */
> > > - if (found > count)
> > > + if (found > count) {
> > > + pr_info("DEBUG: %s zone: %lx page: %lx pfn: %lx
> > > flags: %lx found: %ld count: %ld \n",
> > > + __func__, zone, page, page_to_pfn(page),
> > > page->flags, found, count);
> > > goto unmovable;
> > > + }
> > > ---
> > >
> > > Then I got the following. The page (PFN: 0x1c0ff130d) flag is
> > > 0xdfc0040048 (uptodate|active|swapbacked)
> > >
> > > ---
> > > DEBUG: has_unmovable_pages zone: 0x8c080380 page:
> > > 0xea703fc4c340 pfn: 0x1c0ff130d flags: 0xdfc0040048 found: 1
> > > count: 0
> > > ---
> > >
> > > And I got the owner from /sys/kernel/debug/page_owner.
> > >
> > > Page allocated via order 0, mask 0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO)
> > > PFN 7532909325 type Movable Block 14712713 type Movable Flags
> > > 0xdfc0040048(uptodate|active|swapbacked)
> > > __alloc_pages_nodemask+0xfc/0x270
> > > alloc_pages_vma+0x7c/0x1e0
> > > handle_pte_fault+0x399/0xe50
> > > __handle_mm_fault+0x38e/0x520
> > > handle_mm_fault+0xdc/0x210
> > > __do_page_fault+0x243/0x4c0
> > > do_page_fault+0x31/0x130
> > > page_fault+0x1e/0x30
> > >
> > > The page is allocated as anonymous page via page fault.
> > > I'm not sure, but lru flag should be added to the page...?
> >
> > There is a small window of no PageLRU flag just after page allocation
> > until the page is linked to some LRU list.
> > This kind of unmovability is transient, so retrying can work.
> >
> > I guess that this warning seems to be visible since commit 15c30bc09085
> > ("mm, memory_hotplug: make has_unmovable_pages more robust")
> > which turned off the optimization based on the assumption that pages
> > under ZONE_MOVABLE are always movable.
> > I think that it helps developers find the issue that permanently
> > unmovable pages are accidentally located in ZONE_MOVABLE zone.
> > But even ZONE_MOVABLE zone could have transiently unmovable pages,
> > so the reported warning seems to me a false charge and should be avoided.
> > Doing lru_add_drain_all()/drain_all_pages() before has_unmovable_pages()
> > might be helpful?
>
> Thanks you for your proposal! And sorry for delayed responce.
>
> lru_add_drain_all()/drain_all_pages() might be helpful, but it
> seems that the window is not very small because I tried to do
> offline some times, and every offline failed...
OK, so this doesn't work, thank you for trying.
>
> I have another idea. I found that if the page is belonged to
> Movable zone and it has Uptodate flag, the page will go lru
> soon, so I think we can pass the page.
> Does the idea make sence? As far as I tested it, it works well.
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 52d9efe8c9fb..ecf87bec8ac6 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7758,6 +7758,9 @@ bool has_unmovable_pages(struct zone *zone, struct page
> *page, int count,
> if (__PageMovable(page))
> continue;
>
> + if ((zone_idx(zone) == ZONE_MOVABLE) && PageUptodate(page))
> + continue;
> +
We have many call sites calling SetPageUptodate (many are from filesystems,)
so I'm concerned that some caller might set PageUptodate on non-LRU pages.
Could you explain a little more how/why
Re: [PATCH 2/2] mm: zero remaining unavailable struct pages
On Mon, Sep 17, 2018 at 09:26:07AM -0400, Masayoshi Mizuma wrote:
> On Fri, Aug 31, 2018 at 02:55:36AM +, Naoya Horiguchi wrote:
> > On Wed, Aug 29, 2018 at 11:16:30AM -0400, Masayoshi Mizuma wrote:
> > > Hi Horiguchi-san and Pavel
> > >
> > > Thank you for your comments!
> > > The Pavel's additional patch looks good to me, so I will add it to this
> > > series.
> > >
> > > However, unfortunately, the movable_node option has something wrong yet...
> > > When I offline the memory which belongs to movable zone, I got the
> > > following
> > > warning. I'm trying to debug it.
> > >
> > > I try to describe the issue as following.
> > > If you have any comments, please let me know.
> > >
> > > WARNING: CPU: 156 PID: 25611 at mm/page_alloc.c:7730
> > > has_unmovable_pages+0x1bf/0x200
> > > RIP: 0010:has_unmovable_pages+0x1bf/0x200
> > > ...
> > > Call Trace:
> > > is_mem_section_removable+0xd3/0x160
> > > show_mem_removable+0x8e/0xb0
> > > dev_attr_show+0x1c/0x50
> > > sysfs_kf_seq_show+0xb3/0x110
> > > seq_read+0xee/0x480
> > > __vfs_read+0x36/0x190
> > > vfs_read+0x89/0x130
> > > ksys_read+0x52/0xc0
> > > do_syscall_64+0x5b/0x180
> > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7fe7b7823f70
> > > ...
> > >
> > > I added a printk to catch the unmovable page.
> > > ---
> > > @@ -7713,8 +7719,12 @@ bool has_unmovable_pages(struct zone *zone, struct
> > > page *page, int count,
> > > * is set to both of a memory hole page and a _used_
> > > kernel
> > > * page at boot.
> > > */
> > > - if (found > count)
> > > + if (found > count) {
> > > + pr_info("DEBUG: %s zone: %lx page: %lx pfn: %lx
> > > flags: %lx found: %ld count: %ld \n",
> > > + __func__, zone, page, page_to_pfn(page),
> > > page->flags, found, count);
> > > goto unmovable;
> > > + }
> > > ---
> > >
> > > Then I got the following. The page (PFN: 0x1c0ff130d) flag is
> > > 0xdfc0040048 (uptodate|active|swapbacked)
> > >
> > > ---
> > > DEBUG: has_unmovable_pages zone: 0x8c080380 page:
> > > 0xea703fc4c340 pfn: 0x1c0ff130d flags: 0xdfc0040048 found: 1
> > > count: 0
> > > ---
> > >
> > > And I got the owner from /sys/kernel/debug/page_owner.
> > >
> > > Page allocated via order 0, mask 0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO)
> > > PFN 7532909325 type Movable Block 14712713 type Movable Flags
> > > 0xdfc0040048(uptodate|active|swapbacked)
> > > __alloc_pages_nodemask+0xfc/0x270
> > > alloc_pages_vma+0x7c/0x1e0
> > > handle_pte_fault+0x399/0xe50
> > > __handle_mm_fault+0x38e/0x520
> > > handle_mm_fault+0xdc/0x210
> > > __do_page_fault+0x243/0x4c0
> > > do_page_fault+0x31/0x130
> > > page_fault+0x1e/0x30
> > >
> > > The page is allocated as anonymous page via page fault.
> > > I'm not sure, but lru flag should be added to the page...?
> >
> > There is a small window of no PageLRU flag just after page allocation
> > until the page is linked to some LRU list.
> > This kind of unmovability is transient, so retrying can work.
> >
> > I guess that this warning seems to be visible since commit 15c30bc09085
> > ("mm, memory_hotplug: make has_unmovable_pages more robust")
> > which turned off the optimization based on the assumption that pages
> > under ZONE_MOVABLE are always movable.
> > I think that it helps developers find the issue that permanently
> > unmovable pages are accidentally located in ZONE_MOVABLE zone.
> > But even ZONE_MOVABLE zone could have transiently unmovable pages,
> > so the reported warning seems to me a false charge and should be avoided.
> > Doing lru_add_drain_all()/drain_all_pages() before has_unmovable_pages()
> > might be helpful?
>
> Thanks you for your proposal! And sorry for delayed responce.
>
> lru_add_drain_all()/drain_all_pages() might be helpful, but it
> seems that the window is not very small because I tried to do
> offline some times, and every offline failed...
OK, so this doesn't work, thank you for trying.
>
> I have another idea. I found that if the page is belonged to
> Movable zone and it has Uptodate flag, the page will go lru
> soon, so I think we can pass the page.
> Does the idea make sence? As far as I tested it, it works well.
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 52d9efe8c9fb..ecf87bec8ac6 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7758,6 +7758,9 @@ bool has_unmovable_pages(struct zone *zone, struct page
> *page, int count,
> if (__PageMovable(page))
> continue;
>
> + if ((zone_idx(zone) == ZONE_MOVABLE) && PageUptodate(page))
> + continue;
> +
We have many call sites calling SetPageUptodate (many are from filesystems,)
so I'm concerned that some caller might set PageUptodate on non-LRU pages.
Could you explain a little more how/why
Re: [PATCH] ASoC: qcom: Fix a uninitialized warning.
On 2018/9/19 1:17, Andy Gross wrote: > On Tue, Sep 18, 2018 at 01:06:48PM +0800, zhong jiang wrote: >> Fix the following compile warning: >> >> drivers/soc/qcom/cmd-db.c:194:38: warning: 'ent.addr' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> return ret < 0 ? 0 : le32_to_cpu(ent.addr); >> >> drivers/soc/qcom/cmd-db.c:247:38: warning: 'ent.len' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> return ret < 0 ? 0 : le16_to_cpu(ent.len); >> >> drivers/soc/qcom/cmd-db.c:269:24: warning: 'ent.addr' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> addr = le32_to_cpu(ent.addr); >> >> Signed-off-by: zhong jiang >> --- >> drivers/soc/qcom/cmd-db.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > This is kind of an odd subject for the patch. It should be something like > drivers: qcom: cmd-db: X > > ASOC is sound related. Thank you for your reply and review. I will update the subject and repost. Sincerely, zhong jiang > > Regards, > > Andy > >
Re: [PATCH] ASoC: qcom: Fix a uninitialized warning.
On 2018/9/19 1:17, Andy Gross wrote: > On Tue, Sep 18, 2018 at 01:06:48PM +0800, zhong jiang wrote: >> Fix the following compile warning: >> >> drivers/soc/qcom/cmd-db.c:194:38: warning: 'ent.addr' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> return ret < 0 ? 0 : le32_to_cpu(ent.addr); >> >> drivers/soc/qcom/cmd-db.c:247:38: warning: 'ent.len' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> return ret < 0 ? 0 : le16_to_cpu(ent.len); >> >> drivers/soc/qcom/cmd-db.c:269:24: warning: 'ent.addr' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> addr = le32_to_cpu(ent.addr); >> >> Signed-off-by: zhong jiang >> --- >> drivers/soc/qcom/cmd-db.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > This is kind of an odd subject for the patch. It should be something like > drivers: qcom: cmd-db: X > > ASOC is sound related. Thank you for your reply and review. I will update the subject and repost. Sincerely, zhong jiang > > Regards, > > Andy > >
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On (09/19/18 01:17), zhe...@windriver.com wrote:
> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> /* save requested log_buf_len since it's too early to process it */
> static int __init log_buf_len_setup(char *str)
> {
> - unsigned size = memparse(str, );
> + unsigned size;
unsigned int size;
> + if (!str) {
> + pr_err("Config string not provided\n");
pr_debug() may be?
It's not clear from this error message which one of the "config strings"
was not provided. Besides, I think "config string" is misleading and in
fact it's a "boot command line parameter". But, dunno, I guess I'd just
drop that print out.
Otherwise,
Acked-by: Sergey Senozhatsky
-ss
Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line
On (09/19/18 01:17), zhe...@windriver.com wrote:
> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
> /* save requested log_buf_len since it's too early to process it */
> static int __init log_buf_len_setup(char *str)
> {
> - unsigned size = memparse(str, );
> + unsigned size;
unsigned int size;
> + if (!str) {
> + pr_err("Config string not provided\n");
pr_debug() may be?
It's not clear from this error message which one of the "config strings"
was not provided. Besides, I think "config string" is misleading and in
fact it's a "boot command line parameter". But, dunno, I guess I'd just
drop that print out.
Otherwise,
Acked-by: Sergey Senozhatsky
-ss
Re: [PATCH 14/33] vfs: Implement a filesystem superblock creation/configuration context [ver #11]
On (09/19/18 10:12), Sergey Senozhatsky wrote:
> On (09/18/18 07:06), Guenter Roeck wrote:
> > > So the check either better be
> > >
> > > if (fc->ops && fc->ops->reconfigure)
> > >
> >
> > Since there are multiple instances of fs_context where fc->ops isn't set,
> > this check would be needed wherever fc->ops is dereferenced.
>
> Right. If fc is always guaranteed to be properly zeroed-out. This is
> true for kzalloc-ed fc's, but not necessarily so in any other case.
What I mean was something like this
void foo(void)
{
struct fs_context fc;
fc.purpose = ...;
fc.fs_type = ...;
fc.root = ...;
fc.sb_flags = ...;
reconfigure_super();
}
-ss
Re: [PATCH 14/33] vfs: Implement a filesystem superblock creation/configuration context [ver #11]
On (09/19/18 10:12), Sergey Senozhatsky wrote:
> On (09/18/18 07:06), Guenter Roeck wrote:
> > > So the check either better be
> > >
> > > if (fc->ops && fc->ops->reconfigure)
> > >
> >
> > Since there are multiple instances of fs_context where fc->ops isn't set,
> > this check would be needed wherever fc->ops is dereferenced.
>
> Right. If fc is always guaranteed to be properly zeroed-out. This is
> true for kzalloc-ed fc's, but not necessarily so in any other case.
What I mean was something like this
void foo(void)
{
struct fs_context fc;
fc.purpose = ...;
fc.fs_type = ...;
fc.root = ...;
fc.sb_flags = ...;
reconfigure_super();
}
-ss
[PATCH 1/2] pinctrl: tegra: do not export tegra_pinctrl_probe
No user of tegra_pinctrl_probe can be built as a module, hence exporting the symbol is not necessary. Drop EXPORT_SYMBOL_GPL. Signed-off-by: Stefan Agner --- drivers/pinctrl/tegra/pinctrl-tegra.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c b/drivers/pinctrl/tegra/pinctrl-tegra.c index 1aba75897d147..a5008c066bac2 100644 --- a/drivers/pinctrl/tegra/pinctrl-tegra.c +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c @@ -737,4 +737,3 @@ int tegra_pinctrl_probe(struct platform_device *pdev, return 0; } -EXPORT_SYMBOL_GPL(tegra_pinctrl_probe); -- 2.19.0
[PATCH 1/2] pinctrl: tegra: do not export tegra_pinctrl_probe
No user of tegra_pinctrl_probe can be built as a module, hence exporting the symbol is not necessary. Drop EXPORT_SYMBOL_GPL. Signed-off-by: Stefan Agner --- drivers/pinctrl/tegra/pinctrl-tegra.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c b/drivers/pinctrl/tegra/pinctrl-tegra.c index 1aba75897d147..a5008c066bac2 100644 --- a/drivers/pinctrl/tegra/pinctrl-tegra.c +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c @@ -737,4 +737,3 @@ int tegra_pinctrl_probe(struct platform_device *pdev, return 0; } -EXPORT_SYMBOL_GPL(tegra_pinctrl_probe); -- 2.19.0
