Re: [PATCHv3] x86/boot/KASLR: skip the specified crashkernel region
On Tue, Apr 2, 2019 at 1:20 PM Chao Fan wrote:
>
> On Tue, Apr 02, 2019 at 12:10:46PM +0800, Pingfan Liu wrote:
> >crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> or or?
> >fail to reserve the required memory region if KASLR puts kernel into the
> >region. To avoid this uncertainty, asking KASLR to skip the required
> >region.
> >
> >Signed-off-by: Pingfan Liu
> >Cc: Thomas Gleixner
> >Cc: Ingo Molnar
> >Cc: Borislav Petkov
> >Cc: "H. Peter Anvin"
> >Cc: Baoquan He
> >Cc: Will Deacon
> >Cc: Nicolas Pitre
> >Cc: Pingfan Liu
> >Cc: Chao Fan
> >Cc: "Kirill A. Shutemov"
> >Cc: Ard Biesheuvel
> >Cc: linux-kernel@vger.kernel.org
> >---
> [...]
> >+
> >+/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset
> >options */
>
> Before review, I want to say more about the background.
> It's very hard to review the code for someone who is not so familiar
> with kdump, so could you please explain more ahout
> the uasge of crashkernel=range1:size1[,range2:size2,...]@offset.
> And also there are so many jobs who are parsing string. So I really
> need your help to understand the PATCH.
>
> >+static void mem_avoid_specified_crashkernel_region(char *option)
> >+{
> >+ unsigned long long crash_size, crash_base = 0;
> >+ char*first_colon, *first_space, *cur = option;
> Is there a tab after char?
> >+
> >+ first_colon = strchr(option, ':');
> >+ first_space = strchr(option, ' ');
> >+ /* if contain ":" */
> >+ if (first_colon && (!first_space || first_colon < first_space)) {
> >+ int i;
> >+ u64 total_sz = 0;
> >+ struct boot_e820_entry *entry;
> >+
> >+ for (i = 0; i < boot_params->e820_entries; i++) {
> >+ entry = &boot_params->e820_table[i];
> >+ /* Skip non-RAM entries. */
> >+ if (entry->type != E820_TYPE_RAM)
> >+ continue;
> >+ total_sz += entry->size;
> I wonder whether it's needed to consider the memory ranges here.
> I think it's OK to only record the regions should to be avoid.
Maybe not catch you exactly. In the case of
crashkernel=range1:size1[,range2:size2,...]@offset, the size of avoid
region depends on the size of total system ram.
> I remeber I ever talked with Baoquan about the similiar problems.
> @Baoquan, I am not sure if I misunderstand something.
>
> Thanks,
> Chao Fan
> >+ }
> >+ handle_crashkernel_mem(option, total_sz, &crash_size,
> >+ &crash_base);
> >+ } else {
> >+ crash_size = memparse(option, &cur);
> >+ if (option == cur)
> >+ return;
> >+ while (*cur && *cur != ' ' && *cur != '@')
> >+ cur++;
> >+ if (*cur == '@') {
> >+ option = cur + 1;
> >+ crash_base = memparse(option, &cur);
> >+ }
> >+ }
> >+ if (crash_base) {
> >+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
> >+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
> >+ } else {
> >+ /*
> >+ * Clearing mem_avoid if no offset is given. This is
> >consistent
> >+ * with kernel, which uses the last crashkernel= option.
> >+ */
> >+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = 0;
> >+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = 0;
> >+ }
> >+}
> >
> > static void handle_mem_options(void)
> > {
> >@@ -248,7 +358,7 @@ static void handle_mem_options(void)
> > u64 mem_size;
> >
> > if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
> >- !strstr(args, "hugepages"))
> >+ !strstr(args, "hugepages") && !strstr(args, "crashkernel="))
> > return;
> >
> > tmp_cmdline = malloc(len + 1);
> >@@ -284,6 +394,8 @@ static void handle_mem_options(void)
> > goto out;
> >
> > mem_limit = mem_size;
> >+ } else if (strstr(param, "crashkernel")) {
> >+ mem_avoid_specified_crashkernel_region(val);
> > }
> > }
> >
> >@@ -412,7 +524,7 @@ static void mem_avoid_init(unsigned long input, unsigned
> >long input_size,
> >
> > /* We don't need to set a mapping for setup_data. */
> >
> >- /* Mark the memmap regions we need to avoid */
> >+ /* Mark the regions we need to avoid */
> > handle_mem_options();
> >
> > /* Enumerate the immovable memory regions */
> >--
> >2.7.4
> >
> >
> >
>
>
Re: [v2 PATCH] PCI: mediatek: get optional clock by devm_clk_get_optional()
On Sun, 2019-03-31 at 20:41 +0800, Chunfeng Yun wrote:
> Use devm_clk_get_optional() to get optional clock
>
> Cc: Ryder Lee
> Cc: Honghui Zhang
> Signed-off-by: Chunfeng Yun
Acked-by: Ryder Lee
> ---
> v2:
> 1. cc Ryder and Honghui
> 2. fix up omitted 'if (IS_ERR())'
> ---
> drivers/pci/controller/pcie-mediatek.c | 50 --
> 1 file changed, 15 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c
> b/drivers/pci/controller/pcie-mediatek.c
> index 0b6c72804e03..adb6cb15daa2 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -915,49 +915,29 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
>
> /* sys_ck might be divided into the following parts in some chips */
> snprintf(name, sizeof(name), "ahb_ck%d", slot);
> - port->ahb_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->ahb_ck)) {
> - if (PTR_ERR(port->ahb_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->ahb_ck = NULL;
> - }
> + port->ahb_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->ahb_ck))
> + return PTR_ERR(port->ahb_ck);
>
> snprintf(name, sizeof(name), "axi_ck%d", slot);
> - port->axi_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->axi_ck)) {
> - if (PTR_ERR(port->axi_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->axi_ck = NULL;
> - }
> + port->axi_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->axi_ck))
> + return PTR_ERR(port->axi_ck);
>
> snprintf(name, sizeof(name), "aux_ck%d", slot);
> - port->aux_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->aux_ck)) {
> - if (PTR_ERR(port->aux_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->aux_ck = NULL;
> - }
> + port->aux_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->aux_ck))
> + return PTR_ERR(port->aux_ck);
>
> snprintf(name, sizeof(name), "obff_ck%d", slot);
> - port->obff_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->obff_ck)) {
> - if (PTR_ERR(port->obff_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->obff_ck = NULL;
> - }
> + port->obff_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->obff_ck))
> + return PTR_ERR(port->obff_ck);
>
> snprintf(name, sizeof(name), "pipe_ck%d", slot);
> - port->pipe_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->pipe_ck)) {
> - if (PTR_ERR(port->pipe_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->pipe_ck = NULL;
> - }
> + port->pipe_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->pipe_ck))
> + return PTR_ERR(port->pipe_ck);
>
> snprintf(name, sizeof(name), "pcie-rst%d", slot);
> port->reset = devm_reset_control_get_optional_exclusive(dev, name);
Re: [PATCHv3] x86/boot/KASLR: skip the specified crashkernel region
On 04/02/19 at 02:19pm, Chao Fan wrote:
> On Tue, Apr 02, 2019 at 12:10:46PM +0800, Pingfan Liu wrote:
> >crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> or or?
> >fail to reserve the required memory region if KASLR puts kernel into the
> >region. To avoid this uncertainty, asking KASLR to skip the required
> >region.
> >
> >Signed-off-by: Pingfan Liu
> >Cc: Thomas Gleixner
> >Cc: Ingo Molnar
> >Cc: Borislav Petkov
> >Cc: "H. Peter Anvin"
> >Cc: Baoquan He
> >Cc: Will Deacon
> >Cc: Nicolas Pitre
> >Cc: Pingfan Liu
> >Cc: Chao Fan
> >Cc: "Kirill A. Shutemov"
> >Cc: Ard Biesheuvel
> >Cc: linux-kernel@vger.kernel.org
> >---
> [...]
> >+
> >+/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset
> >options */
>
> Before review, I want to say more about the background.
> It's very hard to review the code for someone who is not so familiar
> with kdump, so could you please explain more ahout
> the uasge of crashkernel=range1:size1[,range2:size2,...]@offset.
> And also there are so many jobs who are parsing string. So I really
> need your help to understand the PATCH.
The hard part may be handle_crashkernel_mem() itself. However, it's
almost copied from parse_crashkernel_mem() completely. If we can reuse
that function, thing's gonna be perfect.
>
> >+static void mem_avoid_specified_crashkernel_region(char *option)
> >+{
> >+unsigned long long crash_size, crash_base = 0;
> >+char*first_colon, *first_space, *cur = option;
> Is there a tab after char?
> >+
> >+first_colon = strchr(option, ':');
> >+first_space = strchr(option, ' ');
> >+/* if contain ":" */
> >+if (first_colon && (!first_space || first_colon < first_space)) {
> >+int i;
> >+u64 total_sz = 0;
> >+struct boot_e820_entry *entry;
> >+
> >+for (i = 0; i < boot_params->e820_entries; i++) {
> >+entry = &boot_params->e820_table[i];
> >+/* Skip non-RAM entries. */
> >+if (entry->type != E820_TYPE_RAM)
> >+continue;
> >+total_sz += entry->size;
> I wonder whether it's needed to consider the memory ranges here.
> I think it's OK to only record the regions should to be avoid.
> I remeber I ever talked with Baoquan about the similiar problems.
> @Baoquan, I am not sure if I misunderstand something.
Not sure if I get you. Could you be more specific?
Re: [PATCH v2 1/9] mfd: mt6397: clean up code
On Mon, 11 Mar 2019, Hsin-Hsiung Wang wrote: > clean up code Please explain what it is that you're cleaning up. > Signed-off-by: Hsin-Hsiung Wang > --- > drivers/mfd/mt6397-core.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) The patch is fine though. When you resubmit, please add my: For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCHv3] x86/boot/KASLR: skip the specified crashkernel region
On 04/02/19 at 12:10pm, Pingfan Liu wrote:
> crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> fail to reserve the required memory region if KASLR puts kernel into the
> region. To avoid this uncertainty, asking KASLR to skip the required
> region.
>
> Signed-off-by: Pingfan Liu
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Baoquan He
> Cc: Will Deacon
> Cc: Nicolas Pitre
> Cc: Pingfan Liu
> Cc: Chao Fan
> Cc: "Kirill A. Shutemov"
> Cc: Ard Biesheuvel
> Cc: linux-kernel@vger.kernel.org
> ---
> v2 -> v3: adding parsing of crashkernel=range1:size1[,range2:size2,...]@offset
>
> arch/x86/boot/compressed/kaslr.c | 116
> ++-
> 1 file changed, 114 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index 2e53c05..7f698f4 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -107,6 +107,7 @@ enum mem_avoid_index {
> MEM_AVOID_BOOTPARAMS,
> MEM_AVOID_MEMMAP_BEGIN,
> MEM_AVOID_MEMMAP_END = MEM_AVOID_MEMMAP_BEGIN + MAX_MEMMAP_REGIONS - 1,
> + MEM_AVOID_CRASHKERNEL,
> MEM_AVOID_MAX,
> };
>
> @@ -238,6 +239,115 @@ static void parse_gb_huge_pages(char *param, char *val)
> }
> }
>
> +/* code heavily copied from parse_crashkernel_mem() */
> +static void handle_crashkernel_mem(char *cmdline,
> + unsigned long long system_ram,
> + unsigned long long *crash_size,
> + unsigned long long *crash_base)
This version looks better and the logic is simple. It will be much better
if we can share code with parse_crashkernel_mem() since both of them look
almost the same.
> +{
> + char *tmp, *cur = cmdline;
> +
> + /* for each entry of the comma-separated list */
> + do {
> + unsigned long long start, end = ULLONG_MAX, size;
> +
> + /* get the start of the range */
> + start = memparse(cur, &tmp);
> + /* no value given */
> + if (cur == tmp)
> + return;
> + cur = tmp;
> + if (*cur != '-')
> + return;
> + cur++;
> +
> + /* if no ':' is here, than we read the end */
> + if (*cur != ':') {
> + end = memparse(cur, &tmp);
> + /* no value given */
> + if (cur == tmp)
> + return;
> + cur = tmp;
> + /* invalid if crashkernel end <= start */
> + if (end <= start)
> + return;
> + }
> + /* expect ":" after range */
> + if (*cur != ':')
> + return;
> + cur++;
> +
> + size = memparse(cur, &tmp);
> + /* no size value given */
> + if (cur == tmp)
> + return;
> + cur = tmp;
> + if (size >= system_ram)
> + return;
> +
> + /* match ? */
> + if (system_ram >= start && system_ram < end) {
> + *crash_size = size;
> + break;
> + }
> + } while (*cur++ == ',');
> +
> + if (*crash_size > 0) {
> + while (*cur && *cur != ' ' && *cur != '@')
> + cur++;
> + if (*cur == '@') {
> + cur++;
> + *crash_base = memparse(cur, &tmp);
> + }
> + }
> +}
> +
> +/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset options
> */
> +static void mem_avoid_specified_crashkernel_region(char *option)
Maybe just add more words to explain the specified crashkernel region
cases, but remove the 'speecified' word in function name?
> +{
> + unsigned long long crash_size, crash_base = 0;
> + char*first_colon, *first_space, *cur = option;
> +
> + first_colon = strchr(option, ':');
> + first_space = strchr(option, ' ');
> + /* if contain ":" */
> + if (first_colon && (!first_space || first_colon < first_space)) {
> + int i;
> + u64 total_sz = 0;
> + struct boot_e820_entry *entry;
> +
> + for (i = 0; i < boot_params->e820_entries; i++) {
> + entry = &boot_params->e820_table[i];
> + /* Skip non-RAM entries. */
> + if (entry->type != E820_TYPE_RAM)
> + continue;
> + total_sz += entry->size;
Wrap this for loop into a static function to calculate the system RAM
size?
Other than these, I think this adding looks good. It won't impact the
current handling, and very easy to recognize what it's doing. Thanks for
the effort.
Thanks
Baoquan
>
RE: [PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate B114-21 with ALC233
Reviewed-by: Kailang Yang
-Original Message-
From: Takashi Iwai
Sent: Tuesday, April 2, 2019 2:43 PM
To: Kailang
Cc: Jian-Hong Pan ; alsa-de...@alsa-project.org; Daniel
Drake ; li...@endlessm.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate
B114-21 with ALC233
On Tue, 02 Apr 2019 08:38:32 +0200,
Kailang wrote:
>
> Hi Takashi,
>
> This COEF value was modified by me.
OK, then could you give your Acked-by or Reviewed-by tag?
thanks,
Takashi
>
> BR,
> Kailang
>
> -Original Message-
> From: Takashi Iwai
> Sent: Tuesday, April 2, 2019 1:09 AM
> To: Jian-Hong Pan
> Cc: alsa-de...@alsa-project.org; Daniel Drake ;
> li...@endlessm.com; Kailang ;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ALSA: hda/realtek: Enable headset MIC of Acer
> TravelMate B114-21 with ALC233
>
> On Mon, 01 Apr 2019 05:25:05 +0200,
> Jian-Hong Pan wrote:
> >
> > The Acer TravelMate B114-21 laptop cannot detect and record sound
> > from headset MIC. This patch adds the ALC233_FIXUP_ACER_HEADSET_MIC
> > HDA verb quirk chained with ALC233_FIXUP_ASUS_MIC_NO_PRESENCE pin
> > quirk to fix this issue.
> >
> > Signed-off-by: Jian-Hong Pan
> > Signed-off-by: Daniel Drake
> > ---
> > sound/pci/hda/patch_realtek.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c
> > b/sound/pci/hda/patch_realtek.c index a3fb3d4c5730..bdb2227be4eb
> > 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5690,6 +5690,7 @@ enum {
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> > ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
> > ALC299_FIXUP_PREDATOR_SPK,
> > + ALC233_FIXUP_ACER_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = { @@ -6713,6
> > +6714,15 @@ static const struct hda_fixup alc269_fixups[] = {
> > { 0x21, 0x90170150 }, /* use as headset mic, without
> > its own jack detect */
> > { }
> > }
> > + [ALC233_FIXUP_ACER_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_VERBS,
> > + .v.verbs = (const struct hda_verb[]) {
> > + { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 },
> > + { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 },
> > + { }
>
> For the additional COEF application, I'd like to hear ack from Kailang. It's
> still a black magic from Realtek, so need some confirmation.
>
>
> thanks,
>
> Takashi
>
> > + },
> > + .chained = true,
> > + .chain_id = ALC233_FIXUP_ASUS_MIC_NO_PRESENCE
> > },
> > };
> >
> > @@ -6737,6 +6747,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> > +ALC233_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> > SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
> > ALC275_FIXUP_DELL_XPS),
> > --
> > 2.20.1
> >
> >
>
> --Please consider the environment before printing this e-mail.
>
Re: [PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate B114-21 with ALC233
On Tue, 02 Apr 2019 08:38:32 +0200,
Kailang wrote:
>
> Hi Takashi,
>
> This COEF value was modified by me.
OK, then could you give your Acked-by or Reviewed-by tag?
thanks,
Takashi
>
> BR,
> Kailang
>
> -Original Message-
> From: Takashi Iwai
> Sent: Tuesday, April 2, 2019 1:09 AM
> To: Jian-Hong Pan
> Cc: alsa-de...@alsa-project.org; Daniel Drake ;
> li...@endlessm.com; Kailang ;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate
> B114-21 with ALC233
>
> On Mon, 01 Apr 2019 05:25:05 +0200,
> Jian-Hong Pan wrote:
> >
> > The Acer TravelMate B114-21 laptop cannot detect and record sound from
> > headset MIC. This patch adds the ALC233_FIXUP_ACER_HEADSET_MIC HDA
> > verb quirk chained with ALC233_FIXUP_ASUS_MIC_NO_PRESENCE pin quirk to
> > fix this issue.
> >
> > Signed-off-by: Jian-Hong Pan
> > Signed-off-by: Daniel Drake
> > ---
> > sound/pci/hda/patch_realtek.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c
> > b/sound/pci/hda/patch_realtek.c index a3fb3d4c5730..bdb2227be4eb
> > 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5690,6 +5690,7 @@ enum {
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> > ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
> > ALC299_FIXUP_PREDATOR_SPK,
> > + ALC233_FIXUP_ACER_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = { @@ -6713,6 +6714,15
> > @@ static const struct hda_fixup alc269_fixups[] = {
> > { 0x21, 0x90170150 }, /* use as headset mic, without
> > its own jack detect */
> > { }
> > }
> > + [ALC233_FIXUP_ACER_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_VERBS,
> > + .v.verbs = (const struct hda_verb[]) {
> > + { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 },
> > + { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 },
> > + { }
>
> For the additional COEF application, I'd like to hear ack from Kailang. It's
> still a black magic from Realtek, so need some confirmation.
>
>
> thanks,
>
> Takashi
>
> > + },
> > + .chained = true,
> > + .chain_id = ALC233_FIXUP_ASUS_MIC_NO_PRESENCE
> > },
> > };
> >
> > @@ -6737,6 +6747,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> > +ALC233_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> > SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
> > ALC275_FIXUP_DELL_XPS),
> > --
> > 2.20.1
> >
> >
>
> --Please consider the environment before printing this e-mail.
>
[PATCH v2 0/2] csky: perf callchain dwarf support
This patch set add perf DWARF unwinding support for C-SKY. Including user registers/stack dump API, and libdw support. Changes since v1: - seperate the callchain support using frame pointer CC: Peter Zijlstra CC: Ingo Molnar CC: Arnaldo Carvalho de Melo CC: Alexander Shishkin CC: Jiri Olsa CC: Namhyung Kim CC: Guo Ren Mao Han (2): csky: Add support for perf registers sampling csky: add support for libdw arch/csky/Kconfig| 2 + arch/csky/include/uapi/asm/perf_regs.h | 48 ++ arch/csky/kernel/Makefile| 1 + arch/csky/kernel/perf_regs.c | 40 tools/arch/csky/include/uapi/asm/perf_regs.h | 48 ++ tools/perf/Makefile.config | 6 +- tools/perf/arch/csky/Build | 1 + tools/perf/arch/csky/Makefile| 3 + tools/perf/arch/csky/include/perf_regs.h | 98 tools/perf/arch/csky/util/Build | 2 + tools/perf/arch/csky/util/dwarf-regs.c | 25 +++ tools/perf/arch/csky/util/unwind-libdw.c | 58 12 files changed, 331 insertions(+), 1 deletion(-) create mode 100644 arch/csky/include/uapi/asm/perf_regs.h create mode 100644 arch/csky/kernel/perf_regs.c create mode 100644 tools/arch/csky/include/uapi/asm/perf_regs.h create mode 100644 tools/perf/arch/csky/Build create mode 100644 tools/perf/arch/csky/Makefile create mode 100644 tools/perf/arch/csky/include/perf_regs.h create mode 100644 tools/perf/arch/csky/util/Build create mode 100644 tools/perf/arch/csky/util/dwarf-regs.c create mode 100644 tools/perf/arch/csky/util/unwind-libdw.c -- 2.7.4
[PATCH v2 2/2] csky: add support for libdw
This patch add support for DWARF register mappings and libdw registers
initialization, which is used by perf callchain analyzing when
--call-graph=dwarf is given.
CC: Peter Zijlstra
CC: Ingo Molnar
CC: Arnaldo Carvalho de Melo
CC: Alexander Shishkin
CC: Jiri Olsa
CC: Namhyung Kim
CC: Guo Ren
Signed-off-by: Mao Han
---
tools/arch/csky/include/uapi/asm/perf_regs.h | 48 ++
tools/perf/Makefile.config | 6 +-
tools/perf/arch/csky/Build | 1 +
tools/perf/arch/csky/Makefile| 3 +
tools/perf/arch/csky/include/perf_regs.h | 98
tools/perf/arch/csky/util/Build | 2 +
tools/perf/arch/csky/util/dwarf-regs.c | 25 +++
tools/perf/arch/csky/util/unwind-libdw.c | 58
8 files changed, 240 insertions(+), 1 deletion(-)
create mode 100644 tools/arch/csky/include/uapi/asm/perf_regs.h
create mode 100644 tools/perf/arch/csky/Build
create mode 100644 tools/perf/arch/csky/Makefile
create mode 100644 tools/perf/arch/csky/include/perf_regs.h
create mode 100644 tools/perf/arch/csky/util/Build
create mode 100644 tools/perf/arch/csky/util/dwarf-regs.c
create mode 100644 tools/perf/arch/csky/util/unwind-libdw.c
diff --git a/tools/arch/csky/include/uapi/asm/perf_regs.h
b/tools/arch/csky/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..337d8fa
--- /dev/null
+++ b/tools/arch/csky/include/uapi/asm/perf_regs.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
+
+#ifndef _ASM_CSKY_PERF_REGS_H
+#define _ASM_CSKY_PERF_REGS_H
+
+enum perf_event_csky_regs {
+ PERF_REG_CSKY_TLS,
+ PERF_REG_CSKY_LR,
+ PERF_REG_CSKY_PC,
+ PERF_REG_CSKY_SR,
+ PERF_REG_CSKY_SP,
+ PERF_REG_CSKY_ORIG_A0,
+ PERF_REG_CSKY_R0,
+ PERF_REG_CSKY_R1,
+ PERF_REG_CSKY_R2,
+ PERF_REG_CSKY_R3,
+ PERF_REG_CSKY_R4,
+ PERF_REG_CSKY_R5,
+ PERF_REG_CSKY_R6,
+ PERF_REG_CSKY_R7,
+ PERF_REG_CSKY_R8,
+ PERF_REG_CSKY_R9,
+ PERF_REG_CSKY_R10,
+ PERF_REG_CSKY_R11,
+ PERF_REG_CSKY_R12,
+ PERF_REG_CSKY_R13,
+ PERF_REG_CSKY_R16,
+ PERF_REG_CSKY_R17,
+ PERF_REG_CSKY_R18,
+ PERF_REG_CSKY_R19,
+ PERF_REG_CSKY_R20,
+ PERF_REG_CSKY_R21,
+ PERF_REG_CSKY_R22,
+ PERF_REG_CSKY_R23,
+ PERF_REG_CSKY_R24,
+ PERF_REG_CSKY_R25,
+ PERF_REG_CSKY_R26,
+ PERF_REG_CSKY_R27,
+ PERF_REG_CSKY_R28,
+ PERF_REG_CSKY_R29,
+ PERF_REG_CSKY_R30,
+ PERF_REG_CSKY_HI,
+ PERF_REG_CSKY_LO,
+ PERF_REG_CSKY_DCSR,
+ PERF_REG_CSKY_MAX,
+};
+#endif /* _ASM_CSKY_PERF_REGS_H */
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index fe3f97e..42985ae 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -59,6 +59,10 @@ ifeq ($(SRCARCH),arm64)
LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
endif
+ifeq ($(SRCARCH),csky)
+ NO_PERF_REGS := 0
+endif
+
ifeq ($(ARCH),s390)
NO_PERF_REGS := 0
NO_SYSCALL_TABLE := 0
@@ -77,7 +81,7 @@ endif
# Disable it on all other architectures in case libdw unwind
# support is detected in system. Add supported architectures
# to the check.
-ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc s390))
+ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc s390 csky))
NO_LIBDW_DWARF_UNWIND := 1
endif
diff --git a/tools/perf/arch/csky/Build b/tools/perf/arch/csky/Build
new file mode 100644
index 000..54afe4a
--- /dev/null
+++ b/tools/perf/arch/csky/Build
@@ -0,0 +1 @@
+libperf-y += util/
diff --git a/tools/perf/arch/csky/Makefile b/tools/perf/arch/csky/Makefile
new file mode 100644
index 000..7fbca17
--- /dev/null
+++ b/tools/perf/arch/csky/Makefile
@@ -0,0 +1,3 @@
+ifndef NO_DWARF
+PERF_HAVE_DWARF_REGS := 1
+endif
diff --git a/tools/perf/arch/csky/include/perf_regs.h
b/tools/perf/arch/csky/include/perf_regs.h
new file mode 100644
index 000..6baae28
--- /dev/null
+++ b/tools/perf/arch/csky/include/perf_regs.h
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include
+#include
+#include
+
+#define PERF_REGS_MASK ((1ULL << PERF_REG_CSKY_MAX) - 1)
+#define PERF_REGS_MAX PERF_REG_CSKY_MAX
+#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_32
+
+#define PERF_REG_IPPERF_REG_CSKY_PC
+#define PERF_REG_SPPERF_REG_CSKY_SP
+
+static inline const char *perf_reg_name(int id)
+{
+ switch (id) {
+ case PERF_REG_CSKY_R0:
+ return "r0";
+ case PERF_REG_CSKY_R1:
+ return "r1";
+ case PERF_REG_CSKY_R2:
+ return "r2";
+ case PERF_REG_CSKY_R3:
+ return "r3";
+ case PERF_REG_CSKY_R4:
+ return "r4";
+ case PERF_REG_CSKY_R5:
+
[PATCH v2 1/2] csky: Add support for perf registers sampling
This patch implements the perf registers sampling and validation API
for csky arch. The valid registers and their register ID are defined in
perf_regs.h. Perf tool can backtrace in userspace with unwind library
and the registers/user stack dump support.
CC: Guo Ren
Signed-off-by: Mao Han
---
arch/csky/Kconfig | 2 ++
arch/csky/include/uapi/asm/perf_regs.h | 48 ++
arch/csky/kernel/Makefile | 1 +
arch/csky/kernel/perf_regs.c | 40
4 files changed, 91 insertions(+)
create mode 100644 arch/csky/include/uapi/asm/perf_regs.h
create mode 100644 arch/csky/kernel/perf_regs.c
diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index c4974cf..8e45c7a 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -38,6 +38,8 @@ config CSKY
select HAVE_KERNEL_LZO
select HAVE_KERNEL_LZMA
select HAVE_PERF_EVENTS
+ select HAVE_PERF_REGS
+ select HAVE_PERF_USER_STACK_DUMP
select HAVE_DMA_API_DEBUG
select HAVE_DMA_CONTIGUOUS
select HAVE_SYSCALL_TRACEPOINTS
diff --git a/arch/csky/include/uapi/asm/perf_regs.h
b/arch/csky/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..337d8fa
--- /dev/null
+++ b/arch/csky/include/uapi/asm/perf_regs.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
+
+#ifndef _ASM_CSKY_PERF_REGS_H
+#define _ASM_CSKY_PERF_REGS_H
+
+enum perf_event_csky_regs {
+ PERF_REG_CSKY_TLS,
+ PERF_REG_CSKY_LR,
+ PERF_REG_CSKY_PC,
+ PERF_REG_CSKY_SR,
+ PERF_REG_CSKY_SP,
+ PERF_REG_CSKY_ORIG_A0,
+ PERF_REG_CSKY_R0,
+ PERF_REG_CSKY_R1,
+ PERF_REG_CSKY_R2,
+ PERF_REG_CSKY_R3,
+ PERF_REG_CSKY_R4,
+ PERF_REG_CSKY_R5,
+ PERF_REG_CSKY_R6,
+ PERF_REG_CSKY_R7,
+ PERF_REG_CSKY_R8,
+ PERF_REG_CSKY_R9,
+ PERF_REG_CSKY_R10,
+ PERF_REG_CSKY_R11,
+ PERF_REG_CSKY_R12,
+ PERF_REG_CSKY_R13,
+ PERF_REG_CSKY_R16,
+ PERF_REG_CSKY_R17,
+ PERF_REG_CSKY_R18,
+ PERF_REG_CSKY_R19,
+ PERF_REG_CSKY_R20,
+ PERF_REG_CSKY_R21,
+ PERF_REG_CSKY_R22,
+ PERF_REG_CSKY_R23,
+ PERF_REG_CSKY_R24,
+ PERF_REG_CSKY_R25,
+ PERF_REG_CSKY_R26,
+ PERF_REG_CSKY_R27,
+ PERF_REG_CSKY_R28,
+ PERF_REG_CSKY_R29,
+ PERF_REG_CSKY_R30,
+ PERF_REG_CSKY_HI,
+ PERF_REG_CSKY_LO,
+ PERF_REG_CSKY_DCSR,
+ PERF_REG_CSKY_MAX,
+};
+#endif /* _ASM_CSKY_PERF_REGS_H */
diff --git a/arch/csky/kernel/Makefile b/arch/csky/kernel/Makefile
index 4c462f5..1624b04 100644
--- a/arch/csky/kernel/Makefile
+++ b/arch/csky/kernel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
obj-$(CONFIG_CSKY_PMU_V1) += perf_event.o
obj-$(CONFIG_PERF_EVENTS) += perf_callchain.o
+obj-$(CONFIG_HAVE_PERF_REGS)+= perf_regs.o
ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
diff --git a/arch/csky/kernel/perf_regs.c b/arch/csky/kernel/perf_regs.c
new file mode 100644
index 000..153c8f6
--- /dev/null
+++ b/arch/csky/kernel/perf_regs.c
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+u64 perf_reg_value(struct pt_regs *regs, int idx)
+{
+ if (WARN_ON_ONCE((u32)idx >= PERF_REG_CSKY_MAX))
+ return 0;
+
+ return ((long *)regs)[idx];
+}
+
+#define REG_RESERVED (~((1ULL << PERF_REG_CSKY_MAX) - 1))
+
+int perf_reg_validate(u64 mask)
+{
+ if (!mask || mask & REG_RESERVED)
+ return -EINVAL;
+
+ return 0;
+}
+
+u64 perf_reg_abi(struct task_struct *task)
+{
+ return PERF_SAMPLE_REGS_ABI_32;
+}
+
+void perf_get_regs_user(struct perf_regs *regs_user,
+ struct pt_regs *regs,
+ struct pt_regs *regs_user_copy)
+{
+ regs_user->regs = task_pt_regs(current);
+ regs_user->abi = perf_reg_abi(current);
+}
--
2.7.4
[PATCH v2 1/1] perf: use hweight64 instead of hweight_long
On 32-bits platform with more than 32 registers, the 64 bits mask is
truncate to the lower 32 bits and the return value of hweight_long will
always smaller than 32. When kernel outputs more than 32 registers, but
the user perf program only counts 32, there will be a data mismatch
result to overflow check fail.
CC: Peter Zijlstra
CC: Ingo Molnar
CC: Arnaldo Carvalho de Melo
CC: Alexander Shishkin
CC: Jiri Olsa
CC: Namhyung Kim
CC: Guo Ren
Signed-off-by: Mao Han
---
tools/perf/util/evsel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 7835e05..73c78be 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2322,7 +2322,7 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
if (data->user_regs.abi) {
u64 mask = evsel->attr.sample_regs_user;
- sz = hweight_long(mask) * sizeof(u64);
+ sz = hweight64(mask) * sizeof(u64);
OVERFLOW_CHECK(array, sz, max_size);
data->user_regs.mask = mask;
data->user_regs.regs = (u64 *)array;
--
2.7.4
RE: [PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate B114-21 with ALC233
Hi Takashi,
This COEF value was modified by me.
BR,
Kailang
-Original Message-
From: Takashi Iwai
Sent: Tuesday, April 2, 2019 1:09 AM
To: Jian-Hong Pan
Cc: alsa-de...@alsa-project.org; Daniel Drake ;
li...@endlessm.com; Kailang ; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate
B114-21 with ALC233
On Mon, 01 Apr 2019 05:25:05 +0200,
Jian-Hong Pan wrote:
>
> The Acer TravelMate B114-21 laptop cannot detect and record sound from
> headset MIC. This patch adds the ALC233_FIXUP_ACER_HEADSET_MIC HDA
> verb quirk chained with ALC233_FIXUP_ASUS_MIC_NO_PRESENCE pin quirk to
> fix this issue.
>
> Signed-off-by: Jian-Hong Pan
> Signed-off-by: Daniel Drake
> ---
> sound/pci/hda/patch_realtek.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c
> b/sound/pci/hda/patch_realtek.c index a3fb3d4c5730..bdb2227be4eb
> 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -5690,6 +5690,7 @@ enum {
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
> ALC299_FIXUP_PREDATOR_SPK,
> + ALC233_FIXUP_ACER_HEADSET_MIC,
> };
>
> static const struct hda_fixup alc269_fixups[] = { @@ -6713,6 +6714,15
> @@ static const struct hda_fixup alc269_fixups[] = {
> { 0x21, 0x90170150 }, /* use as headset mic, without
> its own jack detect */
> { }
> }
> + [ALC233_FIXUP_ACER_HEADSET_MIC] = {
> + .type = HDA_FIXUP_VERBS,
> + .v.verbs = (const struct hda_verb[]) {
> + { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 },
> + { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 },
> + { }
For the additional COEF application, I'd like to hear ack from Kailang. It's
still a black magic from Realtek, so need some confirmation.
thanks,
Takashi
> + },
> + .chained = true,
> + .chain_id = ALC233_FIXUP_ASUS_MIC_NO_PRESENCE
> },
> };
>
> @@ -6737,6 +6747,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> + SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> +ALC233_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> ALC255_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
> ALC275_FIXUP_DELL_XPS),
> --
> 2.20.1
>
>
--Please consider the environment before printing this e-mail.
Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
> Am 02.04.2019 um 07:31 schrieb Mark Brown : > > It's relatively common, especially with older devices, for people to be > perfectly happy to update the kernel and do so frequently but unwilling > to update the bootloader as the procedure for recovering a broken > bootloader is difficult or perhaps not even possible. Yes, that is the case Linus tries to solve, where it is not even possible to modify the DTB. No idea how it could be solved if it would not be possible to change our 6 years old DTB. Fortunately we do not need to change it at all with the latest check for cs-gpios. > >> This also gives another idea: make it depend on "powerpc". > > That won't fly, the code has always been architecture neutral. Ok. Just an idea. > >>> Dunno about this, it looks fragile, I would prefer to keep all working. >>> But I will listen to reason. > >> Reason why I propose a CONFIG option is: > >> if someone is able to compile and deploy a v5.1 kernel for some device which >> has (old) and problematic DTB in ROM he/she must have access to the .config. >> So it is easy to modify it to enable legacy handling of spi-cs-high. And keep >> it disabled for all others. > > This assumes people aren't able to run a distro kernel... Yes, indeed. I have learned from Linus that the problem with legacy spi-cs-high are mostly embedded powerpc systems deployed between 2008 and 2013 where the boot-loader can't be changed. And where the dts is not maintained on kernel.org. IMHO it is very unlikely that they are running distro kernels. Or is there an example of such a system? BR and thanks, Nikolaus
Re: [PATCH 1/3] mtd: devices: m25p80: Simplify m25p80_read()
Hi,
On 01/04/19 10:19 AM, Andrey Smirnov wrote:
> Spi_nor_read() already has an appropriate loop around .read() callback
> to handle the case when not all of the data requested was written in a
> signle ->read() call. Drop extra code doing the same thing in
> m25p80_read().
>
Thanks for the patch series! But we are in the process of completely
moving m25p80.c into spi-nor.c which should take care of this series.
See[1][2], I plan to post the next version shortly. Let me know if
something is missing.
[1] https://patchwork.ozlabs.org/patch/982925/
[2] https://patchwork.ozlabs.org/patch/982922/
Regards
Vignesh
> Signed-off-by: Andrey Smirnov
> Cc: Brian Norris
> Cc: Boris Brezillon
> Cc: Marek Vasut
> Cc: Chris Healy
> Cc: linux-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/mtd/devices/m25p80.c | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 651bab6d4e31..114f8ccea85b 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -125,7 +125,6 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t
> from, size_t len,
> SPI_MEM_OP_ADDR(nor->addr_width, from, 1),
> SPI_MEM_OP_DUMMY(nor->read_dummy, 1),
> SPI_MEM_OP_DATA_IN(len, buf, 1));
> - size_t remaining = len;
> int ret;
>
> /* get transfer protocols. */
> @@ -137,22 +136,15 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t
> from, size_t len,
> /* convert the dummy cycles to the number of bytes */
> op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
>
> - while (remaining) {
> - op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
> - ret = spi_mem_adjust_op_size(flash->spimem, &op);
> - if (ret)
> - return ret;
> -
> - ret = spi_mem_exec_op(flash->spimem, &op);
> - if (ret)
> - return ret;
> + ret = spi_mem_adjust_op_size(flash->spimem, &op);
> + if (ret)
> + return ret;
>
> - op.addr.val += op.data.nbytes;
> - remaining -= op.data.nbytes;
> - op.data.buf.in += op.data.nbytes;
> - }
> + ret = spi_mem_exec_op(flash->spimem, &op);
> + if (ret)
> + return ret;
>
> - return len;
> + return op.data.nbytes;
> }
>
> /*
>
--
Regards
Vignesh
Re: [PATCH v7 2/6] mfd: rk808: Add RK817 and RK809 support
On Wed, 02 Jan 2019, Tony Xie wrote: > The RK809 and RK817 are a Power Management IC (PMIC) for multimedia > and handheld devices. They contains the following components: > - Regulators > - RTC > - Clocking > > Both RK809 and RK817 chips are using a similar register map, > so we can reuse the RTC and Clocking functionality. > Most of regulators have a some implementation also. > > Signed-off-by: Tony Xie > Acked-by: Stephen Boyd > --- > drivers/mfd/Kconfig | 6 +- > drivers/mfd/rk808.c | 192 +- > include/linux/mfd/rk808.h | 172 ++ > 3 files changed, 364 insertions(+), 6 deletions(-) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v10 18/18] LS1021A: dtsi: add ftm quad decoder entries
From: Patrick Havelange
Add the 4 Quadrature counters for this board.
Reviewed-by: Esben Haabendal
Signed-off-by: Patrick Havelange
Signed-off-by: William Breathitt Gray
---
arch/arm/boot/dts/ls1021a.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index ed0941292172..0168fb62590a 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -433,6 +433,34 @@
status = "disabled";
};
+ counter0: counter@29d {
+ compatible = "fsl,ftm-quaddec";
+ reg = <0x0 0x29d 0x0 0x1>;
+ big-endian;
+ status = "disabled";
+ };
+
+ counter1: counter@29e {
+ compatible = "fsl,ftm-quaddec";
+ reg = <0x0 0x29e 0x0 0x1>;
+ big-endian;
+ status = "disabled";
+ };
+
+ counter2: counter@29f {
+ compatible = "fsl,ftm-quaddec";
+ reg = <0x0 0x29f 0x0 0x1>;
+ big-endian;
+ status = "disabled";
+ };
+
+ counter3: counter@2a0 {
+ compatible = "fsl,ftm-quaddec";
+ reg = <0x0 0x2a0 0x0 0x1>;
+ big-endian;
+ status = "disabled";
+ };
+
gpio0: gpio@230 {
compatible = "fsl,ls1021a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x230 0x0 0x1>;
--
2.21.0
Re: [PATCH v3 3/4] driver core: add dev_print_hex_dump() logging function.
On Mon, Apr 01, 2019 at 07:47:14PM -0700, Life is hard, and then you die wrote: > > On Thu, Mar 28, 2019 at 12:29:52PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Mar 28, 2019 at 03:27:55AM -0700, Life is hard, and then you die > > wrote: > > > > > > On Thu, Mar 28, 2019 at 06:29:17AM +0100, Greg Kroah-Hartman wrote: > > > > On Wed, Mar 27, 2019 at 05:28:17PM -0700, Life is hard, and then you > > > > die wrote: > > > > > > > > > > On Wed, Mar 27, 2019 at 11:37:57AM +0900, Greg Kroah-Hartman wrote: > > > > > > On Tue, Mar 26, 2019 at 06:48:06PM -0700, Ronald Tschalär wrote: > > > > > > > This is the dev_xxx() analog to print_hex_dump(), using > > > > > > > dev_printk() > > > > > > > instead of straight printk() to match other dev_xxx() logging > > > > > > > functions. > > > > > > > --- > > > > > > > drivers/base/core.c| 43 > > > > > > > ++ > > > > > > > include/linux/device.h | 15 +++ > > > > > > > 2 files changed, 58 insertions(+) > [snip] > > > > > > Anyway, no, please do not do this. Please do not dump large hex > > > > > > values > > > > > > like this to the kernel log, it does not help anyone. > > > > > > > > > > > > You can do this while debugging, sure, but not for "real" kernel > > > > > > code. > > > > > > > > > > As used by this driver, it is definitely called for debugging only and > > > > > must be explicitly enabled via a module param. But having the ability > > > > > for folks to easily generate and print out debugging info has proven > > > > > quite valuable. > > > > > > > > We have dynamic debugging, no need for module parameters at all. This > > > > isn't the 1990's anymore :) > > > > > > I am aware of dynamic debugging, but there are several issues with it > > > from the perspective of the logging I'm doing here (I mentioned these > > > in response to an earlier review already): > > > > > > 1. Dynamic debugging can't be enabled at a function or line level on > > > the kernel command line, so this means that to debug issues > > > during boot you have to enable everything, which can be way too > > > verbose > > > > You can, and should enable it at a function or line level by writing to > > the proper kernel file in debugfs. > > > > You have read Documentation/admin-guide/dynamic-debug-howto.rst, right? > > Yes, and I've played with the parameters quite a bit. > > > No need to do anything on the command line, that's so old-school :) > > Sorry if I'm being unduly dense, but then how to enable debugging > during early boot? The only other alternative I see is modifying the > initrd, and asking folks to do that is noticeably more complicated > than having them add something to the command line in grub. So from my > perspective I find kernel params far from old-school :-) You can do dynamic debugging from the kernel command line, if your code is built into the kernel (but why would a tiny driver under testing like this, not be built into the kernel?) what specifically did not work for you? > > > 2. The expressions to enable the individual logging statements are > > > quite brittle (in particular the line-based ones) since they > > > (may) change any time the code is changed - having stable > > > commands to give to users and put in documentation (e.g. > > > "echo 0x200 > /sys/module/applespi/parameters/debug") is > > > quite valuable. > > > > > > One way to work around this would be to put every single logging > > > statement in a function of its own, thereby ensuring a stable > > > name is associated with each one. > > > > Again, read the documentation, this works today as-is. > > I have read it (we're talking about the dynamic debug docs here), but > I just don't see how it addresses this in any way. You can enable/disable logging per-function, which is what you want, right? Anyway, I'm glad tracepoints work for you, that should be all that is now needed. good luck with your driver! greg k-h
Re: [PATCH 4/4] staging: iio: ad9832: add devicetree documentation
On Mon, Apr 1, 2019 at 5:38 PM Marcelo Schmitt
wrote:
>
> Add a devicetree documentation for the ad9832 direct digital
> synthesizer, waveform generator.
>
> Signed-off-by: Marcelo Schmitt
> ---
> .../bindings/iio/frequency/ad9832.txt | 26 +++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/frequency/ad9832.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/frequency/ad9832.txt
> b/Documentation/devicetree/bindings/iio/frequency/ad9832.txt
> new file mode 100644
> index ..6a35fdff5a48
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/frequency/ad9832.txt
> @@ -0,0 +1,26 @@
> +Analog Devices AD9832 Direct Digital Synthesizer, Waveform Generator
> +
> +Data sheet:
> +https://www.analog.com/media/en/technical-documentation/data-sheets/AD9832.pdf
> +
> +Required properties:
> + - compatible : Must be "adi,ad9832"
> + - reg : SPI chip select number for the device
> + - spi-max-frequency = Max SPI frequency to use (< 2500)
> + - clocks : The clock reference for the DDS output
> + - clock-names : Must be "mclk"
It's always a good idea to reference other base dt docs.
For SPI you could:
```
For more information on SPI properties, please consult
Documentation/devicetree/bindings/spi/spi-bus.txt
```
For clock:
```
For more information on clock bindings properties, please consult
Documentation/devicetree/bindings/clock/clock-bindings.txt
```
For regulator:
```
For more information on regulator bindings properties, please consult
Documentation/devicetree/bindings/regulator/regulator.txt
```
> +
> +Optional properties:
> + - avdd-supply: Definition of the regulator used as analog supply
> + - dvdd-supply : Definition of the regulator used as digital supply
> +
> +Example:
> + adi9832-dds@0 {
> + compatible = "adi,ad9832";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> + clocks = <&ad9832_mclk>;
> + clock-names = "mclk";
> + avdd-suppy = <&avdd>;
> + dvdd-suppy = <&dvdd>;
> + };
> --
> 2.20.1
>
Re: [PATCH v7 1/6] mfd: rk808: remove the id_table
On Wed, 02 Jan 2019, Tony Xie wrote: > Remove the id_table because it's not used. > > Signed-off-by: Tony Xie > --- > drivers/mfd/rk808.c | 9 - > 1 file changed, 9 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 4/4] Add support for SUNIX Multi-I/O board
On Tue, 19 Mar 2019, Morris Ku wrote: > Driver for SUNIX Multi-I/O card.Based on parport_pc.c, ppdev.c > and lp.c by Linus Torvalds, Theodore Ts'o. Parallel port drivers should live in 'drivers/parport' and 'drivers/char'. LP drivers should live in 'drivers/char'. Please them there. > Signed-off-by: Morris Ku > --- > mfd/sunix/snx_ieee1284.c | 144 +++ > mfd/sunix/snx_ieee1284_ops.c | 258 + > mfd/sunix/snx_lp.c | 717 +++ > mfd/sunix/snx_lp.h | 119 ++ > mfd/sunix/snx_parallel.c | 397 +++ > mfd/sunix/snx_ppdev.c| 454 ++ > mfd/sunix/snx_ppdev.h| 15 + > mfd/sunix/snx_share.c| 629 ++ > 8 files changed, 2733 insertions(+) > create mode 100644 mfd/sunix/snx_ieee1284.c > create mode 100644 mfd/sunix/snx_ieee1284_ops.c > create mode 100644 mfd/sunix/snx_lp.c > create mode 100644 mfd/sunix/snx_lp.h > create mode 100644 mfd/sunix/snx_parallel.c > create mode 100644 mfd/sunix/snx_ppdev.c > create mode 100644 mfd/sunix/snx_ppdev.h > create mode 100644 mfd/sunix/snx_share.c -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] dt-bindings: iio: counter: Add Milbeaut Updown Counter
Hi Rob,
Thank you for your review.
On 2019/03/31 15:42, Rob Herring wrote:
On Tue, Mar 26, 2019 at 03:33:09PM +0900, Shinji Kanematsu wrote:
Add documentation for Milbeaut Updown Counter device
quadrature encoder and counter binding.
Signed-off-by: Shinji Kanematsu
---
.../bindings/iio/counter/milbeaut-updown_cnt.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt
diff --git
a/Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt
b/Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt
new file mode 100644
index 000..6771567
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt
@@ -0,0 +1,22 @@
+SOCIONEXT Milbeaut Updown counter
+
+Required properties:
+- compatible: Must be "socionext,milbeaut-updown-counter".
+- reg: Offset and length of the device's register set.
+- clocks: Phandle to the clock used by the Updown counter module.
+- clock-names: Must be "mux".
+- interrupts: SPI number of the device's set.
+- cms_type: connected_device
+ 1: updown button (updown counter mode)
+ 2: rotary encoder (phase difference counter mode)
We should have a common property for describing what's attached.
IIRC, just had a similar binding recently.
OK, I search the similar binding.
Thank you,
Kanematsu
+
+Example:
+
+ updown0: updown@1e002000 {
+ compatible = "socionext,milbeaut-updown-counter";
+ reg = <0x1e002000 0x20>;
+ clocks = <&clk 4>;
+ clock-names = "mux";
+ interrupts = <0 104 0x4>;
+ cms_type = <1>;
+ };
--
1.9.1
Re: [PATCH 3/4] Add support for SUNIX Multi-I/O board
On Tue, 19 Mar 2019, Morris Ku wrote: > This patch add header files and Makefile. Makefiles and header files should be added to the same patch as they are first used. > Signed-off-by: Morris Ku > --- > mfd/sunix/Makefile |9 + > mfd/sunix/driver_extd.h | 90 > mfd/sunix/snx_common.h | 1031 +++ > 3 files changed, 1130 insertions(+) > create mode 100644 mfd/sunix/Makefile > create mode 100644 mfd/sunix/driver_extd.h > create mode 100644 mfd/sunix/snx_common.h -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/4] Add support for SUNIX Multi-I/O board
On Tue, 19 Mar 2019, Morris Ku wrote: > Driver for SUNIX Multi-I/O card. > Based on driver/char/serial.c by Linus Torvalds, Theodore Ts'o. > > SUNIX serial card designed with SUNIX UART controller and > compatible with 16C950 UART specification. Serial drivers should live in drivers/tty/serial. Please move it there. > Signed-off-by: Morris Ku > --- > mfd/sunix/snx_main.c | 1671 +++ > mfd/sunix/snx_serial.c | 3513 > 2 files changed, 5184 insertions(+) > create mode 100644 mfd/sunix/snx_main.c > create mode 100644 mfd/sunix/snx_serial.c -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 0/2] Add Updown Counter support for Milbeaut M10V SoC
Hi William, On 2019/03/31 11:09, William Breathitt Gray wrote: On Sat, Mar 30, 2019 at 06:36:03PM +, Jonathan Cameron wrote: On Tue, 26 Mar 2019 15:32:34 +0900 Shinji Kanematsu wrote: This is a series of patch which adds Updown Counter support on Milbeaut M10V SoC. The Updown Counter counts input pulse signal from external quadrature encoder. It also has input pulse signal counter function. Hi Shinji, Are you aware of the counter subsystem that has been proposed (and as far as I am concerned is ready to be merged)? https://patchwork.kernel.org/project/linux-iio/list/?series=147 (I think that's the latest version posted).. William, perhaps you could give an update? (bad luck, you are getting popular ;) I'll take a quick review as it stands, as some issues may carry over. I appreciate that it's always unfortunate to try to upstream stuff at the same time as a new framework is being developed / upstreamed, but I don't intend to take any additional counter drivers into IIO. We just end up having to maintain old interfaces in more and more drivers. Thanks, Jonathan Shinji, If you reimplement this driver to use the new Generic Counter API, I can pick it up and include it with my next patchset submission. Please base your patches ontop of the "generic_counter_v10" branch from my personal repository: https://gitlab.com/vilhelmgray/iio/commits/generic_counter_v10 Documentation can be found at: Documentation/driver-api/generic-counter.rst Documentation/ABI/testing/sysfs-bus-counter Look at the existing drivers inside the drivers/counter directory to serve as references: drivers/counter/ftm-quaddec.c drivers/counter/stm32-timer-cnt.c If you have any troubles or difficulties with the API, send me a message and I will be happy to help. :-) Thank you for your information. I read and understand the new Generic Counter API. Thank you, Kanematsu Thank you, William Breathitt Gray Shinji Kanematsu (2): dt-bindings: iio: counter: Add Milbeaut Updown Counter iio: counter: Add support for Milbeaut Updown Counter .../bindings/iio/counter/milbeaut-updown_cnt.txt | 22 ++ drivers/iio/counter/Kconfig| 12 + drivers/iio/counter/Makefile | 1 + drivers/iio/counter/milbeaut-updown.h | 38 ++ drivers/iio/counter/milbeaut-updown_cnt.c | 385 + 5 files changed, 458 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/counter/milbeaut-updown_cnt.txt create mode 100644 drivers/iio/counter/milbeaut-updown.h create mode 100644 drivers/iio/counter/milbeaut-updown_cnt.c
Re: [PATCH 1/4] Add support for SUNIX Multi-I/O board
On Tue, 19 Mar 2019, Morris Ku wrote: > Add Kconfig and Makefile entry. > > Signed-off-by: Morris Ku > --- > mfd/Kconfig | 5 + > mfd/Makefile | 2 ++ > 2 files changed, 7 insertions(+) Can you send this set again please. There are some basic issues with it, which would make reviewing difficult. Please use `git format-patch` and `git send-email` to create and submit your patches. Use the following flags; --annotate, --compose and --thread to ensure the patches are sent a) pinned to each other so they do not become spread throughout people's inboxes and b) a cover letter is provided which should contain a summary of what you are trying to achieve. The diff should be based from the root directory, not 'drivers', such that the diff should read "drivers/mfd/*". > diff --git a/mfd/Kconfig b/mfd/Kconfig > index 76f9909c..efbb3ef1 100644 > --- a/mfd/Kconfig > +++ b/mfd/Kconfig > @@ -1916,5 +1916,10 @@ config RAVE_SP_CORE > Select this to get support for the Supervisory Processor > device found on several devices in RAVE line of hardware. > > +config SUNIX > + tristate "SUNIX Multi-I/O Board Driver" > + help > + Support for SUNIX Multi-I/O controller. > + > endmenu > endif > diff --git a/mfd/Makefile b/mfd/Makefile > index 12980a4a..b70f44de 100644 > --- a/mfd/Makefile > +++ b/mfd/Makefile > @@ -241,4 +241,6 @@ obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o > obj-$(CONFIG_MFD_SC27XX_PMIC)+= sprd-sc27xx-spi.o > obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o > obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o > +obj-$(CONFIG_SUNIX) += sunix/ > + > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume
On Mon, Apr 1, 2019 at 8:23 PM Andy Shevchenko
wrote:
>
> On Mon, Apr 01, 2019 at 06:41:57PM +0800, Chris Chiu wrote:
>
> Thanks for the patch.
> My comments below.
>
> > diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
> > b/drivers/pinctrl/intel/pinctrl-intel.c
> > index 8cda7b535b02..d1cfa5adef9b 100644
> > --- a/drivers/pinctrl/intel/pinctrl-intel.c
> > +++ b/drivers/pinctrl/intel/pinctrl-intel.c
> > @@ -77,6 +77,7 @@ struct intel_pad_context {
> > u32 padcfg0;
> > u32 padcfg1;
> > u32 padcfg2;
>
> > + u32 hostown;
>
> This is wrong. We have one register per entire (*) group of pins to keep host
> ownership. Basically it's a mask.
>
> *) if it's <= 32, otherwise there are more registers. But in any case it's 1
> bit per pin, and not 32 bits.
>
> > for (i = 0; i < pctrl->soc->npins; i++)
>
> Thus, the actual actions should mimic what we do for interrupt mask.
>
> --
> With Best Regards,
> Andy Shevchenko
>
Thanks for the comment. My first version did mimic the logic of the interrupt
mask restore but it was based on the DMI quirk. It saves HOSTSW_OWN
for each padgroup and restores them all after resume if DMI info matched.
What really confused me is how to do this specifically for a requested GPIO
pin. So here's my new proposed patch. Please suggests if there's any better
idea. Thanks.
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -81,6 +81,7 @@ struct intel_pad_context {
struct intel_community_context {
u32 *intmask;
+ u32 *hostown;
};
struct intel_pinctrl_context {
@@ -117,6 +118,10 @@ struct intel_pinctrl {
#define pin_to_padno(c, p) ((p) - (c)->pin_base)
#define padgroup_offset(g, p) ((p) - (g)->base)
+#ifdef CONFIG_PM_SLEEP
+static void intel_save_hostown(struct intel_pinctrl *pctrl, unsigned int pin);
+#endif
+
static struct intel_community *intel_get_community(struct intel_pinctrl *pctrl,
unsigned int pin)
{
@@ -456,7 +461,9 @@ static int intel_gpio_request_enable(struct
pinctrl_dev *pctldev,
intel_gpio_set_gpio_mode(padcfg0);
/* Disable TX buffer and enable RX (this will be input) */
__intel_gpio_set_direction(padcfg0, true);
+#ifdef CONFIG_PM_SLEEP
+ intel_save_hostown(pctrl, pin);
+#endif
raw_spin_unlock_irqrestore(&pctrl->lock, flags);
return 0;
@@ -1284,7 +1291,7 @@ static int intel_pinctrl_pm_init(struct
intel_pinctrl *pctrl)
for (i = 0; i < pctrl->ncommunities; i++) {
struct intel_community *community = &pctrl->communities[i];
- u32 *intmask;
+ u32 *intmask, *hostown;
intmask = devm_kcalloc(pctrl->dev, community->ngpps,
sizeof(*intmask), GFP_KERNEL);
@@ -1292,6 +1299,13 @@ static int intel_pinctrl_pm_init(struct
intel_pinctrl *pctrl)
return -ENOMEM;
communities[i].intmask = intmask;
+
+ hostown = devm_kcalloc(pctrl->dev, community->ngpps,
+ sizeof(*hostown), GFP_KERNEL);
+ if (!hostown)
+ return -ENOMEM;
+
+ communities[i].hostown= hostown;
}
pctrl->context.pads = pads;
@@ -1447,6 +1461,43 @@ int intel_pinctrl_probe_by_uid(struct
platform_device *pdev)
EXPORT_SYMBOL_GPL(intel_pinctrl_probe_by_uid);
#ifdef CONFIG_PM_SLEEP
+static void intel_save_hostown(struct intel_pinctrl *pctrl, unsigned int pin)
+{
+ const struct intel_community *community;
+ const struct intel_padgroup *padgrp;
+ int i;
+
+ community = intel_get_community(pctrl, pin);
+ if (!community)
+ return;
+ if (!community->hostown_offset)
+ return;
+
+ padgrp = intel_community_get_padgroup(community, pin);
+ if (!padgrp)
+ return;
+
+ for (i = 0; i < pctrl->ncommunities; i++) {
+ const struct intel_community *comm = &pctrl->communities[i];
+ int j;
+
+ for (j = 0; j < comm->ngpps; j++) {
+ const struct intel_padgroup *pgrp = &comm->gpps[j];
+
+ if (padgrp == pgrp) {
+ struct intel_community_context *communities;
+ void __iomem *base;
+
+ communities = pctrl->context.communities;
+ base = community->regs +
community->hostown_offset;
+ communities[i].hostown[j] = readl(base + j * 4);
+ break;
+ }
+ }
+ }
+ return;
+}
+
static bool intel_pinctrl_should_save(struct intel_pinctrl *pctrl,
unsigned int pin)
{
const struct pin_desc *pd = pin_desc_get(pctrl->pctldev, pin);
@@ -1588,6 +1639,17 @@ int intel_pinctrl_resume(struct device *dev)
Re: [PATCH] mfd: mc13xxx: i2c/spi Fix to avoid NULL pointer dereference
On Mon, 18 Mar 2019, Aditya Pakki wrote:
> of_match_device can return NULL if no matching device is found. The patches
> avoids a scenario causing null pointer dereference.
>
> Signed-off-by: Aditya Pakki
> ---
> drivers/mfd/mc13xxx-i2c.c | 2 ++
> drivers/mfd/mc13xxx-spi.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/mc13xxx-i2c.c b/drivers/mfd/mc13xxx-i2c.c
> index 67e4c9aa7d18..1fbc9713bb9a 100644
> --- a/drivers/mfd/mc13xxx-i2c.c
> +++ b/drivers/mfd/mc13xxx-i2c.c
> @@ -80,6 +80,8 @@ static int mc13xxx_i2c_probe(struct i2c_client *client,
> if (client->dev.of_node) {
> const struct of_device_id *of_id =
> of_match_device(mc13xxx_dt_ids, &client->dev);
> + if (!of_id)
> + return -ENODEV;
Are you sure this can happen?
I don't think this is possible if client->dev.of_node is non-NULL.
The 'if (client->dev.of_node)' above should see to that.
> mc13xxx->variant = of_id->data;
> } else {
> mc13xxx->variant = (void *)id->driver_data;
> diff --git a/drivers/mfd/mc13xxx-spi.c b/drivers/mfd/mc13xxx-spi.c
> index ee3411cc5ce4..c044a02bdb64 100644
> --- a/drivers/mfd/mc13xxx-spi.c
> +++ b/drivers/mfd/mc13xxx-spi.c
> @@ -158,6 +158,8 @@ static int mc13xxx_spi_probe(struct spi_device *spi)
> if (spi->dev.of_node) {
> const struct of_device_id *of_id =
> of_match_device(mc13xxx_dt_ids, &spi->dev);
> + if (!of_id)
> + return -ENODEV;
>
> mc13xxx->variant = of_id->data;
> } else {
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2] Staging: greybus: usb: Fixed a coding style error
On Mon, Apr 01, 2019 at 10:22:08AM -0400, Will Cunningham wrote: > Line was >80 characters. > > Signed-off-by: Will Cunningham > --- > Changes in v2: > - Created a tmp variable to shorten line length. > --- > drivers/staging/greybus/usb.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/greybus/usb.c b/drivers/staging/greybus/usb.c > index 1c246c73a085..c09793b48850 100644 > --- a/drivers/staging/greybus/usb.c > +++ b/drivers/staging/greybus/usb.c > @@ -163,14 +163,14 @@ static int gb_usb_probe(struct gbphy_device *gbphy_dev, > struct gb_usb_device *gb_usb_dev; > struct usb_hcd *hcd; > int retval; > + u16 tmp; > > hcd = usb_create_hcd(&usb_gb_hc_driver, dev, dev_name(dev)); > if (!hcd) > return -ENOMEM; > > - connection = gb_connection_create(gbphy_dev->bundle, > - > le16_to_cpu(gbphy_dev->cport_desc->id), > - NULL); > + tmp = le16_to_cpu(gbphy_dev->cport_desc->id); > + connection = gb_connection_create(gbphy_dev->bundle, tmp, NULL); "tmp" is the wrong name... :/ Like Joe said, it's doesn't help readability to introduce one time use temporary variables just to make the line lengths shorter. This line is 81 characters. It's fine. Just leave the original as is. regards, dan carpenter
Re: [PATCH -next] Input: uinput - Avoid Use-After-Free with udev lock
Please don't consider this patch, i will send v2 of this. Thanks, Mukesh On 3/28/2019 3:36 PM, Mukesh Ojha wrote: uinput_destroy_device() gets called from two places. In one place, uinput_ioctl_handler() it is protected under a lock udev->mutex but same is not true for other place inside uinput_release(). This can result in a race where udev device gets freed while it is in use. [ 160.093398] Call trace: [ 160.093417] kernfs_get+0x64/0x88 [ 160.093438] kernfs_new_node+0x94/0xc8 [ 160.093450] kernfs_create_dir_ns+0x44/0xfc [ 160.093463] sysfs_create_dir_ns+0xa8/0x130 [ 160.093479] kobject_add_internal+0x278/0x650 [ 160.093491] kobject_add_varg+0xe0/0x130 [ 160.093502] kobject_add+0x15c/0x1d0 [ 160.093518] device_add+0x2bc/0xde0 [ 160.093533] input_register_device+0x5f4/0xa0c [ 160.093547] uinput_ioctl_handler+0x1184/0x2198 [ 160.093560] uinput_ioctl+0x38/0x48 [ 160.093573] vfs_ioctl+0x7c/0xb4 [ 160.093585] do_vfs_ioctl+0x9ec/0x2350 [ 160.093597] SyS_ioctl+0x6c/0xa4 [ 160.093610] el0_svc_naked+0x34/0x38 [ 160.093621] ---[ end trace bccf0093cda2c538 ]--- [ 160.099041] = [ 160.107459] BUG kernfs_node_cache (Tainted: G S W O ): Object already free [ 160.115235] - [ 160.115235] [ 160.125151] Disabling lock debugging due to kernel taint [ 160.130626] INFO: Allocated in __kernfs_new_node+0x8c/0x3c0 age=11 cpu=2 pid=7098 [ 160.138314] kmem_cache_alloc+0x358/0x388 [ 160.142445] __kernfs_new_node+0x8c/0x3c0 [ 160.146590] kernfs_new_node+0x80/0xc8 [ 160.150462] kernfs_create_dir_ns+0x44/0xfc [ 160.154777] sysfs_create_dir_ns+0xa8/0x130 [ 160.158416] CPU5: update max cpu_capacity 1024 [ 160.159085] kobject_add_internal+0x278/0x650 [ 160.163567] kobject_add_varg+0xe0/0x130 [ 160.167606] kobject_add+0x15c/0x1d0 [ 160.168452] CPU5: update max cpu_capacity 780 [ 160.171287] get_device_parent+0x2d0/0x34c [ 160.175510] device_add+0x240/0xde0 [ 160.178371] CPU6: update max cpu_capacity 916 [ 160.179108] input_register_device+0x5f4/0xa0c [ 160.183686] uinput_ioctl_handler+0x1184/0x2198 [ 160.188346] uinput_ioctl+0x38/0x48 [ 160.191941] vfs_ioctl+0x7c/0xb4 [ 160.195261] do_vfs_ioctl+0x9ec/0x2350 [ 160.199111] SyS_ioctl+0x6c/0xa4 [ 160.202436] INFO: Freed in kernfs_put+0x2c8/0x434 age=14 cpu=0 pid=7096 [ 160.209230] kernfs_put+0x2c8/0x434 [ 160.212825] kobject_del+0x50/0xcc [ 160.216332] cleanup_glue_dir+0x124/0x16c [ 160.220456] device_del+0x55c/0x5c8 [ 160.224047] __input_unregister_device+0x274/0x2a8 [ 160.228974] input_unregister_device+0x90/0xd0 [ 160.233553] uinput_destroy_device+0x15c/0x1dc [ 160.238131] uinput_release+0x44/0x5c [ 160.241898] __fput+0x1f4/0x4e4 [ 160.245127] fput+0x20/0x2c [ 160.248358] task_work_run+0x9c/0x174 [ 160.252127] do_notify_resume+0x104/0x6bc [ 160.256253] work_pending+0x8/0x14 [ 160.259751] INFO: Slab 0xffbf0215ff00 objects=33 used=11 fp=0xffc0857ffd08 flags=0x8101 [ 160.268693] INFO: Object 0xffc0857ffd08 @offset=15624 fp=0xffc0857fefb0 [ 160.268693] [ 160.277721] Redzone ffc0857ffd00: bb bb bb bb bb bb bb bb [ 160.286656] Object ffc0857ffd08: 00 00 00 00 01 00 00 80 58 a2 37 45 c1 ff ff ff X.7E [ 160.296207] Object ffc0857ffd18: ae 21 10 0b 90 ff ff ff 20 fd 7f 85 c0 ff ff ff .!.. ... [ 160.305780] Object ffc0857ffd28: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.315342] Object ffc0857ffd38: 00 00 00 00 00 00 00 00 7d a3 25 69 00 00 00 00 }.%i [ 160.324896] Object ffc0857ffd48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.334446] Object ffc0857ffd58: 80 c0 28 47 c1 ff ff ff 00 00 00 00 00 00 00 00 ..(G [ 160.344000] Object ffc0857ffd68: 80 4a ce d1 c0 ff ff ff dc 32 01 00 01 00 00 00 .J...2.. [ 160.353554] Object ffc0857ffd78: 11 00 ed 41 00 00 00 00 00 00 00 00 00 00 00 00 ...A [ 160.363099] Redzone ffc0857ffd88: bb bb bb bb bb bb bb bb [ 160.372032] Padding ffc0857ffee0: 5a 5a 5a 5a 5a 5a 5a 5a [ 160.378299] CPU6: update max cpu_capacity 780 [ 160.380971] CPU: 4 PID: 7098 Comm: syz-executor Tainted: G S B W O 4.14.98+ #1 So, avoid the race by taking a udev lock inside `uinput_release()`. Change-Id: I3bbb07589b7b6e0e1b3bea572b5eb4f6b09774d6 Signed-off-by: Mukesh Ojha Cc:Gaurav Kohli Cc:Peter Hutterer Cc:Martin Kepplinger Cc:"Paul E. McKenney" --- drivers/input/misc/uinput.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 26ec603f..a3fb3b1 100644 --- a/drivers/input/misc/uinput.c +++ b/drivers/input/misc/uinput.c @@ -714,
Re: [PATCH RESEND -next] Input: uinput - Avoid Use-After-Free with udev lock
Please don't consider this patch, i will send v2 of this. Thanks, Mukesh On 3/28/2019 3:55 PM, Mukesh Ojha wrote: uinput_destroy_device() gets called from two places. In one place, uinput_ioctl_handler() it is protected under a lock udev->mutex but same is not true for other place inside uinput_release(). This can result in a race where udev device gets freed while it is in use. [ 160.093398] Call trace: [ 160.093417] kernfs_get+0x64/0x88 [ 160.093438] kernfs_new_node+0x94/0xc8 [ 160.093450] kernfs_create_dir_ns+0x44/0xfc [ 160.093463] sysfs_create_dir_ns+0xa8/0x130 [ 160.093479] kobject_add_internal+0x278/0x650 [ 160.093491] kobject_add_varg+0xe0/0x130 [ 160.093502] kobject_add+0x15c/0x1d0 [ 160.093518] device_add+0x2bc/0xde0 [ 160.093533] input_register_device+0x5f4/0xa0c [ 160.093547] uinput_ioctl_handler+0x1184/0x2198 [ 160.093560] uinput_ioctl+0x38/0x48 [ 160.093573] vfs_ioctl+0x7c/0xb4 [ 160.093585] do_vfs_ioctl+0x9ec/0x2350 [ 160.093597] SyS_ioctl+0x6c/0xa4 [ 160.093610] el0_svc_naked+0x34/0x38 [ 160.093621] ---[ end trace bccf0093cda2c538 ]--- [ 160.099041] = [ 160.107459] BUG kernfs_node_cache (Tainted: G S W O ): Object already free [ 160.115235] - [ 160.115235] [ 160.125151] Disabling lock debugging due to kernel taint [ 160.130626] INFO: Allocated in __kernfs_new_node+0x8c/0x3c0 age=11 cpu=2 pid=7098 [ 160.138314] kmem_cache_alloc+0x358/0x388 [ 160.142445] __kernfs_new_node+0x8c/0x3c0 [ 160.146590] kernfs_new_node+0x80/0xc8 [ 160.150462] kernfs_create_dir_ns+0x44/0xfc [ 160.154777] sysfs_create_dir_ns+0xa8/0x130 [ 160.158416] CPU5: update max cpu_capacity 1024 [ 160.159085] kobject_add_internal+0x278/0x650 [ 160.163567] kobject_add_varg+0xe0/0x130 [ 160.167606] kobject_add+0x15c/0x1d0 [ 160.168452] CPU5: update max cpu_capacity 780 [ 160.171287] get_device_parent+0x2d0/0x34c [ 160.175510] device_add+0x240/0xde0 [ 160.178371] CPU6: update max cpu_capacity 916 [ 160.179108] input_register_device+0x5f4/0xa0c [ 160.183686] uinput_ioctl_handler+0x1184/0x2198 [ 160.188346] uinput_ioctl+0x38/0x48 [ 160.191941] vfs_ioctl+0x7c/0xb4 [ 160.195261] do_vfs_ioctl+0x9ec/0x2350 [ 160.199111] SyS_ioctl+0x6c/0xa4 [ 160.202436] INFO: Freed in kernfs_put+0x2c8/0x434 age=14 cpu=0 pid=7096 [ 160.209230] kernfs_put+0x2c8/0x434 [ 160.212825] kobject_del+0x50/0xcc [ 160.216332] cleanup_glue_dir+0x124/0x16c [ 160.220456] device_del+0x55c/0x5c8 [ 160.224047] __input_unregister_device+0x274/0x2a8 [ 160.228974] input_unregister_device+0x90/0xd0 [ 160.233553] uinput_destroy_device+0x15c/0x1dc [ 160.238131] uinput_release+0x44/0x5c [ 160.241898] __fput+0x1f4/0x4e4 [ 160.245127] fput+0x20/0x2c [ 160.248358] task_work_run+0x9c/0x174 [ 160.252127] do_notify_resume+0x104/0x6bc [ 160.256253] work_pending+0x8/0x14 [ 160.259751] INFO: Slab 0xffbf0215ff00 objects=33 used=11 fp=0xffc0857ffd08 flags=0x8101 [ 160.268693] INFO: Object 0xffc0857ffd08 @offset=15624 fp=0xffc0857fefb0 [ 160.268693] [ 160.277721] Redzone ffc0857ffd00: bb bb bb bb bb bb bb bb [ 160.286656] Object ffc0857ffd08: 00 00 00 00 01 00 00 80 58 a2 37 45 c1 ff ff ff X.7E [ 160.296207] Object ffc0857ffd18: ae 21 10 0b 90 ff ff ff 20 fd 7f 85 c0 ff ff ff .!.. ... [ 160.305780] Object ffc0857ffd28: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.315342] Object ffc0857ffd38: 00 00 00 00 00 00 00 00 7d a3 25 69 00 00 00 00 }.%i [ 160.324896] Object ffc0857ffd48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.334446] Object ffc0857ffd58: 80 c0 28 47 c1 ff ff ff 00 00 00 00 00 00 00 00 ..(G [ 160.344000] Object ffc0857ffd68: 80 4a ce d1 c0 ff ff ff dc 32 01 00 01 00 00 00 .J...2.. [ 160.353554] Object ffc0857ffd78: 11 00 ed 41 00 00 00 00 00 00 00 00 00 00 00 00 ...A [ 160.363099] Redzone ffc0857ffd88: bb bb bb bb bb bb bb bb [ 160.372032] Padding ffc0857ffee0: 5a 5a 5a 5a 5a 5a 5a 5a [ 160.378299] CPU6: update max cpu_capacity 780 [ 160.380971] CPU: 4 PID: 7098 Comm: syz-executor Tainted: G S B W O 4.14.98+ #1 So, avoid the race by taking a udev lock inside `uinput_release()`. Change-Id: I3bbb07589b7b6e0e1b3bea572b5eb4f6b09774d6 Signed-off-by: Mukesh Ojha Cc: Gaurav Kohli Cc: Peter Hutterer Cc: Martin Kepplinger Cc: "Paul E. McKenney" --- drivers/input/misc/uinput.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 26ec603f..a3fb3b1 100644 --- a/drivers/input/misc/uinput.c +++ b/drivers/input/misc/uinput.c @@ -
Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)
Mathieu Desnoyers writes: > Hi Carlos, > > - On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote: ... > > [...] >>> +++ b/sysdeps/unix/sysv/linux/powerpc/bits/rseq.h > [...] >>> +/* Signature required before each abort handler code. */ >>> +#define RSEQ_SIG 0x53053053 >> >> Why isn't this an opcode specific to power? > > On powerpc 32/64, the abort is placed in a __rseq_failure executable section: > > #define RSEQ_ASM_DEFINE_ABORT(label, abort_label) > \ > ".pushsection __rseq_failure, \"ax\"\n\t" > \ > ".long " __rseq_str(RSEQ_SIG) "\n\t" > \ > __rseq_str(label) ":\n\t" > \ > "b %l[" __rseq_str(abort_label) "]\n\t" > \ > ".popsection\n\t" > > That section only contains snippets of those trampolines. Arguably, it would > be > good if disassemblers could find valid instructions there. Boqun Feng could > perhaps > shed some light on this signature choice ? Now would be a good time to decide > once and for all whether a valid instruction would be a better choice. I'm a bit vague on what we're trying to do here. But it seems like you want some sort of "eye catcher" prior to the branch? That value is a valid instruction on current CPUs (rlwimi. r5,r24,6,1,9), and even if it wasn't it could become one in future. If you change it to 0x8053530 that is both a valid instruction and is a nop (conditional trap immediate but with no conditions set). cheers
[PATCH] RISC-V: Fix Maximum Physical Memory 2GiB option for 64bit systems
The Maximum Physical Memory 2GiB option for 64bit systems is currently broken because kernel hangs at boot-time when this option is enabled and the underlying system has more than 2GiB memory. This issue can be easily reproduced on SiFive Unleashed board where we have 8GiB of memory. This patch fixes above issue by reserving unusable memory region in setup_bootmem(). Signed-off-by: Anup Patel --- arch/riscv/mm/init.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 5fd8c922e1c2..6b063f20a9d0 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -121,6 +121,14 @@ void __init setup_bootmem(void) */ memblock_reserve(reg->base, vmlinux_end - reg->base); mem_size = min(reg->size, (phys_addr_t)-PAGE_OFFSET); + + /* +* Reserve from the end of usable area to the end of +* region +*/ + if ((reg->base + mem_size) < end) + memblock_reserve(reg->base + mem_size, +end - reg->base - mem_size); } } BUG_ON(mem_size == 0); -- 2.17.1
Re: [RFC PATCH 3/5] documention: leds: Add multicolor class documentation
On Mon, 1 Apr 2019 23:27:10 +0200 Pavel Machek wrote: > One was discussed before -- have single file which contains > coefficients for r/g/b channels. That would somehow break the rule one file/one value. Although you could consider the whole color one value, that way it would not be broken...
[PATCH v4] arm/mach-at91/pm : fix possible object reference leak
of_find_device_by_node() takes a reference to the struct device
when it finds a match via get_device. When returning error we should
call put_device.
Reviewed-by: Mukesh Ojha
Signed-off-by: Peng Hao
---
arch/arm/mach-at91/pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 51e808a..38511a5 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -591,13 +591,13 @@ static int __init at91_pm_backup_init(void)
np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-securam");
if (!np)
- goto securam_fail;
+ goto securam_fail_no_ref_dev;
pdev = of_find_device_by_node(np);
of_node_put(np);
if (!pdev) {
pr_warn("%s: failed to find securam device!\n", __func__);
- goto securam_fail;
+ goto securam_fail_no_ref_dev;
}
sram_pool = gen_pool_get(&pdev->dev, NULL);
@@ -620,6 +620,8 @@ static int __init at91_pm_backup_init(void)
return 0;
securam_fail:
+ put_device(&pdev->dev);
+securam_fail_no_ref_dev:
iounmap(pm_data.sfrbu);
pm_data.sfrbu = NULL;
return ret;
--
1.8.3.1
[PATCH v5] HID: intel-ish-hid: ISH firmware loader client driver
This driver adds support for loading Intel Integrated Sensor Hub (ISH) firmware from host file system to ISH SRAM and start execution. At power-on, the ISH subsystem shall boot to an interim Shim loader-firmware, which shall expose an ISHTP loader device. The driver implements an ISHTP client that communicates with the Shim ISHTP loader device over the intel-ish-hid stack, to download the main ISH firmware. Signed-off-by: Rushikesh S Kadam Acked-by: Srinivas Pandruvada Acked-by: Nick Crews Tested-by: Jett Rink --- The patches are baselined to hid git tree, branch for-5.2/ish https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.2/ish v5 - Added the Acked-by & Tested-by to commit message. No other change. v4 - Changed process_recv() to wake the caller in case of error as well. Earlier caller would wait until timeout on an error. - Change sequence of few checks in process_recv(). v3 - Moved a couple of sanity checks from loader_cl_send() to process_recv(). - Several minor changes to address review comments. v2 - Change loader_cl_send() so that the calling function shall allocate and pass the buffer to be used for receiving firwmare response data. Corresponding changes in calling function and process_recv(). - Introduced struct response_info to encapsulate and pass data between from the process_recv() callback to calling function loader_cl_send(). - Keep count of host firmware load retries, and fail after 3 unsuccessful attempts. - Dropped report_bad_packets() function previously used for keeping count of bad packets. - Inlined loader_ish_hw_reset()'s functionality v1 - Initial version. drivers/hid/Makefile|1 + drivers/hid/intel-ish-hid/Kconfig | 15 + drivers/hid/intel-ish-hid/Makefile |3 + drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 1085 +++ 4 files changed, 1104 insertions(+) create mode 100644 drivers/hid/intel-ish-hid/ishtp-fw-loader.c diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 170163b..d8d393e 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -134,3 +134,4 @@ obj-$(CONFIG_USB_KBD) += usbhid/ obj-$(CONFIG_I2C_HID) += i2c-hid/ obj-$(CONFIG_INTEL_ISH_HID)+= intel-ish-hid/ +obj-$(INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ish-hid/ diff --git a/drivers/hid/intel-ish-hid/Kconfig b/drivers/hid/intel-ish-hid/Kconfig index 519e4c8..786adbc 100644 --- a/drivers/hid/intel-ish-hid/Kconfig +++ b/drivers/hid/intel-ish-hid/Kconfig @@ -14,4 +14,19 @@ config INTEL_ISH_HID Broxton and Kaby Lake. Say Y here if you want to support Intel ISH. If unsure, say N. + +config INTEL_ISH_FIRMWARE_DOWNLOADER + tristate "Host Firmware Load feature for Intel ISH" + depends on INTEL_ISH_HID + depends on X86 + help + The Integrated Sensor Hub (ISH) enables the kernel to offload + sensor polling and algorithm processing to a dedicated low power + processor in the chipset. + + The Host Firmware Load feature adds support to load the ISH + firmware from host file system at boot. + + Say M here if you want to support Host Firmware Loading feature + for Intel ISH. If unsure, say N. endmenu diff --git a/drivers/hid/intel-ish-hid/Makefile b/drivers/hid/intel-ish-hid/Makefile index 825b70a..2de97e4 100644 --- a/drivers/hid/intel-ish-hid/Makefile +++ b/drivers/hid/intel-ish-hid/Makefile @@ -20,4 +20,7 @@ obj-$(CONFIG_INTEL_ISH_HID) += intel-ishtp-hid.o intel-ishtp-hid-objs := ishtp-hid.o intel-ishtp-hid-objs += ishtp-hid-client.o +obj-$(CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ishtp-loader.o +intel-ishtp-loader-objs += ishtp-fw-loader.o + ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp diff --git a/drivers/hid/intel-ish-hid/ishtp-fw-loader.c b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c new file mode 100644 index 000..e770e22 --- /dev/null +++ b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c @@ -0,0 +1,1085 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * ISH-TP client driver for ISH firmware loading + * + * Copyright (c) 2019, Intel Corporation. + */ + +#include +#include +#include +#include +#include +#include + +/* Number of times we attempt to load the firmware before giving up */ +#define MAX_LOAD_ATTEMPTS 3 + +/* ISH TX/RX ring buffer pool size */ +#define LOADER_CL_RX_RING_SIZE 1 +#define LOADER_CL_TX_RING_SIZE 1 + +/* + * ISH Shim firmware loader reserves 4 Kb buffer in SRAM. The buffer is + * used to temporarily hold the data transferred from host to Shim + * firmware loader. Reason for the odd size of 3968 bytes? Each IPC + * transfer is 128 bytes (= 4 bytes header + 124 bytes payload). So the + * 4 Kb buffer can hold maximum of 32 IPC transfers, which means we can + * have a max payload of 3968 bytes (= 32 x 124 payload). + */ +#define LOADER_
Applied "ASoC: dpcm: skip missing substream while applying symmetry" to the asoc tree
The patch
ASoC: dpcm: skip missing substream while applying symmetry
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 6246f283d5e02ac757bd8d9bacde8fdc54c4582d Mon Sep 17 00:00:00 2001
From: Jerome Brunet
Date: Mon, 1 Apr 2019 15:03:54 +0200
Subject: [PATCH] ASoC: dpcm: skip missing substream while applying symmetry
If for any reason, the backend does not have the requested substream
(like capture on a playback only backend), the BE will be skipped in
dpcm_be_dai_startup().
However, dpcm_apply_symmetry() does not skip those BE and will
dereference the be_substream (NULL) pointer anyway.
Like in dpcm_be_dai_startup(), just skip those BE.
Fixes: 906c7d690c3b ("ASoC: dpcm: Apply symmetry for DPCM")
Signed-off-by: Jerome Brunet
Signed-off-by: Mark Brown
---
sound/soc/soc-pcm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 7fe5321000e8..2d5d5cac4ba6 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -1911,10 +1911,15 @@ static int dpcm_apply_symmetry(struct snd_pcm_substream
*fe_substream,
struct snd_soc_pcm_runtime *be = dpcm->be;
struct snd_pcm_substream *be_substream =
snd_soc_dpcm_get_substream(be, stream);
- struct snd_soc_pcm_runtime *rtd = be_substream->private_data;
+ struct snd_soc_pcm_runtime *rtd;
struct snd_soc_dai *codec_dai;
int i;
+ /* A backend may not have the requested substream */
+ if (!be_substream)
+ continue;
+
+ rtd = be_substream->private_data;
if (rtd->dai_link->be_hw_params_fixup)
continue;
--
2.20.1
Applied "regulator: bcm590xx: Convert to use simplified DT parsing" to the regulator tree
The patch
regulator: bcm590xx: Convert to use simplified DT parsing
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a4e73625cb12f662b2a72d292f34232c61cca47f Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Mon, 1 Apr 2019 22:42:36 +0800
Subject: [PATCH] regulator: bcm590xx: Convert to use simplified DT parsing
Use regulator core's simplified DT parsing code to simply the driver
implementation.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/bcm590xx-regulator.c | 105 +
1 file changed, 2 insertions(+), 103 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index e49c0a7d5dd5..85ccc93b2bb6 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -103,10 +103,6 @@
((n > BCM590XX_REG_VSR) && (n < BCM590XX_REG_VBUS))
#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
-struct bcm590xx_board {
- struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
-};
-
/* LDO group A: supported voltages in microvolts */
static const unsigned int ldo_a_table[] = {
120, 180, 250, 270, 280,
@@ -280,105 +276,15 @@ static const struct regulator_ops bcm590xx_ops_vbus = {
.disable= regulator_disable_regmap,
};
-#define BCM590XX_MATCH(_name, _id) \
- { \
- .name = #_name, \
- .driver_data = (void *)&bcm590xx_regs[BCM590XX_REG_##_id], \
- }
-
-static struct of_regulator_match bcm590xx_matches[] = {
- BCM590XX_MATCH(rfldo, RFLDO),
- BCM590XX_MATCH(camldo1, CAMLDO1),
- BCM590XX_MATCH(camldo2, CAMLDO2),
- BCM590XX_MATCH(simldo1, SIMLDO1),
- BCM590XX_MATCH(simldo2, SIMLDO2),
- BCM590XX_MATCH(sdldo, SDLDO),
- BCM590XX_MATCH(sdxldo, SDXLDO),
- BCM590XX_MATCH(mmcldo1, MMCLDO1),
- BCM590XX_MATCH(mmcldo2, MMCLDO2),
- BCM590XX_MATCH(audldo, AUDLDO),
- BCM590XX_MATCH(micldo, MICLDO),
- BCM590XX_MATCH(usbldo, USBLDO),
- BCM590XX_MATCH(vibldo, VIBLDO),
- BCM590XX_MATCH(csr, CSR),
- BCM590XX_MATCH(iosr1, IOSR1),
- BCM590XX_MATCH(iosr2, IOSR2),
- BCM590XX_MATCH(msr, MSR),
- BCM590XX_MATCH(sdsr1, SDSR1),
- BCM590XX_MATCH(sdsr2, SDSR2),
- BCM590XX_MATCH(vsr, VSR),
- BCM590XX_MATCH(gpldo1, GPLDO1),
- BCM590XX_MATCH(gpldo2, GPLDO2),
- BCM590XX_MATCH(gpldo3, GPLDO3),
- BCM590XX_MATCH(gpldo4, GPLDO4),
- BCM590XX_MATCH(gpldo5, GPLDO5),
- BCM590XX_MATCH(gpldo6, GPLDO6),
- BCM590XX_MATCH(vbus, VBUS),
-};
-
-static struct bcm590xx_board *bcm590xx_parse_dt_reg_data(
- struct platform_device *pdev,
- struct of_regulator_match **bcm590xx_reg_matches)
-{
- struct bcm590xx_board *data;
- struct device_node *np = pdev->dev.parent->of_node;
- struct device_node *regulators;
- struct of_regulator_match *matches = bcm590xx_matches;
- int count = ARRAY_SIZE(bcm590xx_matches);
- int idx = 0;
- int ret;
-
- if (!np) {
- dev_err(&pdev->dev, "of node not found\n");
- return NULL;
- }
-
- data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
- if (!data)
- return NULL;
-
- np = of_node_get(np);
- regulators = of_get_child_by_name(np, "regulators");
- if (!regulators) {
- dev_warn(&pdev->dev, "regulator node not found\n");
- return NULL;
- }
-
- ret = of_regulator_match(&pdev->dev, regulators, matches, count);
- of_node_put(regulators);
- if (ret < 0) {
- dev_err(&pdev->dev, "Error parsing regulator init data: %d\n",
- ret);
- return NULL;
- }
-
- *bcm590xx_reg_matches = matches;
-
- for (idx = 0; idx < count; idx++) {
- if (!matches[idx].init_data || !matches[idx].of_node)
- continue;
-
- data->bcm590xx_pmu_init_data[idx] = matches[idx].init_data;
- }
-
- retur
Re: [RFC PATCH 5/5] leds: multicolor: Introduce a multicolor class definition
Hi Dan,
On Mon, 1 Apr 2019 12:34:00 -0500
Dan Murphy wrote:
> +static ssize_t sync_store(struct device *dev,
> + struct device_attribute *sync_attr,
> + const char *buf, size_t size)
> +{
> + struct led_classdev_mc_data *data = container_of(sync_attr,
> + struct
> led_classdev_mc_data,
> + sync_attr);
> + struct led_classdev_mc *mcled_cdev = data->mcled_cdev;
> + struct led_classdev *led_cdev = &mcled_cdev->led_cdev;
> + const struct led_multicolor_ops *ops = mcled_cdev->ops;
> + struct led_classdev_mc_priv *priv;
> + unsigned long sync_value;
> + ssize_t ret = -EINVAL;
> +
> + mutex_lock(&led_cdev->led_access);
> +
> + if (!mcled_cdev->sync_enabled)
> + goto unlock;
This lock is redundant, you could just put
if (mcled_cdev->sync_enabled)
return ret;
before the lock.
Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
On Tue, Apr 02, 2019 at 07:05:35AM +0200, H. Nikolaus Schaller wrote: > > Am 02.04.2019 um 06:02 schrieb Linus Walleij : Please delete unneeded context from mails when replying. Doing this makes it much easier to find your reply in the message, helping ensure it won't be missed by people scrolling through the irrelevant quoted material. > >>> This does not work because there are devices that requires spi-cs-high to > >>> be > >>> respected and the DTS second cell GPIO flag to be ignored. > >> Then, those should be fixed... > > This can't be done because some old systems (mostly powerpc) > > added between 2008-2013 do not know about GPIO flags and > > have DTBs deployed in firmware that need to keep working. > > They cannot be fixed. > The question is if it is even possible to deploy a new kernel > for such devices and if anyone wants to do... It's relatively common, especially with older devices, for people to be perfectly happy to update the kernel and do so frequently but unwilling to update the bootloader as the procedure for recovering a broken bootloader is difficult or perhaps not even possible. > This also gives another idea: make it depend on "powerpc". That won't fly, the code has always been architecture neutral. > > Dunno about this, it looks fragile, I would prefer to keep all working. > > But I will listen to reason. > Reason why I propose a CONFIG option is: > if someone is able to compile and deploy a v5.1 kernel for some device which > has (old) and problematic DTB in ROM he/she must have access to the .config. > So it is easy to modify it to enable legacy handling of spi-cs-high. And keep > it disabled for all others. This assumes people aren't able to run a distro kernel... signature.asc Description: PGP signature
Re: [PATCH 2/2] iio: counter: Add support for Milbeaut Updown Counter
Hi Jonathan,
Thank you for your review.
On 2019/03/31 3:43, Jonathan Cameron wrote:
On Tue, 26 Mar 2019 15:33:32 +0900
Shinji Kanematsu wrote:
Add support for Milbeaut Updown Counter, that can be used as counter
or quadrature encoder.
Signed-off-by: Shinji Kanematsu
A few minor comments inline. The counter subsystem will provide a cleaner
way of describing this. Please look to that for v2.
Hopefully William will give some feedback as well.
OK, I understand.
Jonathan
---
drivers/iio/counter/Kconfig | 12 +
drivers/iio/counter/Makefile | 1 +
drivers/iio/counter/milbeaut-updown.h | 38 +++
drivers/iio/counter/milbeaut-updown_cnt.c | 385 ++
4 files changed, 436 insertions(+)
create mode 100644 drivers/iio/counter/milbeaut-updown.h
create mode 100644 drivers/iio/counter/milbeaut-updown_cnt.c
diff --git a/drivers/iio/counter/Kconfig b/drivers/iio/counter/Kconfig
index bf1e559..a665f61 100644
--- a/drivers/iio/counter/Kconfig
+++ b/drivers/iio/counter/Kconfig
@@ -31,4 +31,16 @@ config STM32_LPTIMER_CNT
To compile this driver as a module, choose M here: the
module will be called stm32-lptimer-cnt.
+
+config MILBEAUT_UPDOWN_CNT
+ tristate "Milbeaut Updown Counter driver"
+ depends on OF
+ depends on ARCH_MILBEAUT || COMPILE_TEST
+ help
+ Select this option to enable Milbeaut Updown Counter quadrature
encoder
+ and counter driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called milbeaut-updown-cnt.
+
endmenu
diff --git a/drivers/iio/counter/Makefile b/drivers/iio/counter/Makefile
index 1b9a896..0cb708b 100644
--- a/drivers/iio/counter/Makefile
+++ b/drivers/iio/counter/Makefile
@@ -6,3 +6,4 @@
obj-$(CONFIG_104_QUAD_8) += 104-quad-8.o
obj-$(CONFIG_STM32_LPTIMER_CNT) += stm32-lptimer-cnt.o
+obj-$(CONFIG_MILBEAUT_UPDOWN_CNT) += milbeaut-updown_cnt.o
diff --git a/drivers/iio/counter/milbeaut-updown.h
b/drivers/iio/counter/milbeaut-updown.h
new file mode 100644
index 000..9a038ad
--- /dev/null
+++ b/drivers/iio/counter/milbeaut-updown.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Milbeaut Updown parent driver
+ * Copyright (C) 2019 Socionext Inc.
+ */
+
+#ifndef _LINUX_MILBEAUT_UPDOWN_H_
+#define _LINUX_MILBEAUT_UPDOWN_H_
+
+#define MLB_UPDOWN_UDCR0x0 /* Updown Count Reg
*/
+#define MLB_UPDOWN_RCR 0x4 /* Reload Compare Reg */
+#define MLB_UPDOWN_CSR 0xC /* Counter Status Reg */
+#define MLB_UPDOWN_CCR 0x14/* Counter Control Reg */
+
+/* MLB_UPDOWN_CSR - bit fields */
+#define MLB_UPDOWN_CSTRBIT(7)
+#define MLB_UPDOWN_UDIEBIT(5)
+#define MLB_UPDOWN_CMPFBIT(4)
+#define MLB_UPDOWN_OVFFBIT(3)
+#define MLB_UPDOWN_UDFFBIT(2)
+
+/* MLB_UPDOWN_CCR - bit fields */
+#define MLB_UPDOWN_FIXED BIT(15)
+#define MLB_UPDOWN_CMS GENMASK(11, 10)
+#define MLB_UPDOWN_CES GENMASK(9, 8)
+#define MLB_UPDOWN_CTUTBIT(6)
+#define MLB_UPDOWN_RLDEBIT(4)
+
+/* MLB_UPDOWN max count value */
+#define MLB_UPDOWN_MAX_COUNT 0x
+
+/* MLB_UPDOWN rising edge detection */
+#define MLB_UPDOWN_RISING_EDGE BIT(9)
+
+/* MLB_UPDOWN mode */
+#define MLB_UPDOWN_MODE1
+
+#endif
diff --git a/drivers/iio/counter/milbeaut-updown_cnt.c
b/drivers/iio/counter/milbeaut-updown_cnt.c
new file mode 100644
index 000..a58709a
--- /dev/null
+++ b/drivers/iio/counter/milbeaut-updown_cnt.c
@@ -0,0 +1,385 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Milbeaut Updown counter driver
+ *
+ * Copyright (C) 2019 Socionext Inc.
I'm fussy about pointless lines. The one below doesn't add anything ;)
That's right, correct it.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "milbeaut-updown.h"
+
+#define MILBEAUT_UPDOWN_IRQ_NAME "milbeaut_updown_event"
+#define MILBEAUT_UPDOWN_MAX_REGISTER 0x1f
+
+static const struct regmap_config milbeaut_updown_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = MILBEAUT_UPDOWN_MAX_REGISTER,
+};
+struct milbeaut_updown_cnt {
+ struct device *dev;
+ struct regmap *regmap;
+ struct clk *clk;
+ u32 preset;
+ u32 polarity;
+ u32 quadrature_mode;
+};
+
+static int milbeaut_updown_is_enabled(struct milbeaut_updown_cnt *priv)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(priv->regmap, MLB_UPDOWN_CSR, &val);
+ if (ret)
+ return ret;
+
+ return FIELD_GET(MLB_UPDOWN_CSTR, val);
+}
+
+static int milbeaut_updown_setup(struct milbeaut_updown_cnt *priv,
+ int
[PATCH V1] mmc: tegra: add sdhci tegra suspend and resume
This patch adds suspend and resume PM ops for tegra SDHCI.
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 45 +-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index eafaaefab4a6..68263ea4a93e 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1611,11 +1611,54 @@ static int sdhci_tegra_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int sdhci_tegra_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ int ret;
+
+ if (host->mmc->caps2 & MMC_CAP2_CQE) {
+ ret = cqhci_suspend(host->mmc);
+ if (ret)
+ return ret;
+ }
+
+ ret = sdhci_suspend_host(host);
+ if (ret)
+ return ret;
+
+ clk_disable_unprepare(pltfm_host->clk);
+ return 0;
+}
+
+static int sdhci_tegra_resume(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ int ret;
+
+ clk_prepare_enable(pltfm_host->clk);
+
+ ret = sdhci_resume_host(host);
+ if (ret)
+ return ret;
+
+ if (host->mmc->caps2 & MMC_CAP2_CQE)
+ return cqhci_resume(host->mmc);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(sdhci_tegra_dev_pm_ops, sdhci_tegra_suspend,
+sdhci_tegra_resume);
+
static struct platform_driver sdhci_tegra_driver = {
.driver = {
.name = "sdhci-tegra",
.of_match_table = sdhci_tegra_dt_match,
- .pm = &sdhci_pltfm_pmops,
+ .pm = &sdhci_tegra_dev_pm_ops,
},
.probe = sdhci_tegra_probe,
.remove = sdhci_tegra_remove,
--
2.7.4
Re: [PATCH] lib: Fix possible incorrect result from rational fractions helper
On Sat, 30 Mar 2019 13:58:55 -0700 Trent Piepho wrote: > In some cases the previous algorithm would not return the closest > approximation. This would happen when a semi-convergent was the > closest, as the previous algorithm would only consider convergents. > > As an example, consider an initial value of 5/4, and trying to find the > closest approximation with a maximum of 4 for numerator and denominator. > The previous algorithm would return 1/1 as the closest approximation, > while this version will return the correct answer of 4/3. > > To do this, the main loop performs effectively the same operations as it > did before. It must now keep track of the last three approximations, > n2/d2 .. n0/d0, while before it only needed the last two. > > If an exact answer is not found, the algorithm will now calculate the > best semi-convergent term, t, which is a single expression with two > divisions: > min((max_numerator - n0) / n1, (max_denominator - d0) / d1) > > This will be used if it is better than previous convergent. The test > for this is generally a simple comparison, 2*t > a. But in an edge > case, where the convergent's final term is even and the best allowable > semi-convergent has a final term of exactly half the convergent's final > term, the more complex comparison (d0*dp > d1*d) is used. > > I also wrote some comments explaining the code. While one still needs > to look up the math elsewhere, they should help a lot to follow how the > code relates to that math. What are the userspace-visible runtime effects of this change?
Re: [PATCHv3] x86/boot/KASLR: skip the specified crashkernel region
On Tue, Apr 02, 2019 at 12:10:46PM +0800, Pingfan Liu wrote:
>crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
or or?
>fail to reserve the required memory region if KASLR puts kernel into the
>region. To avoid this uncertainty, asking KASLR to skip the required
>region.
>
>Signed-off-by: Pingfan Liu
>Cc: Thomas Gleixner
>Cc: Ingo Molnar
>Cc: Borislav Petkov
>Cc: "H. Peter Anvin"
>Cc: Baoquan He
>Cc: Will Deacon
>Cc: Nicolas Pitre
>Cc: Pingfan Liu
>Cc: Chao Fan
>Cc: "Kirill A. Shutemov"
>Cc: Ard Biesheuvel
>Cc: linux-kernel@vger.kernel.org
>---
[...]
>+
>+/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset options
>*/
Before review, I want to say more about the background.
It's very hard to review the code for someone who is not so familiar
with kdump, so could you please explain more ahout
the uasge of crashkernel=range1:size1[,range2:size2,...]@offset.
And also there are so many jobs who are parsing string. So I really
need your help to understand the PATCH.
>+static void mem_avoid_specified_crashkernel_region(char *option)
>+{
>+ unsigned long long crash_size, crash_base = 0;
>+ char*first_colon, *first_space, *cur = option;
Is there a tab after char?
>+
>+ first_colon = strchr(option, ':');
>+ first_space = strchr(option, ' ');
>+ /* if contain ":" */
>+ if (first_colon && (!first_space || first_colon < first_space)) {
>+ int i;
>+ u64 total_sz = 0;
>+ struct boot_e820_entry *entry;
>+
>+ for (i = 0; i < boot_params->e820_entries; i++) {
>+ entry = &boot_params->e820_table[i];
>+ /* Skip non-RAM entries. */
>+ if (entry->type != E820_TYPE_RAM)
>+ continue;
>+ total_sz += entry->size;
I wonder whether it's needed to consider the memory ranges here.
I think it's OK to only record the regions should to be avoid.
I remeber I ever talked with Baoquan about the similiar problems.
@Baoquan, I am not sure if I misunderstand something.
Thanks,
Chao Fan
>+ }
>+ handle_crashkernel_mem(option, total_sz, &crash_size,
>+ &crash_base);
>+ } else {
>+ crash_size = memparse(option, &cur);
>+ if (option == cur)
>+ return;
>+ while (*cur && *cur != ' ' && *cur != '@')
>+ cur++;
>+ if (*cur == '@') {
>+ option = cur + 1;
>+ crash_base = memparse(option, &cur);
>+ }
>+ }
>+ if (crash_base) {
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
>+ } else {
>+ /*
>+ * Clearing mem_avoid if no offset is given. This is consistent
>+ * with kernel, which uses the last crashkernel= option.
>+ */
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = 0;
>+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = 0;
>+ }
>+}
>
> static void handle_mem_options(void)
> {
>@@ -248,7 +358,7 @@ static void handle_mem_options(void)
> u64 mem_size;
>
> if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
>- !strstr(args, "hugepages"))
>+ !strstr(args, "hugepages") && !strstr(args, "crashkernel="))
> return;
>
> tmp_cmdline = malloc(len + 1);
>@@ -284,6 +394,8 @@ static void handle_mem_options(void)
> goto out;
>
> mem_limit = mem_size;
>+ } else if (strstr(param, "crashkernel")) {
>+ mem_avoid_specified_crashkernel_region(val);
> }
> }
>
>@@ -412,7 +524,7 @@ static void mem_avoid_init(unsigned long input, unsigned
>long input_size,
>
> /* We don't need to set a mapping for setup_data. */
>
>- /* Mark the memmap regions we need to avoid */
>+ /* Mark the regions we need to avoid */
> handle_mem_options();
>
> /* Enumerate the immovable memory regions */
>--
>2.7.4
>
>
>
Re: [PATCH] vfio/type1: Limit DMA mappings per container
On Mon, Apr 01, 2019 at 10:34:13PM -0600, Alex Williamson wrote:
> On Tue, 2 Apr 2019 10:41:15 +0800
> Peter Xu wrote:
>
> > On Mon, Apr 01, 2019 at 02:16:52PM -0600, Alex Williamson wrote:
> >
> > [...]
> >
> > > @@ -1081,8 +1088,14 @@ static int vfio_dma_do_map(struct vfio_iommu
> > > *iommu,
> > > goto out_unlock;
> > > }
> > >
> > > + if (!atomic_add_unless(&iommu->dma_avail, -1, 0)) {
> > > + ret = -ENOSPC;
> > > + goto out_unlock;
> > > + }
> > > +
> > > dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> > > if (!dma) {
> > > + atomic_inc(&iommu->dma_avail);
> >
> > This should be the only special path to revert the change. Not sure
> > whether this can be avoided by simply using atomic_read() or even
> > READ_ONCE() (I feel like we don't need atomic ops with dma_avail
> > because we've had the mutex but it of course it doesn't hurt...) to
> > replace atomic_add_unless() above to check against zero then we do
> > +1/-1 in vfio_[un]link_dma() only. But AFAICT this patch is correct.
>
> Thanks for the review, you're right, we're only twiddling this atomic
> while holding the iommu->lock mutex, so it appears unnecessary. Since
> we're within the mutex, I think we don't even need a READ_ONCE. We can
> simple test it before alloc and decrement after. Am I missing something
> that would specifically require READ_ONCE within our mutex critical
> section? Thanks,
I don't know very clear on this and I'd be glad to learn about that.
My understanding is that [READ|WRITE]_ONCE() is the same as volatile
mem operation and will make sure we don't keep variables in the
registers. So if the mutex semantics can support that (say, a "*addr
= val" following with a mutex_unlock will make sure "val" will
definitely land into memory of "&addr") then I do think it's fine even
without it (which corresponds to WRITE_ONCE(&addr, val) in this case).
Thanks,
--
Peter Xu
Re: linux-next: build failure after merge of the sound-asoc tree
On Mon, Apr 01, 2019 at 10:11:44PM +1100, Michael Ellerman wrote: > Anyway I think what you've done in next, make the code depend on > COMMON_CLOCK, is the best option. If anyone cares about that driver on > powerpc platforms that don't support COMMON_CLOCK they should speak up. It's probably fine for now for this one driver but it's going to cause issues going forwards since we're trying to make the framework's clock handling more standard. signature.asc Description: PGP signature
Re: [PATCH v3] mfd: cros_ec: instantiate properly CrOS ISH MCU device
On Fri, 01 Mar 2019, Rushikesh S Kadam wrote: > Integrated Sensor Hub (ISH) is also a MCU running EC > having feature bit EC_FEATURE_ISH. Instantiate it as > a special CrOS EC device with device name 'cros_ish'. > > Signed-off-by: Rushikesh S Kadam > --- > v3 > - Dropped "Intel" in commments in cros_ec header file. CrOS EC ISH > device is a generic ISH. This was missed earlier. > v2 > - Addressed review comments to term the CrOS EC device as a generic > Integrated Sensor Hub. > v1 > - Initial version. > > drivers/mfd/cros_ec_dev.c| 13 + > include/linux/mfd/cros_ec.h | 1 + > include/linux/mfd/cros_ec_commands.h | 2 ++ > 3 files changed, 16 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1] mfd: Add support for Merrifield Basin Cove PMIC
On Mon, 18 Mar 2019, Andy Shevchenko wrote:
> Add an mfd driver for Intel Merrifield Basin Cove PMIC.
Nit: s/mfd/MFD/
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mfd/Kconfig | 11 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/intel_soc_pmic_mrfld.c | 157 +++
> include/linux/mfd/intel_soc_pmic_mrfld.h | 81
> 4 files changed, 250 insertions(+)
> create mode 100644 drivers/mfd/intel_soc_pmic_mrfld.c
> create mode 100644 include/linux/mfd/intel_soc_pmic_mrfld.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 0ce2d8dfc5f1..2adf9d393029 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -572,6 +572,17 @@ config INTEL_SOC_PMIC_CHTDC_TI
> Select this option for supporting Dollar Cove (TI version) PMIC
> device that is found on some Intel Cherry Trail systems.
>
> +config INTEL_SOC_PMIC_MRFLD
> + tristate "Support for Intel Merrifield Basin Cove PMIC"
> + depends on GPIOLIB
> + depends on ACPI
> + depends on INTEL_SCU_IPC
> + select MFD_CORE
> + select REGMAP_IRQ
> + help
> + Select this option for supporting Basin Cove PMIC device
> + that is found on Intel Merrifield systems.
> +
> config MFD_INTEL_LPSS
> tristate
> select COMMON_CLK
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b4569ed7f3f3..1b746bd01ac5 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -234,6 +234,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)+= intel_soc_pmic_chtdc_ti.o
> +obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> diff --git a/drivers/mfd/intel_soc_pmic_mrfld.c
> b/drivers/mfd/intel_soc_pmic_mrfld.c
> new file mode 100644
> index ..bbee89c0c25b
> --- /dev/null
> +++ b/drivers/mfd/intel_soc_pmic_mrfld.c
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device access for Basin Cove PMIC
> + *
> + * Copyright (c) 2018, Intel Corporation.
> + * Author: Andy Shevchenko
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
> + * Level 2 IRQs
> + *
> + * Firmware on the systems with Basin Cove PMIC services Level 1 IRQs
> + * without an assistance. Thus, each of the Level 1 IRQ is represented
> + * as a separate RTE in IOAPIC.
> + */
> +static struct resource irq_level2_resources[] = {
> + DEFINE_RES_IRQ(0), /* power button */
> + DEFINE_RES_IRQ(0), /* TMU */
> + DEFINE_RES_IRQ(0), /* thermal */
> + DEFINE_RES_IRQ(0), /* BCU */
> + DEFINE_RES_IRQ(0), /* ADC */
> + DEFINE_RES_IRQ(0), /* charger */
> + DEFINE_RES_IRQ(0), /* GPIO */
> +};
> +
> +static const struct mfd_cell bcove_dev[] = {
> + {
> + .name = "mrfld_bcove_pwrbtn",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[0],
> + }, {
> + .name = "mrfld_bcove_tmu",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[1],
> + }, {
> + .name = "mrfld_bcove_thermal",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[2],
> + }, {
> + .name = "mrfld_bcove_bcu",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[3],
> + }, {
> + .name = "mrfld_bcove_adc",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[4],
> + }, {
> + .name = "mrfld_bcove_charger",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[5],
> + }, {
> + .name = "mrfld_bcove_extcon",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[5],
> + }, {
> + .name = "mrfld_bcove_gpio",
> + .num_resources = 1,
> + .resources = &irq_level2_resources[6],
> + },
> + { .name = "mrfld_bcove_region", },
> +};
> +
> +static int regmap_ipc_byte_reg_read(void *context, unsigned int reg,
Prefixing these with regmap is pretty confusing, since this it not
part of the Regmap API. Better to provide them with local names
instead.
bcove_ipc_byte_reg_read()
> + unsigned int *val)
> +{
> + u8 ipc_out;
> + int ret;
> +
> + ret = intel_scu_ipc_ioread8(reg, &ipc_out);
> + if (ret)
> + return ret;
> +
> + *val = ipc_out;
> + return 0;
> +}
> +
> +static int regmap_ipc_byte_reg_write(void *context, unsigned int reg,
> + unsigned int val)
> +{
Re: [PATCH 2/2] ASoC: rt5677: make ACPI property names match _DSD
On Mon, Apr 01, 2019 at 02:55:19PM -0600, Fletcher Woodruff wrote: > The rt5677 driver is using the wrong property names to read from ACPI. > Update the property names to match those from _DSD, so that the correct > GPIO pin numbers are read and that plug-detection works. > With this patch, plugging and unplugging the headphone jack switches > between headphones and speakers automatically. What makes you say that these properties are wrong? Are you sure that this isn't just some other systems using different ACPI properties given the poor standardization for ACPI? Your new ones look like they're DT properties pulled into ACPI while the existing ones look more idiomatic for ACPI. It'd be fine to add your new DT style properties but this might break existing systems. signature.asc Description: PGP signature
Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
Hi Linus, > Am 02.04.2019 um 06:02 schrieb Linus Walleij : > > (CC Kumar and Wolfgang who came up with spi-active-low, I think.) > > On Sun, Mar 24, 2019 at 1:56 PM H. Nikolaus Schaller > wrote: >>> Am 24.03.2019 um 05:15 schrieb Linus Walleij : > >>> But I fixed it in that case by introducing a spi-cs-high into the DTS file: >>> https://marc.info/?l=linux-arm-kernel&m=155292310015309&w=2 >> >> Yes, that of course works and is our temporary solution. >> >> And I see that you also have it on the controller node and not the slave >> node. > > Yes I git it wrong, the slave should have it and another bug of mine > made it look at the controller not (some days I should not write > code in paths that do not get executed). > >>> I'm sorry about that, however if you look at the DT binding document: >>> Documentation/devicetree/bindings/spi/spi-bus.txt >> >> Shouldn't it be a property of the slave node and not the controller node? > > Indeed. > >>> You will see that spi-cs-high is mandatory. So these DTS files are >>> incorrect. >> >> How do you read that it is mandatory from >> >> "All slave nodes can contain the following optional properties: >> - spi-cs-high - Empty property indicating device requires chip select >>active high." >> >> I read it as optional and indicative. Equal priority to cs-gpios. > > The basic problem is that spi-cs-high is defined negatively, > so by default a CS GPIO is active low. This clashes with the > default GPIO flag, as GPIO_ACTIVE_HIGH is zero, no flag, > and thus the default if nothing is specified, so if the GPIO flag is > zero it should be active high, but if "spi-active-high" is not on the > slave node it should be active low, so one of them have > to win, they can't both win. > > I'd say that spi-cs-high existed before we standardized the GPIO > flags in the DT bindings. So people were relying on it for years before > we came up with the ACTIVE_HIGH/LOW flags. > > commit f618ebfcbf9616a0fa9a78f5ecb69762f0fa3c59 > Author: Wolfgang Ocker > Date: Wed Oct 15 15:00:47 2008 +0200 > >of/spi: Support specifying chip select as active high via device tree > >The patch allows to specify that an SPI device needs an active high chip >select. > >Signed-off-by: Wolfgang Ocker >Signed-off-by: Kumar Gala > > While the GPIO binding turns up 5 years later: > > commit 71fab21fee07fd6d5f1a984db387cc5e4596f3fa > Author: Stephen Warren > Date: Tue Feb 12 17:22:36 2013 -0700 > >ARM: dt: add header to define GPIO flags > >Many GPIO device tree bindings use the same flags. Create a header to >define those. > >Signed-off-by: Stephen Warren >Acked-by: Rob Herring > > And then this guy think it is a good idea to standardize this for > all GPIO phandles two years later: > > commit 69d301fdd19635a39cb2b78e53fdd625b7a27924 > Author: Linus Walleij > Date: Thu Sep 24 15:05:45 2015 -0700 > >gpio: add DT bindings for existing consumer flags > >It is customary for GPIO controllers to support open drain/collector >and open source/emitter configurations. Add standard GPIO line flags >to account for this and augment the documentation to say that these >are the most generic bindings. > >Several people approached me to add new flags to the lines, and this >makes sense, but let's first bind up the most common cases before we >start to add exotic stuff. > >Thanks to H. Nikolaus Schaller for ideas on how to encode single-ended >wiring such as open drain/source and open collector/emitter. > >Cc: Tony Lindgren >Cc: Grygorii Strashko >Cc: H. Nikolaus Schaller Yes, I remember to help with the open drain/collector definition :) >Signed-off-by: Linus Walleij > >>> This does not work because there are devices that requires spi-cs-high to be >>> respected and the DTS second cell GPIO flag to be ignored. >> >> Then, those should be fixed... > > This can't be done because some old systems (mostly powerpc) > added between 2008-2013 do not know about GPIO flags and > have DTBs deployed in firmware that need to keep working. > They cannot be fixed. The question is if it is even possible to deploy a new kernel for such devices and if anyone wants to do... This also gives another idea: make it depend on "powerpc". > >>> They might have deployed DTB binaries that need to keep working, >> >> Well, that is a weak argument. What if the GTA04 would have the DTB in FLASH >> and would need it working (fortunately we always reflash kernel + dtbs)? > > Usually the definition I use for "deployed DTB" is not > "deployed on my desk" but "deployed by a factory" i.e. someone > producing millions of TV sets or something. For example my monitor > is using a PowerPC CPU and has one of these DTBs in flash, > and expect it to keep working if I upgrade the kernel separately. Ok, I see. We basically have the same (devices deployed to unknown users), but we can and do flash
Re: [PATCH 1/2] ASoC: rt5677: allow multiple interrupt sources
On Mon, Apr 01, 2019 at 02:55:18PM -0600, Fletcher Woodruff wrote:
> From: Ben Zhang
>
> This patch allows headphone plug detect and mic present
> detect to be enabled at the same time. This patch implements
> an irq_chip with irq_domain directly instead of using
> regmap_irq, so that interrupt source line polarities can
> be flipped to support irq sharing.
regmap-irq should support active high/low, and if it doesn't it can't be
a unique thing that only this device wants to implement so the common
code should be improved.
> + mutex_lock(&rt5677->irq_lock);
> + /*
> + * Loop to handle interrupts until the last i2c read shows no pending
> + * irqs. The interrupt line is shared by multiple interrupt sources.
> + * After the regmap_read() below, a new interrupt source line may
> + * become high before the regmap_write() finishes, so there isn't a
> + * rising edge on the shared interrupt line for the new interrupt. Thus,
> + * the loop is needed to avoid missing irqs.
> + *
> + * A safeguard of 20 loops is used to avoid hanging in the irq handler
> + * if there is something wrong with the interrupt status update. The
> + * interrupt sources here are audio jack plug/unplug events which
> + * shouldn't happen at a high frequency for a long period of time.
> + * Empirically, more than 3 loops have never been seen.
> + */
> + for (loop = 0; loop < 20; loop++) {
This looks unrelated to the polarity of the interupt?
signature.asc
Description: PGP signature
Re: MSI number limit for PCI hotplug under PCI bridge on ARM platform
On Mon, 01 Apr 2019 14:55:52 +0100, Heyi Guo wrote: > > Hi folks, > > In current kernel implementation for ARM platform, all devices under > one PCI bridge share a same device ID and the total number of MSI > interrupts is fixed at the first time any child device is allocating > MSI. However, this may cause failure of allocating MSI if the system > supports device hot-plug under the PCI bridge, which is possible for > ARM virtual machine with generic pcie-to-pci-bridge and kernel > config HOTPLUG_PCI_SHPC enabled. > > Does it make sense to add support for the above scenario? If it > does, any suggestion for how to do that? I don't think it makes much sense. You have the flexibility not to add such a broken setup to your guests, and instead have enough pcie ports so that you can always have an exact allocation and no DevID aliasing. The alternative is to dynamically grow the ITT for a given DevID, which cannot be done without unmapping it first. This in turn will result in interrupts being lost while the DevID was unmapped, and they'd need to be pessimistically reinjected. This also involves a substantial amount of data structure repainting, as you're pretty much guaranteed not to be able to reuse the same LPI range. Given that this is arbitrarily self-inflicted, I'm not overly keen on even trying to support this. Thanks, M. -- Jazz is not dead, it just smell funny.
Re: [RESEND PATCH] mfd: sc27xx: Use SoC compatible string for PMIC devices
On Mon, 18 Mar 2019, Baolin Wang wrote:
> We should use SoC compatible string in stead of wildcard string for
> PMIC child devices.
>
> Signed-off-by: Baolin Wang
> ---
> Hi Lee,
>
> Could you merge this patch into v5.1-rc if no objection from you?
> Since our DTS patches had been merged into v5.1, our PMIC can not
> work without this patch. Thanks.
Oh dear, what a pickle. Really you should have pushed these change
though one tree, in either a single patch or at the very least a
single patch-set. I will see what I can do, so that this doesn't
break for an entire kernel version (but I make no promises).
> ---
> drivers/mfd/sprd-sc27xx-spi.c | 42
> -
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
> index 69df277..43ac716 100644
> --- a/drivers/mfd/sprd-sc27xx-spi.c
> +++ b/drivers/mfd/sprd-sc27xx-spi.c
> @@ -53,67 +53,67 @@ struct sprd_pmic_data {
> static const struct mfd_cell sprd_pmic_devs[] = {
> {
> .name = "sc27xx-wdt",
> - .of_compatible = "sprd,sc27xx-wdt",
> + .of_compatible = "sprd,sc2731-wdt",
> }, {
> .name = "sc27xx-rtc",
> - .of_compatible = "sprd,sc27xx-rtc",
> + .of_compatible = "sprd,sc2731-rtc",
> }, {
> .name = "sc27xx-charger",
> - .of_compatible = "sprd,sc27xx-charger",
> + .of_compatible = "sprd,sc2731-charger",
> }, {
> .name = "sc27xx-chg-timer",
> - .of_compatible = "sprd,sc27xx-chg-timer",
> + .of_compatible = "sprd,sc2731-chg-timer",
> }, {
> .name = "sc27xx-fast-chg",
> - .of_compatible = "sprd,sc27xx-fast-chg",
> + .of_compatible = "sprd,sc2731-fast-chg",
> }, {
> .name = "sc27xx-chg-wdt",
> - .of_compatible = "sprd,sc27xx-chg-wdt",
> + .of_compatible = "sprd,sc2731-chg-wdt",
> }, {
> .name = "sc27xx-typec",
> - .of_compatible = "sprd,sc27xx-typec",
> + .of_compatible = "sprd,sc2731-typec",
> }, {
> .name = "sc27xx-flash",
> - .of_compatible = "sprd,sc27xx-flash",
> + .of_compatible = "sprd,sc2731-flash",
> }, {
> .name = "sc27xx-eic",
> - .of_compatible = "sprd,sc27xx-eic",
> + .of_compatible = "sprd,sc2731-eic",
> }, {
> .name = "sc27xx-efuse",
> - .of_compatible = "sprd,sc27xx-efuse",
> + .of_compatible = "sprd,sc2731-efuse",
> }, {
> .name = "sc27xx-thermal",
> - .of_compatible = "sprd,sc27xx-thermal",
> + .of_compatible = "sprd,sc2731-thermal",
> }, {
> .name = "sc27xx-adc",
> - .of_compatible = "sprd,sc27xx-adc",
> + .of_compatible = "sprd,sc2731-adc",
> }, {
> .name = "sc27xx-audio-codec",
> - .of_compatible = "sprd,sc27xx-audio-codec",
> + .of_compatible = "sprd,sc2731-audio-codec",
> }, {
> .name = "sc27xx-regulator",
> - .of_compatible = "sprd,sc27xx-regulator",
> + .of_compatible = "sprd,sc2731-regulator",
> }, {
> .name = "sc27xx-vibrator",
> - .of_compatible = "sprd,sc27xx-vibrator",
> + .of_compatible = "sprd,sc2731-vibrator",
> }, {
> .name = "sc27xx-keypad-led",
> - .of_compatible = "sprd,sc27xx-keypad-led",
> + .of_compatible = "sprd,sc2731-keypad-led",
> }, {
> .name = "sc27xx-bltc",
> - .of_compatible = "sprd,sc27xx-bltc",
> + .of_compatible = "sprd,sc2731-bltc",
> }, {
> .name = "sc27xx-fgu",
> - .of_compatible = "sprd,sc27xx-fgu",
> + .of_compatible = "sprd,sc2731-fgu",
> }, {
> .name = "sc27xx-7sreset",
> - .of_compatible = "sprd,sc27xx-7sreset",
> + .of_compatible = "sprd,sc2731-7sreset",
> }, {
> .name = "sc27xx-poweroff",
> - .of_compatible = "sprd,sc27xx-poweroff",
> + .of_compatible = "sprd,sc2731-poweroff",
> }, {
> .name = "sc27xx-syscon",
> - .of_compatible = "sprd,sc27xx-syscon",
> + .of_compatible = "sprd,sc2731-syscon",
> },
> };
>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok
On 2019/4/2 上午11:14, Rong Chen wrote:
>
> On 4/1/19 11:40 PM, David Sterba wrote:
>> On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
>>> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
On 2019/4/1 下午10:02, Chen, Rong A wrote:
> On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
>> On 1.04.19 г. 16:24 ч., kernel test robot wrote:
>>> FYI, we noticed the following commit (built with gcc-7):
>>>
>>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
>>> tree-checker: Verify dev item")
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
>>> master
>>>
>>> in testcase: trinity
>>> with following parameters:
>>>
>>> runtime: 300s
>>>
>>> test-description: Trinity is a linux system call fuzz tester.
>>> test-url: http://codemonkey.org.uk/projects/trinity/
>>>
>>>
>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge
>>> -smp
>>> 2 -m 2G
>>>
>>> caused below changes (please refer to attached dmesg/kmsg for entire
>>> log/backtrace):
>>>
>>>
>>> ++++
>>>
>>>
>>> |
>>> | 36b9d2bc69 | 70d28b0e4f |
>>> ++++
>>>
>>>
>>> |
>>> boot_successes
>>> | 14 | 0 |
>>> |
>>> boot_failures
>>> | 2 | 14 |
>>> |
>>> IP-Config:Auto-configuration_of_network_failed
>>> | 2 | |
>>> |
>>> BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
>>>
>>> | 0 | 14 |
>>> ++++
>>>
>>>
>>>
>>>
>>>
>>> early console in setup code
>>> Probing EDD (edd=off to disable)... ok
>>> BUG: kernel reboot-without-warning in early-boot stage, last printk:
>>> Probing EDD (edd=off to disable)... ok
>>> Linux version 5.0.0-rc8-00196-g70d28b0 #1
>>> Command line: ip=vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
>>> user=lkp
>>> job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
>>>
>>> ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
>>> branch=linux-devel/devel-hourly-2019032317
>>> commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
>>> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
>>>
>>> max_uptime=1500
>>> RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
>>>
>>> LKP_SERVER=inn debug apic=debug sysrq_always_enabled
>>> rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
>>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
>>> load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
>>> systemd.log_level=err ignore_loglevel console=tty0
>>> earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
>>> rcuperf.shutdown=0
>>>
>> Can this report be made useful by actually including output from
>> serial
>> console? For example possible bug-ons or whatnot? dmesg.xz just
>> contains
>> qemu's command line + some metadata about the test and :
>>
>> "BUG: kernel reboot-without-warning in early-boot stage, last printk:
>> Probing EDD (edd=off to disable)... ok"
>>
>> At least a stack trace would have been useful.
>>
>>
> Hi,
>
> We usually use the tool ("bin/lkp qemu -k job-script") to
> reproduce it. It seems no stack trace in the result:
So there is no regression at that commit right?
Just some false alert?
>>>
>>> Hi,
>>>
>>> I think there's a regression, it stopped in the early-boot stage .
>> Can you please provide any logs that would point at btrfs? If the module
>> is loaded or built-in started, there's a line about that. Besides that
>> it's preceded by messages from other subsystems' initialization.
>
>
> Hi,
>
> CONFIG_BTRFS_FS and CONFIG_BTRFS_FS_REF_VERIFY is enabled in the kconfig.
> I disabled them for the experiment, and the new kernel is bootable. I
> don't have more logs to prove it.
>
> $ grep BTRFS config-5.0.0-rc8-00196-g70d28b0
> CONFIG_BTRFS_FS=y
> # CONFIG_BTRFS_FS_POSIX_ACL is not set
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
> # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
> # CONFIG_BTRFS_DEBUG is not set
> # CONFIG_BTRFS_ASSERT is not set
> CONFIG_BTRFS_FS_REF_VERIFY=y
With the same BTR
Re: Applied "ASoC: es8316: Add support for inverted jack detect" to the asoc tree
On Mon, Apr 01, 2019 at 07:57:19PM +0200, Paul Cercueil wrote: Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed. > What about the other two patches? Should I make a new patchset with these? They're Intel board patches so the Intel people will hopefully review. signature.asc Description: PGP signature
Re: [PATCH 01/17] fpga: dfl-fme-mgr: fix FME_PR_INTFC_ID register address.
On Mon, Apr 01, 2019 at 12:54:47PM -0700, Moritz Fischer wrote: > Hi Wu, > > On Mon, Mar 25, 2019 at 11:07:28AM +0800, Wu Hao wrote: > > FME_PR_INTFC_ID is used as compat_id for fpga manager and region, > > but high 64 bits and low 64 bits of the compat_id are swapped by > > mistake. This patch fixes this problem by fixing register address. > > > > Signed-off-by: Wu Hao > > --- > > drivers/fpga/dfl-fme-mgr.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c > > index 76f3770..b3f7eee 100644 > > --- a/drivers/fpga/dfl-fme-mgr.c > > +++ b/drivers/fpga/dfl-fme-mgr.c > > @@ -30,8 +30,8 @@ > > #define FME_PR_STS 0x10 > > #define FME_PR_DATA0x18 > > #define FME_PR_ERR 0x20 > > -#define FME_PR_INTFC_ID_H 0xA8 > > -#define FME_PR_INTFC_ID_L 0xB0 > > +#define FME_PR_INTFC_ID_L 0xA8 > > +#define FME_PR_INTFC_ID_H 0xB0 > > Does this handle endianess correct? Hi Moritz, This is just a bug fixing for wrong offsets given to these 2 registers according to spec. I think this is not endianess related, and per my understanding we don't need more code on endianess handling as that should be done inside the readq function already. :) Thanks Hao
Re: [PATCH V1 24/26] spi: tegra114: de-assert CS before SPI mode is reset to its default
On Mon, Apr 01, 2019 at 06:07:45PM +, Sowjanya Komatineni wrote: > I see you have applied some patches in V1 series so should I re-send > again those as well along with feedback changes in next version or > just only the patches that are not applied. Please don't resend already applied patches. signature.asc Description: PGP signature
Re: [PATCH V1 19/26] DT bindings: spi: add spi client device properties
On Mon, Apr 01, 2019 at 05:59:57PM +, Sowjanya Komatineni wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > > > +spi-client device controller properties: > > > +- nvidia,cs-setup-clk-count: CS setup timing parameter. > > > +- nvidia,cs-hold-clk-count: CS hold timing parameter. > > > +- nvidia,cs-inactive-cycles: CS inactive delay in terms of clock > > > +between > > > + transfers. > > Why are these being done as nVidia specific properties rather than > > generic ones and why are these being configured in DT rather than by > > the client driver? If the devices have particular timing > > requirements for chip select presumably that's going to apply no > > matter what controller or system they're used with so it seems best > > to configure this in the client driver and have an API that any > > controller can implement. > These are implemented thru DT as Tegra SPI is master and master controls the > timing. > Some SPI slaves have specific requirements of certain CS setup/hold time and > inactive cycles which SPI master should meet when driving during transfer and > Tegra SPI controller supports tuning these parameters. This doesn't address the issue at all, obviously the timings for the SPI bus are going to be impelemented by the controller but that's not the issue. signature.asc Description: PGP signature
Re: [PATCH v2 3/4] Makefile: lld: tell clang to use lld
Hi Nick, On Tue, Apr 2, 2019 at 12:54 PM Nick Desaulniers wrote: > > On Sat, Feb 16, 2019 at 10:09 AM Masahiro Yamada > wrote: > > > > On Thu, Feb 14, 2019 at 8:08 AM Nick Desaulniers > > wrote: > > > > > > On Wed, Feb 13, 2019 at 6:59 AM Masahiro Yamada > > > wrote: > > > > > > > > On Tue, Feb 12, 2019 at 5:42 AM wrote: > > > > > > > > > > This is needed because clang doesn't select which linker to use based > > > > > on > > > > > $LD but rather -fuse-ld=lld. This is problematic especially for > > > > > cc-ldoption, which checks for linker flag support via invoking the > > > > > compiler, rather than the linker. > > > > > > > > > > > > Sorry, please explain what kind of problem > > > > this patch solves. > > > > > > > > > > > > > > > > [1] $(LD) is used to link vmlinux, modules, etc. > > > > > > > > [2] $(CC) is used to link vdso, etc. > > > > and -fuse-ld= selects which linker is invoked from $(CC) > > > > > > It solves case 2. > > > > > > > > > > > > > > > Is it a problem to use a different > > > > type of linker for [1] and [2] ? > > > > > > Ideally, no, but I can think of at least one case where it might be > > > problematic to mix linkers like that: > > > You might be mixing linker flags added via ld-option from one linker > > > that aren't actually supported by the other linker. > > > > You can do this only when you are sure > > that the _exactly_ same linker is used. > > > > In my understanding, -fuse-ld=lld does not guarantee it. > > I really don't think we should be mixing and matching linkers during a > kernel build. When we compile with clang, we don't have escape > hatches that allow for some object files to be compiled with GCC > (mixing clang and GCC compiled object files into one build). > Following the same logic, I think mixing linkers during kernel build > should similarly be dissuaded. This patch AVOIDS clang using a > different linker than what was specified via $LD, which is CRITICAL > for cc-ldoption kbuild macro. Masahiro, I hope this patch can be > re-evaluated, or if I'm not understanding your point, that you can > provide additional clarification. > You can pass an absolute pass to LD, like make LD=/path/to/my/llvm/install/dir/bin/ld.lld This clarifies which linker is being used even when multiple versions of llvm are installed on the machine. However, -fuse-ld=lld is ambiguous. Will it use the first ld.lld found in PATH? So, you cannot avoid mixing linkers by this means. If we could do -fuse=$(LD), I would agree with it. Clang accepts -fuse=, GCC does not. Is there a way to control the linker search path? -- Best Regards Masahiro Yamada
Re: [PATCH v3] gcov: fix when CONFIG_MODULES is not set
On 4/1/19 8:09 PM, tr...@android.com wrote:
> From: Tri Vo
>
> Fixes: 8c3d220cb6b5 ("gcov: clang support")
>
> Cc: Greg Hackmann
> Cc: Peter Oberparleiter
> Cc: linux...@kvack.org
> Cc: kbuild-...@01.org
> Reported-by: Randy Dunlap
> Reported-by: kbuild test robot
> Link: https://marc.info/?l=linux-mm&m=155384681109231&w=2
> Signed-off-by: Nick Desaulniers
> Signed-off-by: Tri Vo
Acked-by: Randy Dunlap # build-tested
Thanks.
> ---
> kernel/gcov/clang.c | 4
> kernel/gcov/gcc_3_4.c | 4
> kernel/gcov/gcc_4_7.c | 4
> 3 files changed, 12 insertions(+)
>
> diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
> index 125c50397ba2..cfb9ce5e0fed 100644
> --- a/kernel/gcov/clang.c
> +++ b/kernel/gcov/clang.c
> @@ -223,7 +223,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
> gcov_info *info)
> */
> bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
> {
> +#ifdef CONFIG_MODULES
> return within_module((unsigned long)info->filename, mod);
> +#else
> + return false;
> +#endif
> }
>
> /* Symbolic links to be created for each profiling data file. */
> diff --git a/kernel/gcov/gcc_3_4.c b/kernel/gcov/gcc_3_4.c
> index 801ee4b0b969..8fc30f178351 100644
> --- a/kernel/gcov/gcc_3_4.c
> +++ b/kernel/gcov/gcc_3_4.c
> @@ -146,7 +146,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
> gcov_info *info)
> */
> bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
> {
> +#ifdef CONFIG_MODULES
> return within_module((unsigned long)info, mod);
> +#else
> + return false;
> +#endif
> }
>
> /* Symbolic links to be created for each profiling data file. */
> diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
> index ec37563674d6..0b6886d4a4dd 100644
> --- a/kernel/gcov/gcc_4_7.c
> +++ b/kernel/gcov/gcc_4_7.c
> @@ -159,7 +159,11 @@ void gcov_info_unlink(struct gcov_info *prev, struct
> gcov_info *info)
> */
> bool gcov_info_within_module(struct gcov_info *info, struct module *mod)
> {
> +#ifdef CONFIG_MODULES
> return within_module((unsigned long)info, mod);
> +#else
> + return false;
> +#endif
> }
>
> /* Symbolic links to be created for each profiling data file. */
>
--
~Randy
Re: Nested events with zero deltas, can use absolute timestamps instead?
On Mon, Apr 1, 2019 at 7:21 PM Steven Rostedt wrote: > > On Mon, 1 Apr 2019 15:54:20 -0700 > Jason Behmer wrote: > > > The concurrency model is still a little bit unclear to me as I'm new > > to this codebase. So I'm having some trouble reasoning about what > > operations are safe at one point on the ring buffer.It seems like > > we can't be preempted in general, just interrupts? And the events for > > the events emitted by interrupts will be fully processed before > > getting back to the event pointed at by the commit pointer? If this > > is true I think the approach below (and prototyped in the attached > > patch against head) might work and would love feedback. If not, this > > problem is way harder. > > > > We detect nested events by checking our event pointer against the > > commit pointer. This is safe because we reserve our event space > > atomically in the buffer, leading to an ordering of events we can > > depend on. But to add a TIME_STAMP event we need to reserve more > > space before we even have an event pointer, so we need to know > > something about the ordering of events before we've actually > > atomically reserved ours. We could check if the write pointer is set > > to the commit pointer, and if it isn't we know we're a nested event. > > But, someone could update the write pointer and/or commit pointer > > between the time we check it and the time we atomically reserve our > > space in the buffer. However, I think maybe this is ok. > > > > If we see that the write pointer is not equal to the commit pointer, > > then we're in an interrupt, and the only thing that could update the > > commit pointer is the original event emitting code that was > > interrupted, which can't run again until we're finished. And the only > > thing that can update the write pointer is further interrupts of us, > > which will advance the write pointer further away from commit, leaving > > our decision to allocate a TIME_STAMP event as valid. > > > > If we see that the write pointer is equal to the commit pointer, then > > anything that interrupts us before we move the write pointer will see > > that same state and will need to, before returning to us, commit their > > event and set commit to their new write pointer, which will make our > > decision valid once again. > > > > There's a lot of assumptions in there that I'd love to be checked on > > as I'm new to this code base. For example I haven't read the read > > path at all and have no idea if it interacts with this at all. > > I think you pretty much got the idea correct. The issue is what to put > into the extra timestamp value. As the time we record the timestamp > compared to the time we allocate the space for the timestamp is not > atomic. And we can't have time go backwards :-( > > | | > commit --->+--+ > | TS offset from previous event| (A) > +--+ > | outer event data | > +--+ > | extended TS | (B) > +--+ > | interrupt event data | > +--+ > head --->| | > > > TS = rdstc(); > A = reserve_ring_buffer > *A = TS > > interrupt: > TS = rdtsc(); > B = reserve_ring_buffer > *B = TS > > > What's important is what we store in A and B > > TS = rdtsc(); > ---> > TS = rdstc() > (this is first commit!) > A = reserver_ring_buffer > *A = TS > (finish commit) > < > A = reserver_ring_buffer > *A = TS > > You can see how the recording of the timestamp and writing it gets > complex. Also it gets more complex when we use deltas and not direct writes. > > Now we may be able to handle this if we take the timestamp before doing > anything, and if it's nested, take it again (which should guarantee > that it's after the previous timestamp) > > Now of course the question is, how do we update the write stamp that we > will use to compute new "deltas"? Or we just use absolute timestamps to > the end of the page, and start over again, when we start a new page > that isn't nested. > > But see where the complexity comes from? > > -- Steve Ah, yes, I was too focused on the first problem of if we could even reserve the space due to concurrency restrictions. First, I had assumed there weren't restrictions on timestamps needing to not go backwards between consecutive events in the buffers, as it seems the current implementation of absolute timestamps s
Re: [PATCH v2 0/2] arm64: meson-gxm: Add support for the Mali T820 GPU
Neil Armstrong writes: > On 15/03/2019 14:56, Neil Armstrong wrote: >> This patchset adds : >> - Optional reset properties in the midgard bindings >> - Mali T820 Node in Amlogic Meson GXM DTSI >> >> Changes since v1: >> - Updated midgard DT wording following the recently submitted >> bifrost bindings >> >> Christian Hewitt (1): >> arm64: dts: meson-gxm: Add Mali-T820 node >> >> Neil Armstrong (1): >> dt-bindings: gpu: mali-midgard: Add resets property >> >> .../bindings/gpu/arm,mali-midgard.txt | 14 ++ >> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi| 27 +++ >> 2 files changed, 41 insertions(+) >> > > Kevin, can you take both in your tree now the bindings are reviewed ? Yes. Queud for v5.2 (branch: v5.2/dt64) Thanks, Kevin
Re: [PATCH 2/6] kbuild: allow Kbuild to start from any directory
Hi Yamada-san,
Thank you for the patches,
I like the direction this series is taking.
Small spelling error spotted below...
But as I've now gone through all of it I'll offer
Reviewed-by: Kieran Bingham
On 30/03/2019 12:04, Masahiro Yamada wrote:
> Kbuild always runs in the top of the output directory.
>
> If Make starts in the source directory with O=, it relocates the
> working directory to the location specified by O=.
>
> Also, users can start build from the output directory by using the
> Makefile generated by scripts/mkmakefile.
>
> With a little more effort, Kbuild will be able to start from any
> directory path.
>
> This commit allows to specify the source directory by using
> the -f option.
>
> For example, you can do:
>
> $ cd path/to/output/dir
> $ make -f path/to/source/dir/Makefile
>
> Or, for the equivalent behavior, you can do:
>
> $ make O=path/to/output/dir -f path/to/source/dir/Makefile
>
> KBUILD_SRC is now deprecated.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Makefile | 87
> +---
> 1 file changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 9cbd367..1b2a70e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -96,56 +96,65 @@ endif
>
> export quiet Q KBUILD_VERBOSE
>
> -# kbuild supports saving output files in a separate directory.
> -# To locate output files in a separate directory two syntaxes are supported.
> -# In both cases the working directory must be the root of the kernel src.
> +# Kbuild will save output files in the current working directory.
> +# This does not need to match to the root of the kernel source tree.
> +#
> +# For example, you can do this:
> +#
> +# cd /dir/to/store/output/files; make -f /dir/to/kernel/source/Makefile
> +#
> +# If you want to save output files in a different location, there are
> +# two syntaxes to specify it.
> +#
> # 1) O=
> # Use "make O=dir/to/store/output/files/"
> #
> # 2) Set KBUILD_OUTPUT
> -# Set the environment variable KBUILD_OUTPUT to point to the directory
> -# where the output files shall be placed.
> -# export KBUILD_OUTPUT=dir/to/store/output/files/
> -# make
> +# Set the environment variable KBUILD_OUTPUT to point to the output
> directory.
> +# export KBUILD_OUTPUT=dir/to/store/output/files/; make
> #
> # The O= assignment takes precedence over the KBUILD_OUTPUT environment
> # variable.
>
> -# KBUILD_SRC is not intended to be used by the regular user (for now),
> -# it is set on invocation of make with KBUILD_OUTPUT or O= specified.
> -
> -# OK, Make called in directory where kernel src resides
> -# Do we want to locate output files in a separate directory?
> +# Do we want to change the working directory?
> ifeq ("$(origin O)", "command line")
>KBUILD_OUTPUT := $(O)
> endif
>
> -ifneq ($(words $(subst :, ,$(CURDIR))), 1)
> - $(error main directory cannot contain spaces nor colons)
> +ifneq ($(KBUILD_OUTPUT),)
> +# Make's built-in functions such as $(abspath ...), $(realpath ...) cannot
> +# expand a shell special character '~'. We use a bit tredious way to handle
> it.
very minor, but I noticed while looking through the series ^^
s/bit tredious/somewhat tedious/
> +abs_objtree := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) &&
> pwd)
> +$(if $(abs_objtree),, \
> + $(error failed to create output directory "$(KBUILD_OUTPUT)"))
> +
> +# $(realpath ...) resolves symlinks
> +abs_objtree := $(realpath $(abs_objtree))
> +else
> +abs_objtree := $(CURDIR)
> +endif # ifneq ($(KBUILD_OUTPUT),)
> +
> +ifeq ($(abs_objtree),$(CURDIR))
> +# Suppress "Entering directory ..." unless we are changing the work
> directory.
> +MAKEFLAGS += --no-print-directory
> +else
> +need-sub-make := 1
> endif
>
> -ifneq ($(KBUILD_OUTPUT),)
> -# check that the output directory actually exists
> -saved-output := $(KBUILD_OUTPUT)
> -KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \
> - && pwd)
> -$(if $(KBUILD_OUTPUT),, \
> - $(error failed to create output directory "$(saved-output)"))
> +abs_srctree := $(realpath $(dir $(lastword $(MAKEFILE_LIST
> +
> +ifneq ($(words $(subst :, ,$(abs_srctree))), 1)
> +$(error source directory cannot contain spaces or colons)
> +endif
>
> +ifneq ($(abs_srctree),$(abs_objtree))
> # Look for make include files relative to root of kernel src
> #
> # This does not become effective immediately because MAKEFLAGS is re-parsed
> -# once after the Makefile is read. It is OK since we are going to invoke
> -# 'sub-make' below.
> -MAKEFLAGS += --include-dir=$(CURDIR)
> -
> +# once after the Makefile is read. We need to invoke sub-make.
> +MAKEFLAGS += --include-dir=$(abs_srctree)
> need-sub-make := 1
> -else
> -
> -# Do not print "Entering directory ..." at all for in-tree build.
> -MAKEFLAGS += --no-print-directory
> -
> -endif # ifneq ($(KBUILD_OUTPUT),)
> +endif
>
>
Re: [PATCH 1/1] slob: Only use list functions when safe to do so
On Tue, 2 Apr 2019 14:29:57 +1100 "Tobin C. Harding" wrote:
> Currently we call (indirectly) list_del() then we manually try to combat
> the fact that the list may be in an undefined state by getting 'prev'
> and 'next' pointers in a somewhat contrived manner. It is hard to
> verify that this works for all initial states of the list. Clearly the
> author (me) got it wrong the first time because the 0day kernel testing
> robot managed to crash the kernel thanks to this code.
>
> All this is done in order to do an optimisation aimed at preventing
> fragmentation at the start of a slab. We can just skip this
> optimisation any time the list is put into an undefined state since this
> only occurs when an allocation completely fills the slab and in this
> case the optimisation is unnecessary since we have not fragmented the slab
> by this allocation.
>
> Change the page pointer passed to slob_alloc_page() to be a double
> pointer so that we can set it to NULL to indicate that the page was
> removed from the list. Skip the optimisation if the page was removed.
>
> Found thanks to the kernel test robot, email subject:
>
> 340d3d6178 ("mm/slob.c: respect list_head abstraction layer"): kernel
> BUG at lib/list_debug.c:31!
>
It's regrettable that this fixes
slob-respect-list_head-abstraction-layer.patch but doesn't apply to
that patch - slob-use-slab_list-instead-of-lru.patch gets in the way.
So we end up with a patch series which introduces a bug and later
fixes it.
I guess we can live with that but if the need comes to respin this
series, please do simply fix
slob-respect-list_head-abstraction-layer.patch so we get a clean
series.
Re: [PATCH] drivers: gpio: Kconfig: pedantic formatting cleanups
On Tue, Mar 5, 2019 at 7:35 AM Enrico Weigelt, metux IT consult wrote: > Align the Kconfig formatting with the vast majority of the Kconfig > files, to make it a bit easier / more pleasant to read ;-) > > Signed-off-by: Enrico Weigelt, metux IT consult Patch applied. Yours, Linus Walleij
Re: [PATCH] ASoC: soc-core: Fix probe deferral following prelink failure
On Mon, Apr 01, 2019 at 01:22:09PM +0100, Jon Hunter wrote: > FYI, I am seeing that the deferral of soundcards failing with v5.1-rc3 > because the above has not been merged yet. Just wanted to let you know > in case this one was not marked for v5.1. I don't have this patch at all AFAICT. signature.asc Description: PGP signature
Re: [PATCH] vfio/type1: Limit DMA mappings per container
On Tue, 2 Apr 2019 10:41:15 +0800
Peter Xu wrote:
> On Mon, Apr 01, 2019 at 02:16:52PM -0600, Alex Williamson wrote:
>
> [...]
>
> > @@ -1081,8 +1088,14 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
> > goto out_unlock;
> > }
> >
> > + if (!atomic_add_unless(&iommu->dma_avail, -1, 0)) {
> > + ret = -ENOSPC;
> > + goto out_unlock;
> > + }
> > +
> > dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> > if (!dma) {
> > + atomic_inc(&iommu->dma_avail);
>
> This should be the only special path to revert the change. Not sure
> whether this can be avoided by simply using atomic_read() or even
> READ_ONCE() (I feel like we don't need atomic ops with dma_avail
> because we've had the mutex but it of course it doesn't hurt...) to
> replace atomic_add_unless() above to check against zero then we do
> +1/-1 in vfio_[un]link_dma() only. But AFAICT this patch is correct.
Thanks for the review, you're right, we're only twiddling this atomic
while holding the iommu->lock mutex, so it appears unnecessary. Since
we're within the mutex, I think we don't even need a READ_ONCE. We can
simple test it before alloc and decrement after. Am I missing something
that would specifically require READ_ONCE within our mutex critical
section? Thanks,
Alex
Re: [PATCH v2] spi: tegra20-slink: change chip select action order
On Fri, Mar 29, 2019 at 06:44:11PM +0100, Randolph Maaßen wrote: > To transfer via SPI the tegra20-slink driver first sets the command > register, which contains the chip select value, and after that the > command2 register, which contains the chip select line. This leads to a > small spike in the chip selct 0 line between the set of the value and > the selection of the chip select line. Please do not submit new versions of already applied patches, please submit incremental updates to the existing code. Modifying existing commits creates problems for other users building on top of those commits so it's best practice to only change pubished git commits if absolutely essential. signature.asc Description: PGP signature
Re: [PATCH v3] HID: intel-ish-hid: ISH firmware loader client driver
Hi Nick, Joe
thanks for your comments
Regards
Rushikesh
On Mon, Apr 01, 2019 at 03:17:13PM -0600, Nick Crews wrote:
> I tried to send the last message from my phone, and surprise it wasn't
> formatted correctly, so it may have been marked as spam. repeating
> myself again...
>
> Ah, I guess I was wrong about logging OOM. I hadn’t hear about the
> recommendations against it, but they make sense. Thanks for the
> clarifications!
>
> On Sat, Mar 30, 2019 at 10:27 AM Joe Perches wrote:
> >
> > On Sat, 2019-03-30 at 15:52 +0530, Rushikesh S Kadam wrote:
> > > On Fri, Mar 29, 2019 at 04:30:18PM -0700, Nick Crews wrote:
> > > > On Fri, Mar 29, 2019 at 1:03 PM Rushikesh S Kadam
> > > > wrote:
> > > > > + ldr_xfer_ipc_frag = kzalloc(LOADER_SHIM_IPC_BUF_SIZE,
> > > > > GFP_KERNEL);
> > > > > + if (!ldr_xfer_ipc_frag) {
> > > > Log error here.
> > > The error code is logged in calling function
> > > load_fw_from_host(). Is that good enough?
> > >
> > > I believe the checkpatch script too, would
> > > recommend against adding debug print for ENOMEM
> > > error.
> >
> > The generic kernel allocation functions already do
> > a dump_stack() on OOM conditions when called without
> > __GFP_NOWARN so any additional OOM message isn't
> > particularly useful.
> >
> > > Again, I thought it was against practise to log
> > > "out of memory" debug prints in probe()
> >
> > Or anywhere else given the generic OOM stack dump.
> >
> > > But will add if you tell me this is the right way.
> > >
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + loader_ishtp_cl = ishtp_cl_allocate(cl_device);
> > > > > + if (!loader_ishtp_cl)
> > > >
> > > > log error here
> >
> > The ishtp_cl_allocate function just calls kmalloc then
> > initializes the struct so an additional OOM message
> > isn't useful here either.
> >
> >
--
Re: [Letux-kernel] [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
On Sun, Mar 31, 2019 at 1:33 AM Andreas Kemnade wrote: > > > But I fixed it in that case by introducing a spi-cs-high into the DTS > > > file: > > > https://marc.info/?l=linux-arm-kernel&m=155292310015309&w=2 > > > > Yes, that of course works and is our temporary solution. > > > > And I see that you also have it on the controller node and not the slave > > node. > > > So if I get it right is a check added for undocumented properties > (nothing about spi-cs-high in controller node in the bindings > documentation, only in the slave node) in the two patches mentioned. > > And then you add that undocumented property to a dts file in your "fix". > > That all sounds strange to me. Yeah it sounds strange because it is strange :) I was simply confused and wrong. Sometimes we all do very uniformed things, today it was me. The flag should of course be on the slave node. So now I have to fix my fix. Yours, Linus Walleij
Re: [PATCH] ELAN touchpad i2c_hid bugs fix
On Apr 2, 2019, at 5:37 AM,
wrote:
-Original Message-
From: Andy Shevchenko
Sent: Thursday, March 21, 2019 4:48 AM
To: Kai-Heng Feng; Limonciello, Mario
Cc: Hans de Goede; Benjamin Tissoires; hotwater...@tutanota.com; Jiri
Kosina;
Stephen Boyd; Sebastian Andrzej Siewior; Dmitry Torokhov; open list:HID
CORE
LAYER; lkml
Subject: Re: [PATCH] ELAN touchpad i2c_hid bugs fix
[EXTERNAL EMAIL]
+Cc: Mario
Mario, do you have any insights about the issue with touchpad on Dell
system described below?
My apologies, this got lost while I was on vacation.
On Thu, Mar 21, 2019 at 6:08 AM Kai-Heng Feng
wrote:
at 01:18, Andy Shevchenko wrote:
On Wed, Mar 20, 2019 at 6:55 PM Kai-Heng Feng
wrote:
at 23:39, Hans de Goede wrote:
On 3/20/19 3:37 PM, Benjamin Tissoires wrote:
Benjamin, what I find interesting here is that the BOGUS_IRQ quirk
is also used on Elan devices, I suspect that these Elan devices
likely also need the I2C_HID_QUIRK_FORCE_TRIGGER_FALLING quirk
and then they probably will no longer need the bogus IRQ flag,
if you know about bugreports with an acpidump for any of the devices
needing the bogus IRQ quirk, then I (or you) can check how the IRQ is
declared there, I suspect it will be declared as level-low, just like
with the laptop this patch was written for. And it probably need to
be edge-falling instead of level-low just like this case.
First, I’ve already tried using IRQF_TRIGGER_FALLING, unfortunately it
doesn’t solve the issue for me.
I talked to Elan once, and they confirm the correct IRQ trigger is
level
low. So forcing falling trigger may break other platforms.
As far as I understood Vladislav the quirk he got from Elan as well.
Ok, then this is really weird.
Recently we found that Elan touchpad doesn’t like GpioInt() from its
_CRS.
Once the Interrupt() is used instead, the issue goes away.
IIRC i2c core tries to get interrupt from Interrupt() resource and
then falls back to GpioInt().
See i2c_acpi_get_info() and i2c_device_probe().
Here’s its ASL:
Scope (\_SB.PCI0.I2C4)
{
Device (TPD0)
{
Name (_ADR, One) // _ADR: Address
Name (_HID, "DELL08AE") // _HID: Hardware ID
Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) // _CID:
Compatible ID
Name (_UID, One) // _UID: Unique ID
Name (_S0W, 0x04) // _S0W: S0 Device Wake State
Name (SBFB, ResourceTemplate ()
{
I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C4",
0x00, ResourceConsumer, , Exclusive,
)
})
Name (SBFG, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullUp, 0x,
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0012
}
})
Name (SBFI, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow,
ExclusiveAndWake, ,, )
{
0x003C,
}
})
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
If ((TCPD == One))
{
Return (0x0F)
}
Return (Zero)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
If ((OSYS < 0x07DC))
{
Return (SBFI) /* \_SB_.PCI0.I2C4.TPD0.SBFI */
}
Return (ConcatenateResTemplate (SBFB, SBFG))
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg0 == ToUUID ("3cdff6f7-4267-4555-ad05-b30a3d8938de") /*
HID
I2C Device */))
{
If ((Arg2 == Zero))
{
If ((Arg1 == One))
{
Return (Buffer (One)
{
0x03
// .
})
}
Else
{
Return (Buffer (One)
{
0x00
// .
})
}
}
ElseIf ((Arg2 == One))
{
Return (0x20)
}
Else
{
Return (Buffer (One)
linux-next: Tree for Apr 2
Hi all, Changes since 20190401: New tree: nand-fixes The nand tree gained a build failure so I used the version from next-20190401. The drm-misc tree gained a build failure due to an interaction with a change in Linus' tree for which I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 3998 3646 files changed, 123258 insertions(+), 54404 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 300 trees (counting Linus' and 71 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (5e7a8ca31926 Merge branch 'work.aio' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging fixes/master (b352face4ca9 adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (2d212a1bac7e NFC: st21nfca: Fix fall-through warnings) Merging kbuild-current/fixes (79a3aaa7b82e Linux 5.1-rc3) Merging arc-current/for-curr (831e90bd606e ARC: PAE40: don't panic and instead turn off hw ioc) Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for PMSAv8's PRBAR4/PRLAR4) Merging arm64-fixes/for-next/fixes (9e0a17db517d arm64: replace memblock_alloc_low with memblock_alloc) Merging m68k-current/for-linus (28713169d879 m68k: Add -ffreestanding to CFLAGS) Merging powerpc-fixes/fixes (6f845ebec270 powerpc/pseries/mce: Fix misleading print for TLB mutlihit) Merging sparc/master (7d762d69145a afs: Fix manually set volume location server list) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (8c1074f690bc MAINTAINERS: net: update Solarflare maintainers) Merging bpf/master (d3de85a51a4b Merge branch 'net-stmmac-fix-handling-of-oversized-frames') Merging ipsec/master (025c65e119bf xfrm: Honor original L3 slave device in xfrmi policy lookup) Merging netfilter/master (5f543a54eec0 net: hns3: fix for not calculating tx bd num correctly) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (4837696f6b54 Merge tag 'iwlwifi-for-kalle-2019-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (53bf5811ca37 cfg80211: add ratelimited variants of err and warn) Merging rdma-fixes/for-rc (1abe186ed8a6 IB/mlx5: Reset access mask when looping inside page fault handler) Merging sound-current/for-linus (e2a829b3da01 ALSA: hda/realtek - Fix speakers on Acer Predator Helios 500 Ryzen laptops) Merging sound-asoc-fixes/for-linus (4259c21f8f7e Merge branch 'asoc-5.1' into asoc-linus) Merging regmap-fixes/for-linus (76da4321eac8 Merge branch 'regmap-5.1' into regmap-linus) Merging regulator-fixes/for-linus (ce84eca9761e Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (02b45338db7c Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (0fa635aec9ab PCI/LINK: Deduplicate bandwidth reports for multi-function devices) Merging driver-core.current/driver-core-linus (79a3aaa7b82e Linux 5.1-rc3) Merging tty.current/tty-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb.current/usb-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb-gadget-fixes/fixes (072684e8c58d USB: gad
[PATCHv3] x86/boot/KASLR: skip the specified crashkernel region
crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
fail to reserve the required memory region if KASLR puts kernel into the
region. To avoid this uncertainty, asking KASLR to skip the required
region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Baoquan He
Cc: Will Deacon
Cc: Nicolas Pitre
Cc: Pingfan Liu
Cc: Chao Fan
Cc: "Kirill A. Shutemov"
Cc: Ard Biesheuvel
Cc: linux-kernel@vger.kernel.org
---
v2 -> v3: adding parsing of crashkernel=range1:size1[,range2:size2,...]@offset
arch/x86/boot/compressed/kaslr.c | 116 ++-
1 file changed, 114 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 2e53c05..7f698f4 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -107,6 +107,7 @@ enum mem_avoid_index {
MEM_AVOID_BOOTPARAMS,
MEM_AVOID_MEMMAP_BEGIN,
MEM_AVOID_MEMMAP_END = MEM_AVOID_MEMMAP_BEGIN + MAX_MEMMAP_REGIONS - 1,
+ MEM_AVOID_CRASHKERNEL,
MEM_AVOID_MAX,
};
@@ -238,6 +239,115 @@ static void parse_gb_huge_pages(char *param, char *val)
}
}
+/* code heavily copied from parse_crashkernel_mem() */
+static void handle_crashkernel_mem(char *cmdline,
+ unsigned long long system_ram,
+ unsigned long long *crash_size,
+ unsigned long long *crash_base)
+{
+ char *tmp, *cur = cmdline;
+
+ /* for each entry of the comma-separated list */
+ do {
+ unsigned long long start, end = ULLONG_MAX, size;
+
+ /* get the start of the range */
+ start = memparse(cur, &tmp);
+ /* no value given */
+ if (cur == tmp)
+ return;
+ cur = tmp;
+ if (*cur != '-')
+ return;
+ cur++;
+
+ /* if no ':' is here, than we read the end */
+ if (*cur != ':') {
+ end = memparse(cur, &tmp);
+ /* no value given */
+ if (cur == tmp)
+ return;
+ cur = tmp;
+ /* invalid if crashkernel end <= start */
+ if (end <= start)
+ return;
+ }
+ /* expect ":" after range */
+ if (*cur != ':')
+ return;
+ cur++;
+
+ size = memparse(cur, &tmp);
+ /* no size value given */
+ if (cur == tmp)
+ return;
+ cur = tmp;
+ if (size >= system_ram)
+ return;
+
+ /* match ? */
+ if (system_ram >= start && system_ram < end) {
+ *crash_size = size;
+ break;
+ }
+ } while (*cur++ == ',');
+
+ if (*crash_size > 0) {
+ while (*cur && *cur != ' ' && *cur != '@')
+ cur++;
+ if (*cur == '@') {
+ cur++;
+ *crash_base = memparse(cur, &tmp);
+ }
+ }
+}
+
+/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset options */
+static void mem_avoid_specified_crashkernel_region(char *option)
+{
+ unsigned long long crash_size, crash_base = 0;
+ char*first_colon, *first_space, *cur = option;
+
+ first_colon = strchr(option, ':');
+ first_space = strchr(option, ' ');
+ /* if contain ":" */
+ if (first_colon && (!first_space || first_colon < first_space)) {
+ int i;
+ u64 total_sz = 0;
+ struct boot_e820_entry *entry;
+
+ for (i = 0; i < boot_params->e820_entries; i++) {
+ entry = &boot_params->e820_table[i];
+ /* Skip non-RAM entries. */
+ if (entry->type != E820_TYPE_RAM)
+ continue;
+ total_sz += entry->size;
+ }
+ handle_crashkernel_mem(option, total_sz, &crash_size,
+ &crash_base);
+ } else {
+ crash_size = memparse(option, &cur);
+ if (option == cur)
+ return;
+ while (*cur && *cur != ' ' && *cur != '@')
+ cur++;
+ if (*cur == '@') {
+ option = cur + 1;
+ crash_base = memparse(option, &cur);
+ }
+ }
+ if (crash_base) {
+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
+ } else {
+
Re: [PATCH 068/114] drivers: mfd: Kconfig: pedantic formatting
On Mon, 11 Mar 2019, Enrico Weigelt, metux IT consult wrote: > Formatting of Kconfig files doesn't look so pretty, so let the > Great White Handkerchief come around and clean it up. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > drivers/mfd/Kconfig | 62 > ++--- > 1 file changed, 31 insertions(+), 31 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: cros_ec_dev: Add a poll handler to receive MKBP events
On Fri, 08 Mar 2019, Enric Balletbo i Serra wrote: > From: Vincent Palatin > > Allow to poll on the cros_ec device to receive the MKBP events. > > The /dev/cros_[ec|fp|..] file operations now implements the poll > operation. The userspace can now receive specific MKBP events by doing the > following: > - Open the /dev/cros_XX file. > - Call the CROS_EC_DEV_IOCEVENTMASK ioctl with the bitmap of the MKBP > events it wishes to receive as argument. > - Poll on the file descriptor. > - When it gets POLLIN, do a read on the file descriptor, the first > queued event will be returned (using the struct > ec_response_get_next_event format: one byte of event type, then > the payload). > > The read() operation returns at most one event even if there are several > queued, and it might be truncated if the buffer is smaller than the > event (but the caller should know the maximum size of the events it is > reading). > > read() used to return the EC version string, it still does it when no > event mask or an empty event is set for backward compatibility (despite > nobody really using this feature). > > This will be used, for example, by the userspace daemon to receive and > treat the EC_MKBP_EVENT_FINGERPRINT sent by the FP MCU. MFD does not seem like the correct place for this. Maybe this is a good candidate for drivers/platform/chrome/* where the rest of your platform empire now resides. > Signed-off-by: Vincent Palatin > Signed-off-by: Enric Balletbo i Serra > --- > > drivers/mfd/cros_ec_dev.c | 163 +- > drivers/mfd/cros_ec_dev.h | 1 + > 2 files changed, 160 insertions(+), 4 deletions(-) -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v5 6/9] mtd: rawnand: denali_pci: rename goto labels
As Documentation/process/coding-style.rst says, choose label names
which say what the goto does. The out_ label style is already
used in denali_dt.c. Rename likewise for denali_pci.c
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali_pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali_pci.c
b/drivers/mtd/nand/raw/denali_pci.c
index 48e9ac5..02eb599 100644
--- a/drivers/mtd/nand/raw/denali_pci.c
+++ b/drivers/mtd/nand/raw/denali_pci.c
@@ -84,20 +84,20 @@ static int denali_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
if (!denali->host) {
dev_err(&dev->dev, "Spectra: ioremap_nocache failed!");
ret = -ENOMEM;
- goto failed_remap_reg;
+ goto out_unmap_reg;
}
ret = denali_init(denali);
if (ret)
- goto failed_remap_mem;
+ goto out_unmap_host;
pci_set_drvdata(dev, denali);
return 0;
-failed_remap_mem:
+out_unmap_host:
iounmap(denali->host);
-failed_remap_reg:
+out_unmap_reg:
iounmap(denali->reg);
return ret;
}
--
2.7.4
[PATCH v5 8/9] mtd: rawnand: denali: remove DENALI_NR_BANKS macro
Use the runtime-detected denali->nbanks instead of hard-coded
DENALI_NR_BANKS (=4).
The actual number of banks depends on the IP configuration, and
can be less than DENALI_NR_BANKS. It is pointless to touch
registers of unsupported banks.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 8722762..e918c3d 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -40,7 +40,6 @@
#define DENALI_BANK(denali)((denali)->active_bank << 24)
#define DENALI_INVALID_BANK-1
-#define DENALI_NR_BANKS4
static struct denali_chip *to_denali_chip(struct nand_chip *chip)
{
@@ -92,7 +91,7 @@ static void denali_enable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(U32_MAX, denali->reg + INTR_EN(i));
iowrite32(GLOBAL_INT_EN_FLAG, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -101,7 +100,7 @@ static void denali_disable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(0, denali->reg + INTR_EN(i));
iowrite32(0, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -117,7 +116,7 @@ static void denali_clear_irq_all(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
denali_clear_irq(denali, i, U32_MAX);
}
@@ -130,7 +129,7 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
spin_lock(&denali->irq_lock);
- for (i = 0; i < DENALI_NR_BANKS; i++) {
+ for (i = 0; i < denali->nbanks; i++) {
irq_status = ioread32(denali->reg + INTR_STATUS(i));
if (irq_status)
ret = IRQ_HANDLED;
--
2.7.4
[PATCH v5 2/9] mtd: rawnand: denali: refactor raw page accessors
The Denali IP adopts the syndrome page layout (payload and ECC are
interleaved). The *_page_raw() and *_oob() callbacks are complicated
because they must hide the underlying layout used by the hardware,
and always return contiguous in-band and out-of-band data.
The Denali IP cannot reuse nand_{read,write}_page_raw_syndrome()
in nand_base.c because its hardware ECC engine skips some of first
bytes in OOB. That is why this driver implements specially-crafted
*_page_raw() and *_oob() hooks.
Currently, similar code is duplicated to reorganize the data layout.
For example, denali_read_page_raw() and denali_write_page_raw() look
almost the same. The complexity is partly due to the DMA transfer
used for better performance of *_page_raw() accessors.
On second thought, we do not need to care about their performance
because MTD_OPS_RAW is rarely used.
Let's focus on code cleanups rather than the performance. This commit
removes the internal buffer for DMA, and factors out as much code as
possible.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4:
- Do not pass function pointers
- The code simplicity wins over the performance
since the raw accessors are rarely used.
Changes in v3:
- Add comments to denali_raw_payload_op() and denali_oob_payload_op()
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 446 +-
drivers/mtd/nand/raw/denali.h | 1 -
2 files changed, 182 insertions(+), 265 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 83156f4..6a3520f 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -287,6 +287,182 @@ static void denali_cmd_ctrl(struct nand_chip *chip, int
dat, unsigned int ctrl)
denali->host_write(denali, DENALI_BANK(denali) | type, dat);
}
+static int denali_change_column(struct nand_chip *chip, unsigned int offset,
+ void *buf, unsigned int len, bool write)
+{
+ if (write)
+ return nand_change_write_column_op(chip, offset, buf, len,
+ false);
+ else
+ return nand_change_read_column_op(chip, offset, buf, len,
+ false);
+}
+
+static int denali_payload_xfer(struct nand_chip *chip, void *buf, bool write)
+{
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = &chip->ecc;
+ int writesize = mtd->writesize;
+ int oob_skip = denali->oob_skip_bytes;
+ int ret, i, pos, len;
+
+ for (i = 0; i < ecc->steps; i++) {
+ pos = i * (ecc->size + ecc->bytes);
+ len = ecc->size;
+
+ if (pos >= writesize) {
+ pos += oob_skip;
+ } else if (pos + len > writesize) {
+ /* This chunk overwraps the BBM area. Must be split */
+ ret = denali_change_column(chip, pos, buf,
+ writesize - pos, write);
+ if (ret)
+ return ret;
+
+ buf += writesize - pos;
+ len -= writesize - pos;
+ pos = writesize + oob_skip;
+ }
+
+ ret = denali_change_column(chip, pos, buf, len, write);
+ if (ret)
+ return ret;
+
+ buf += len;
+ }
+
+ return 0;
+}
+
+static int denali_oob_xfer(struct nand_chip *chip, void *buf, bool write)
+{
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = &chip->ecc;
+ int writesize = mtd->writesize;
+ int oobsize = mtd->oobsize;
+ int oob_skip = denali->oob_skip_bytes;
+ int ret, i, pos, len;
+
+ /* BBM at the beginning of the OOB area */
+ ret = denali_change_column(chip, writesize, buf, oob_skip, write);
+ if (ret)
+ return ret;
+
+ buf += oob_skip;
+
+ for (i = 0; i < ecc->steps; i++) {
+ pos = ecc->size + i * (ecc->size + ecc->bytes);
+
+ if (i == ecc->steps - 1)
+ /* The last chunk includes OOB free */
+ len = writesize + oobsize - pos - oob_skip;
+ else
+ len = ecc->bytes;
+
+ if (pos >= writesize) {
+ pos += oob_skip;
+ } else if (pos + len > writesize) {
+ /* This chunk overwraps the BBM area. Must be split */
+ ret = denali_change_column(chip, pos, buf,
+ writesize - pos, write);
+ if (ret)
+ return ret;
+
+ buf += writes
[PATCH v5 1/9] mtd: rawnand: denali: use more nand_chip pointers for internal functions
With the recent refactoring, the NAND driver hooks now take a pointer
to nand_chip. Add to_denali() in order to convert (struct nand_chip *)
to (struct denali_nand_info *) directly. It is more useful than the
current mtd_to_denali().
I changed some helper functions to take (struct nand_chip *). This will
avoid pointer conversion back and forth, and ease further development.
Signed-off-by: Masahiro Yamada
---
Changes in v5:
- pass nand_chip to denali_check_erased_page(),
denali_hw_ecc_fixup(), and denali_hw_ecc_fixup()
instead of passing them both nand_chip and denali_nand_info.
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 61 ---
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 24aeafc..83156f4 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -47,6 +47,11 @@ static inline struct denali_nand_info *mtd_to_denali(struct
mtd_info *mtd)
return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
}
+static struct denali_nand_info *to_denali(struct nand_chip *chip)
+{
+ return container_of(chip, struct denali_nand_info, nand);
+}
+
/*
* Direct Addressing - the slave address forms the control information (command
* type, bank, block, and page address). The slave data is the actual data to
@@ -282,12 +287,12 @@ static void denali_cmd_ctrl(struct nand_chip *chip, int
dat, unsigned int ctrl)
denali->host_write(denali, DENALI_BANK(denali) | type, dat);
}
-static int denali_check_erased_page(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf,
+static int denali_check_erased_page(struct nand_chip *chip, u8 *buf,
unsigned long uncor_ecc_flags,
unsigned int max_bitflips)
{
- struct denali_nand_info *denali = mtd_to_denali(mtd);
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_ecc_stats *ecc_stats = &nand_to_mtd(chip)->ecc_stats;
uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
int ecc_steps = chip->ecc.steps;
int ecc_size = chip->ecc.size;
@@ -303,9 +308,9 @@ static int denali_check_erased_page(struct mtd_info *mtd,
NULL, 0,
chip->ecc.strength);
if (stat < 0) {
- mtd->ecc_stats.failed++;
+ ecc_stats->failed++;
} else {
- mtd->ecc_stats.corrected += stat;
+ ecc_stats->corrected += stat;
max_bitflips = max_t(unsigned int, max_bitflips, stat);
}
@@ -316,11 +321,11 @@ static int denali_check_erased_page(struct mtd_info *mtd,
return max_bitflips;
}
-static int denali_hw_ecc_fixup(struct mtd_info *mtd,
- struct denali_nand_info *denali,
+static int denali_hw_ecc_fixup(struct nand_chip *chip,
unsigned long *uncor_ecc_flags)
{
- struct nand_chip *chip = mtd_to_nand(mtd);
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_ecc_stats *ecc_stats = &nand_to_mtd(chip)->ecc_stats;
int bank = denali->active_bank;
uint32_t ecc_cor;
unsigned int max_bitflips;
@@ -346,16 +351,17 @@ static int denali_hw_ecc_fixup(struct mtd_info *mtd,
* Unfortunately, we can not know the total number of corrected bits in
* the page. Increase the stats by max_bitflips. (compromised solution)
*/
- mtd->ecc_stats.corrected += max_bitflips;
+ ecc_stats->corrected += max_bitflips;
return max_bitflips;
}
-static int denali_sw_ecc_fixup(struct mtd_info *mtd,
- struct denali_nand_info *denali,
+static int denali_sw_ecc_fixup(struct nand_chip *chip,
unsigned long *uncor_ecc_flags, uint8_t *buf)
{
- unsigned int ecc_size = denali->nand.ecc.size;
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_ecc_stats *ecc_stats = &nand_to_mtd(chip)->ecc_stats;
+ unsigned int ecc_size = chip->ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
uint32_t err_addr, err_cor_info;
@@ -404,7 +410,7 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
/* correct the ECC error */
flips_in_byte = hweight8(buf[offset] ^ err_cor_value);
buf[offset] ^= err_cor_value;
- mtd->ecc_stats.corrected += flips_in_byte;
+ ecc_stats->corrected += flips_in_byte;
bitflips += flips_in_byte;
max_bitflips = max(max_bitflips,
[PATCH v5 5/9] mtd: rawnand: denali: use bool type instead of int where appropriate
Use 'bool' type for the following boolean parameters.
- write (write or read?)
- dma_avail (DMA engine available or not?)
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Use bool for dma_avail as well
drivers/mtd/nand/raw/denali.c | 23 ---
drivers/mtd/nand/raw/denali.h | 4 ++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index b9bc406..a501d9e 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -533,7 +533,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
}
static void denali_setup_dma64(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -547,7 +547,8 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
*burst len = 64 bytes, the number of pages
*/
denali->host_write(denali, mode,
- 0x01002000 | (64 << 16) | (write << 8) | page_count);
+ 0x01002000 | (64 << 16) |
+ (write ? BIT(8) : 0) | page_count);
/* 2. set memory low address */
denali->host_write(denali, mode, lower_32_bits(dma_addr));
@@ -557,7 +558,7 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
}
static void denali_setup_dma32(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -568,7 +569,7 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
/* 1. setup transfer type and # of pages */
denali->host_write(denali, mode | page,
- 0x2000 | (write << 8) | page_count);
+ 0x2000 | (write ? BIT(8) : 0) | page_count);
/* 2. set memory high address bits 23:8 */
denali->host_write(denali, mode | ((dma_addr >> 16) << 8), 0x2200);
@@ -628,7 +629,7 @@ static int denali_pio_write(struct denali_nand_info
*denali, const u32 *buf,
}
static int denali_pio_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
if (write)
return denali_pio_write(denali, buf, size, page);
@@ -637,7 +638,7 @@ static int denali_pio_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_dma_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
dma_addr_t dma_addr;
uint32_t irq_mask, irq_status, ecc_err_mask;
@@ -694,7 +695,7 @@ static int denali_dma_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_page_xfer(struct nand_chip *chip, void *buf, size_t size,
- int page, int write)
+ int page, bool write)
{
struct denali_nand_info *denali = to_denali(chip);
@@ -715,7 +716,7 @@ static int denali_read_page(struct nand_chip *chip, uint8_t
*buf,
int stat = 0;
int ret;
- ret = denali_page_xfer(chip, buf, mtd->writesize, page, 0);
+ ret = denali_page_xfer(chip, buf, mtd->writesize, page, false);
if (ret && ret != -EBADMSG)
return ret;
@@ -744,7 +745,7 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
{
struct mtd_info *mtd = nand_to_mtd(chip);
- return denali_page_xfer(chip, (void *)buf, mtd->writesize, page, 1);
+ return denali_page_xfer(chip, (void *)buf, mtd->writesize, page, true);
}
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
@@ -1001,7 +1002,7 @@ static int denali_attach_chip(struct nand_chip *chip)
int ret;
if (ioread32(denali->reg + FEATURES) & FEATURES__DMA)
- denali->dma_avail = 1;
+ denali->dma_avail = true;
if (denali->dma_avail) {
int dma_bit = denali->caps & DENALI_CAP_DMA_64BIT ? 64 : 32;
@@ -1010,7 +1011,7 @@ static int denali_attach_chip(struct nand_chip *chip)
if (ret) {
dev_info(denali->dev,
"Failed to set DMA mask. Disabling DMA.\n");
- denali->dma_avail = 0;
+ denali->dma_avail = false;
}
}
diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
index 4447184..d2603c6 100644
--- a/drivers/mtd/nand/raw/denali.h
+++ b/drivers/mtd/nand/raw/denali.h
@@ -303,7 +303,7 @@ struc
[PATCH v5 7/9] mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada
Acked-by: Rob Herring
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- simplify mtd->name fallback
- Add Rob's Ack
Changes in v2: None
.../devicetree/bindings/mtd/denali-nand.txt| 40 +-
drivers/mtd/nand/raw/denali.c | 430 -
drivers/mtd/nand/raw/denali.h | 114 +-
drivers/mtd/nand/raw/denali_dt.c | 98 -
drivers/mtd/nand/raw/denali_pci.c | 30 +-
5 files changed, 482 insertions(+), 230 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index f33da87..b14b675 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -7,34 +7,48 @@ Required properties:
"socionext,uniphier-denali-nand-v5b" - for Socionext UniPhier (v5b)
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
+ - #address-cells: should be 1. The cell encodes the chip select connection.
+ - #size-cells : should be 0.
- interrupts : The interrupt number.
- clocks: should contain phandle of the controller core clock, the bus
interface clock, and the ECC circuit clock.
- clock-names: should contain "nand", "nand_x", "ecc"
-Optional properties:
- - nand-ecc-step-size: see nand.txt for details. If present, the value must
be
- 512for "altr,socfpga-denali-nand"
- 1024 for "socionext,uniphier-denali-nand-v5a"
- 1024 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-strength: see nand.txt for details. Valid values are:
- 8, 15 for "altr,socfpga-denali-nand"
- 8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
- 8, 16 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-maximize: see nand.txt for details
-
-The device tree may optionally contain sub-nodes describing partitions of the
+Sub-nodes:
+ Sub-nodes represent available NAND chips.
+
+ Required properties:
+- reg: should contain the bank ID of the controller to which each chip
+ select is connected.
+
+ Optional properties:
+- nand-ecc-step-size: see nand.txt for details.
+ If present, the value must be
+512for "altr,socfpga-denali-nand"
+1024 for "socionext,uniphier-denali-nand-v5a"
+1024 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-strength: see nand.txt for details. Valid values are:
+8, 15 for "altr,socfpga-denali-nand"
+8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
+8, 16 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-maximize: see nand.txt for details
+
+The chip nodes may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Examples:
nand: nand@ff90 {
#address-cells = <1>;
- #size-cells = <1>;
+ #size-cells = <0>;
compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x20>, <0xffb8 0x1000>;
reg-names = "nand_data", "denali_reg";
clocks = <&nand_clk>, <&nand_x_clk>, <&nand_ecc_clk>;
clock-names = "nand", "nand_x", "ecc";
interrupts = <0 144 4>;
+
+ nand@0 {
+ reg = <0>;
+ }
};
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index a501d9e..8722762 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -3,7 +3,7 @@
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
*
- * Copyright (c) 2017 Socionext Inc.
+ * Copyright (c) 2017-2019 Socionext Inc.
* Reworked by Masahiro Yamada
*/
@@ -42,14 +42,15 @@
#define DENALI_INVALID_BANK-1
#define DENALI_NR_BANKS4
-static inline struct denali_n
[PATCH v5 3/9] mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
Since (u32 *) can accept an opaque pointer, the explicit casting
from (void *) to (u32 *) is redundant. Change the function argument type
to remove the casts.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 6a3520f..1422015 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -654,11 +654,10 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
denali->host_write(denali, mode | 0x14000, 0x2400);
}
-static int denali_pio_read(struct denali_nand_info *denali, void *buf,
+static int denali_pio_read(struct denali_nand_info *denali, u32 *buf,
size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status, ecc_err_mask;
int i;
@@ -670,7 +669,7 @@ static int denali_pio_read(struct denali_nand_info *denali,
void *buf,
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- *buf32++ = denali->host_read(denali, addr);
+ buf[i] = denali->host_read(denali, addr);
irq_status = denali_wait_for_irq(denali, INTR__PAGE_XFER_INC);
if (!(irq_status & INTR__PAGE_XFER_INC))
@@ -682,18 +681,17 @@ static int denali_pio_read(struct denali_nand_info
*denali, void *buf,
return irq_status & ecc_err_mask ? -EBADMSG : 0;
}
-static int denali_pio_write(struct denali_nand_info *denali,
- const void *buf, size_t size, int page)
+static int denali_pio_write(struct denali_nand_info *denali, const u32 *buf,
+ size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- const uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status;
int i;
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- denali->host_write(denali, addr, *buf32++);
+ denali->host_write(denali, addr, buf[i]);
irq_status = denali_wait_for_irq(denali,
INTR__PROGRAM_COMP | INTR__PROGRAM_FAIL);
--
2.7.4
[PATCH v5 0/9] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups
I took time for the Denali driver to catch up with the latest framework.
- switch over to exec_op() and remove legacy hooks
- separate controller/chips
- various cleanups
Major changes in v5:
- Passing both nand_chip and denali is redundant.
Pass only nand_chip to local helpers.
Major changes in v4:
- Add denali_exec_out() and denali_exec_in()
in order to make denali_exec_instr() readable
- Make .read_page_raw() and .write_page_raw() even simpler
by giving up the performance
Major changes in v3:
- Drop "mtd: rawnand: denali: use more precise timeout for
NAND_OP_WAITRDT_INSTR"
entirely according to the review comments in v2
- Add comments to helpers in 2/9
Masahiro Yamada (9):
mtd: rawnand: denali: use more nand_chip pointers for internal
functions
mtd: rawnand: denali: refactor raw page accessors
mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
mtd: rawnand: denali: use bool type instead of int where appropriate
mtd: rawnand: denali_pci: rename goto labels
mtd: rawnand: denali: decouple controller and NAND chips
mtd: rawnand: denali: remove DENALI_NR_BANKS macro
mtd: rawnand: denali: clean up coding style
.../devicetree/bindings/mtd/denali-nand.txt| 40 +-
drivers/mtd/nand/raw/denali.c | 1146 ++--
drivers/mtd/nand/raw/denali.h | 117 +-
drivers/mtd/nand/raw/denali_dt.c | 98 +-
drivers/mtd/nand/raw/denali_pci.c | 38 +-
5 files changed, 823 insertions(+), 616 deletions(-)
--
2.7.4
[PATCH v5 9/9] mtd: rawnand: denali: clean up coding style
Eliminate the following reports from 'scripts/checkpatch.pl --strict'.
CHECK: Prefer kernel type 'u8' over 'uint8_t'
CHECK: Prefer kernel type 'u32' over 'uint32_t'
CHECK: Alignment should match open parenthesis
I slightly changed denali_check_erased_page() to shorten it.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 54 +--
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index e918c3d..132956d 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -106,7 +106,7 @@ static void denali_disable_irq(struct denali_controller
*denali)
}
static void denali_clear_irq(struct denali_controller *denali,
-int bank, uint32_t irq_status)
+int bank, u32 irq_status)
{
/* write one to clear bits */
iowrite32(irq_status, denali->reg + INTR_STATUS(bank));
@@ -124,7 +124,7 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
{
struct denali_controller *denali = dev_id;
irqreturn_t ret = IRQ_NONE;
- uint32_t irq_status;
+ u32 irq_status;
int i;
spin_lock(&denali->irq_lock);
@@ -163,7 +163,7 @@ static void denali_reset_irq(struct denali_controller
*denali)
static u32 denali_wait_for_irq(struct denali_controller *denali, u32 irq_mask)
{
unsigned long time_left, flags;
- uint32_t irq_status;
+ u32 irq_status;
spin_lock_irqsave(&denali->irq_lock, flags);
@@ -411,20 +411,17 @@ static int denali_check_erased_page(struct nand_chip
*chip, u8 *buf,
{
struct denali_controller *denali = to_denali_controller(chip);
struct mtd_ecc_stats *ecc_stats = &nand_to_mtd(chip)->ecc_stats;
- uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
- int ecc_steps = chip->ecc.steps;
- int ecc_size = chip->ecc.size;
- int ecc_bytes = chip->ecc.bytes;
+ struct nand_ecc_ctrl *ecc = &chip->ecc;
+ u8 *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
int i, stat;
- for (i = 0; i < ecc_steps; i++) {
+ for (i = 0; i < ecc->steps; i++) {
if (!(uncor_ecc_flags & BIT(i)))
continue;
- stat = nand_check_erased_ecc_chunk(buf, ecc_size,
- ecc_code, ecc_bytes,
- NULL, 0,
- chip->ecc.strength);
+ stat = nand_check_erased_ecc_chunk(buf, ecc->size, ecc_code,
+ ecc->bytes, NULL, 0,
+ ecc->strength);
if (stat < 0) {
ecc_stats->failed++;
} else {
@@ -432,8 +429,8 @@ static int denali_check_erased_page(struct nand_chip *chip,
u8 *buf,
max_bitflips = max_t(unsigned int, max_bitflips, stat);
}
- buf += ecc_size;
- ecc_code += ecc_bytes;
+ buf += ecc->size;
+ ecc_code += ecc->bytes;
}
return max_bitflips;
@@ -445,7 +442,7 @@ static int denali_hw_ecc_fixup(struct nand_chip *chip,
struct denali_controller *denali = to_denali_controller(chip);
struct mtd_ecc_stats *ecc_stats = &nand_to_mtd(chip)->ecc_stats;
int bank = denali->active_bank;
- uint32_t ecc_cor;
+ u32 ecc_cor;
unsigned int max_bitflips;
ecc_cor = ioread32(denali->reg + ECC_COR_INFO(bank));
@@ -475,18 +472,18 @@ static int denali_hw_ecc_fixup(struct nand_chip *chip,
}
static int denali_sw_ecc_fixup(struct nand_chip *chip,
- unsigned long *uncor_ecc_flags, uint8_t *buf)
+ unsigned long *uncor_ecc_flags, u8 *buf)
{
struct denali_controller *denali = to_denali_controller(chip);
struct mtd_ecc_stats *ecc_stats = &nand_to_mtd(chip)->ecc_stats;
unsigned int ecc_size = chip->ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
- uint32_t err_addr, err_cor_info;
+ u32 err_addr, err_cor_info;
unsigned int err_byte, err_sector, err_device;
- uint8_t err_cor_value;
+ u8 err_cor_value;
unsigned int prev_sector = 0;
- uint32_t irq_status;
+ u32 irq_status;
denali_reset_irq(denali);
@@ -551,7 +548,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
static void denali_setup_dma64(struct denali_controller *denali,
dma_addr_t dma_addr, int page, bool write)
{
- uint32_t mode;
+ u32 mode;
const int page_count = 1;
mode = DENALI_MAP10 | DENALI_BANK(denali) | page;
@
[PATCH v5 4/9] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
Implement ->exec_op(), and remove the deprecated hooks.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4:
- add denali_exec_in() and denali_exec_out()
- avoid ternary operator to select function
Changes in v3:
- Fix byte-swap in denali_exec_in16()
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 251 --
1 file changed, 143 insertions(+), 108 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 1422015..b9bc406 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -206,85 +206,11 @@ static uint32_t denali_wait_for_irq(struct
denali_nand_info *denali,
return denali->irq_status;
}
-static void denali_read_buf(struct nand_chip *chip, uint8_t *buf, int len)
+static void denali_select_target(struct nand_chip *chip, int cs)
{
- struct mtd_info *mtd = nand_to_mtd(chip);
- struct denali_nand_info *denali = mtd_to_denali(mtd);
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- buf[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf(struct nand_chip *chip, const uint8_t *buf,
-int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- denali->host_write(denali, addr, buf[i]);
-}
-
-static void denali_read_buf16(struct nand_chip *chip, uint8_t *buf, int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- uint16_t *buf16 = (uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- buf16[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf16(struct nand_chip *chip, const uint8_t *buf,
- int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- const uint16_t *buf16 = (const uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- denali->host_write(denali, addr, buf16[i]);
-}
-
-static uint8_t denali_read_byte(struct nand_chip *chip)
-{
- uint8_t byte;
-
- denali_read_buf(chip, &byte, 1);
-
- return byte;
-}
-
-static void denali_write_byte(struct nand_chip *chip, uint8_t byte)
-{
- denali_write_buf(chip, &byte, 1);
-}
-
-static void denali_cmd_ctrl(struct nand_chip *chip, int dat, unsigned int ctrl)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t type;
-
- if (ctrl & NAND_CLE)
- type = DENALI_MAP11_CMD;
- else if (ctrl & NAND_ALE)
- type = DENALI_MAP11_ADDR;
- else
- return;
-
- /*
-* Some commands are followed by chip->legacy.waitfunc.
-* irq_status must be cleared here to catch the R/B# interrupt later.
-*/
- if (ctrl & NAND_CTRL_CHANGE)
- denali_reset_irq(denali);
+ struct denali_nand_info *denali = to_denali(chip);
- denali->host_write(denali, DENALI_BANK(denali) | type, dat);
+ denali->active_bank = cs;
}
static int denali_change_column(struct nand_chip *chip, unsigned int offset,
@@ -772,6 +698,8 @@ static int denali_page_xfer(struct nand_chip *chip, void
*buf, size_t size,
{
struct denali_nand_info *denali = to_denali(chip);
+ denali_select_target(chip, chip->cur_cs);
+
if (denali->dma_avail)
return denali_dma_xfer(denali, buf, size, page, write);
else
@@ -819,24 +747,6 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
return denali_page_xfer(chip, (void *)buf, mtd->writesize, page, 1);
}
-static void denali_select_chip(struct nand_chip *chip, int cs)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
-
- denali->active_bank = cs;
-}
-
-static int denali_waitfunc(struct nand_chip *chip)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t irq_status;
-
- /* R/B# pin transitioned from low to high? */
- irq_status = denali_wait_for_irq(denali, INTR__INT_ACT);
-
- return irq_status & INTR__INT_ACT ? 0 : NAND_STATUS_FAIL;
-}
-
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
const struct nand_data_interface *conf)
{
@@ -1149,13 +1059,6 @@ static int denali_attach_chip(struct nand_chip *chip)
mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
- if (chip->options & NAND_BUSWIDTH_16) {
- chip->legacy.read_buf = denali_read_buf16;
- chip->legacy.write_buf = denali_write_buf16;
- } e
Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel
(CC Kumar and Wolfgang who came up with spi-active-low, I think.) On Sun, Mar 24, 2019 at 1:56 PM H. Nikolaus Schaller wrote: > > Am 24.03.2019 um 05:15 schrieb Linus Walleij : > > But I fixed it in that case by introducing a spi-cs-high into the DTS file: > > https://marc.info/?l=linux-arm-kernel&m=155292310015309&w=2 > > Yes, that of course works and is our temporary solution. > > And I see that you also have it on the controller node and not the slave node. Yes I git it wrong, the slave should have it and another bug of mine made it look at the controller not (some days I should not write code in paths that do not get executed). > > I'm sorry about that, however if you look at the DT binding document: > > Documentation/devicetree/bindings/spi/spi-bus.txt > > Shouldn't it be a property of the slave node and not the controller node? Indeed. > > You will see that spi-cs-high is mandatory. So these DTS files are > > incorrect. > > How do you read that it is mandatory from > > "All slave nodes can contain the following optional properties: > - spi-cs-high - Empty property indicating device requires chip select > active high." > > I read it as optional and indicative. Equal priority to cs-gpios. The basic problem is that spi-cs-high is defined negatively, so by default a CS GPIO is active low. This clashes with the default GPIO flag, as GPIO_ACTIVE_HIGH is zero, no flag, and thus the default if nothing is specified, so if the GPIO flag is zero it should be active high, but if "spi-active-high" is not on the slave node it should be active low, so one of them have to win, they can't both win. I'd say that spi-cs-high existed before we standardized the GPIO flags in the DT bindings. So people were relying on it for years before we came up with the ACTIVE_HIGH/LOW flags. commit f618ebfcbf9616a0fa9a78f5ecb69762f0fa3c59 Author: Wolfgang Ocker Date: Wed Oct 15 15:00:47 2008 +0200 of/spi: Support specifying chip select as active high via device tree The patch allows to specify that an SPI device needs an active high chip select. Signed-off-by: Wolfgang Ocker Signed-off-by: Kumar Gala While the GPIO binding turns up 5 years later: commit 71fab21fee07fd6d5f1a984db387cc5e4596f3fa Author: Stephen Warren Date: Tue Feb 12 17:22:36 2013 -0700 ARM: dt: add header to define GPIO flags Many GPIO device tree bindings use the same flags. Create a header to define those. Signed-off-by: Stephen Warren Acked-by: Rob Herring And then this guy think it is a good idea to standardize this for all GPIO phandles two years later: commit 69d301fdd19635a39cb2b78e53fdd625b7a27924 Author: Linus Walleij Date: Thu Sep 24 15:05:45 2015 -0700 gpio: add DT bindings for existing consumer flags It is customary for GPIO controllers to support open drain/collector and open source/emitter configurations. Add standard GPIO line flags to account for this and augment the documentation to say that these are the most generic bindings. Several people approached me to add new flags to the lines, and this makes sense, but let's first bind up the most common cases before we start to add exotic stuff. Thanks to H. Nikolaus Schaller for ideas on how to encode single-ended wiring such as open drain/source and open collector/emitter. Cc: Tony Lindgren Cc: Grygorii Strashko Cc: H. Nikolaus Schaller Signed-off-by: Linus Walleij > > This does not work because there are devices that requires spi-cs-high to be > > respected and the DTS second cell GPIO flag to be ignored. > > Then, those should be fixed... This can't be done because some old systems (mostly powerpc) added between 2008-2013 do not know about GPIO flags and have DTBs deployed in firmware that need to keep working. They cannot be fixed. > > They might have deployed DTB binaries that need to keep working, > > Well, that is a weak argument. What if the GTA04 would have the DTB in FLASH > and would need it working (fortunately we always reflash kernel + dtbs)? Usually the definition I use for "deployed DTB" is not "deployed on my desk" but "deployed by a factory" i.e. someone producing millions of TV sets or something. For example my monitor is using a PowerPC CPU and has one of these DTBs in flash, and expect it to keep working if I upgrade the kernel separately. > BTW, on which node do these invariable DTBs have the spi-cs-high flag? > In the controller node (IMHO wrong) or the slave node (according to bindings > doc)? Slave node I hope, the controller thing was just one of my stupid mistakes. > I have checked with randomly picked imx51-babbage.dts and it has it in the > slave node (pmic: mc13892@0). It also seems to be an example where different > CS lines want different settings. I'm afraid the consumers of the old powerpc DTS files are not even maintained inside the Linux kernel, as we sometimes assume. Those were created and dispersed
Re: [PATCH 2/2] mfd: cros_ec: instantiate properly CrOS Touchpad MCU device
On Thu, 07 Mar 2019, Enric Balletbo i Serra wrote: > From: Wei-Ning Huang > > Support Touchpad MCU as a special of CrOS EC devices. The current > Touchpad MCU is used on Eve Chromebook and used the same protocol as > other CrOS EC devices. > > When a MCU has touchpad support (aka EC_FEATURE_TOUCHPAD), it is > instantiated as a special CrOS EC device with device name 'cros_tp'. So > regardless of the probing order between the actual cros_ec and cros_tp, > the userspace and other kernel drivers should not confuse them. > > Signed-off-by: Wei-Ning Huang > Signed-off-by: Enric Balletbo i Serra > --- > > drivers/mfd/cros_ec_dev.c | 10 ++ > include/linux/mfd/cros_ec.h | 1 + > 2 files changed, 11 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] mfd: cros_ec: instantiate properly CrOS FP MCU device
On Thu, 07 Mar 2019, Enric Balletbo i Serra wrote: > From: Vincent Palatin > > Support Fingerprint MCU as a special of CrOS EC devices. The current FP > MCU uses the same EC SPI protocol v3 as other CrOS EC devices on a SPI > bus. > > When a MCU has fingerprint support (aka EC_FEATURE_FINGERPRINT), it is > instantiated as a special CrOS EC device with device name 'cros_fp'. So > regardless of the probing order between the actual cros_ec and cros_fp, > the userspace and other kernel drivers should not confuse them. > > Signed-off-by: Vincent Palatin > Signed-off-by: Enric Balletbo i Serra > --- > > drivers/mfd/cros_ec_dev.c | 10 ++ > include/linux/mfd/cros_ec.h | 1 + > 2 files changed, 11 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 3/4] Makefile: lld: tell clang to use lld
On Sat, Feb 16, 2019 at 10:09 AM Masahiro Yamada wrote: > > On Thu, Feb 14, 2019 at 8:08 AM Nick Desaulniers > wrote: > > > > On Wed, Feb 13, 2019 at 6:59 AM Masahiro Yamada > > wrote: > > > > > > On Tue, Feb 12, 2019 at 5:42 AM wrote: > > > > > > > > This is needed because clang doesn't select which linker to use based on > > > > $LD but rather -fuse-ld=lld. This is problematic especially for > > > > cc-ldoption, which checks for linker flag support via invoking the > > > > compiler, rather than the linker. > > > > > > > > > Sorry, please explain what kind of problem > > > this patch solves. > > > > > > > > > > > > [1] $(LD) is used to link vmlinux, modules, etc. > > > > > > [2] $(CC) is used to link vdso, etc. > > > and -fuse-ld= selects which linker is invoked from $(CC) > > > > It solves case 2. > > > > > > > > > > > Is it a problem to use a different > > > type of linker for [1] and [2] ? > > > > Ideally, no, but I can think of at least one case where it might be > > problematic to mix linkers like that: > > You might be mixing linker flags added via ld-option from one linker > > that aren't actually supported by the other linker. > > You can do this only when you are sure > that the _exactly_ same linker is used. > > In my understanding, -fuse-ld=lld does not guarantee it. I really don't think we should be mixing and matching linkers during a kernel build. When we compile with clang, we don't have escape hatches that allow for some object files to be compiled with GCC (mixing clang and GCC compiled object files into one build). Following the same logic, I think mixing linkers during kernel build should similarly be dissuaded. This patch AVOIDS clang using a different linker than what was specified via $LD, which is CRITICAL for cc-ldoption kbuild macro. Masahiro, I hope this patch can be re-evaluated, or if I'm not understanding your point, that you can provide additional clarification. -- Thanks, ~Nick Desaulniers
Re: [PATCH] mfd: sm501: Fix potential NULL pointer dereference
On Sat, 02 Mar 2019, Aditya Pakki wrote: > lookup variable on failure of allocating memory via devm_kzalloc > can cause a NULL pointer dereference. This patch avoids such a scenario. > > Signed-off-by: Aditya Pakki > --- > drivers/mfd/sm501.c | 3 +++ > 1 file changed, 3 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: twl-core: disable irq while suspended
On Sat, 23 Feb 2019, Andreas Kemnade wrote:
> Since commit
> 6e2bd956936 ("i2c: omap: Use noirq system sleep pm ops to idle device for
> suspend")
> on gta04 we have handle_twl4030_pih() called in situations where
> pm_runtime_get()
> in i2c-omap.c returns -EACCES.
> [ 86.474365] Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
> done.
> [ 86.485473] printk: Suspending console(s) (use no_console_suspend to debug)
> [ 86.72] Disabling non-boot CPUs ...
> [ 86.555664] Successfully put all powerdomains to target state
> [ 86.563720] twl: Read failed (mod 1, reg 0x01 count 1)
> [ 86.563751] twl4030: I2C error -13 reading PIH ISR
> [ 86.563812] twl: Read failed (mod 1, reg 0x01 count 1)
> [ 86.563812] twl4030: I2C error -13 reading PIH ISR
> [ 86.563873] twl: Read failed (mod 1, reg 0x01 count 1)
> [ 86.563903] twl4030: I2C error -13 reading PIH ISR
>
> This happens when we wakeup via something behing twl4030
> (powerbutton or rtc alarm).
> This goes on for minutes until the system is finally resumed.
> Disable the irq on suspend and enable it on resume to avoid
> having i2c access problems when the irq registers are checked.
>
> Signed-off-by: Andreas Kemnade
> ---
> drivers/mfd/twl-core.c | 23 +++
> 1 file changed, 23 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v4 1/9] mtd: rawnand: denali: use nand_chip pointer more for internal functions
On Tue, Apr 2, 2019 at 2:14 AM Miquel Raynal wrote:
>
> Hi Masahiro,
>
> Boris Brezillon wrote on Sat, 30 Mar
> 2019 15:23:23 +0100:
>
> > On Fri, 29 Mar 2019 16:28:13 +0900
> > Masahiro Yamada wrote:
> >
> > > With the recent refactoring, the NAND driver hooks now take a pointer
> > > to nand_chip. Add to_denali() in order to convert (struct nand_chip *)
> > > to (struct denali_nand_info *) directly. It is more useful than the
> > > current mtd_to_denali().
> > >
> > > I changed some helper functions to take (struct nand_chip *). This will
> > > avoid pointer conversion back and forth, and ease further development.
> > >
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > Changes in v4: None
> > > Changes in v3: None
> > > Changes in v2: None
> > >
> > > drivers/mtd/nand/raw/denali.c | 57
> > > ---
> > > 1 file changed, 32 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
> > > index 24aeafc..4ac1314 100644
> > > --- a/drivers/mtd/nand/raw/denali.c
> > > +++ b/drivers/mtd/nand/raw/denali.c
> > > @@ -47,6 +47,11 @@ static inline struct denali_nand_info
> > > *mtd_to_denali(struct mtd_info *mtd)
> > > return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
> > > }
> > >
> > > +static struct denali_nand_info *to_denali(struct nand_chip *chip)
> > > +{
> > > + return container_of(chip, struct denali_nand_info, nand);
> > > +}
> > > +
> > > /*
> > > * Direct Addressing - the slave address forms the control information
> > > (command
> > > * type, bank, block, and page address). The slave data is the actual
> > > data to
> > > @@ -282,12 +287,12 @@ static void denali_cmd_ctrl(struct nand_chip *chip,
> > > int dat, unsigned int ctrl)
> > > denali->host_write(denali, DENALI_BANK(denali) | type, dat);
> > > }
> > >
> > > -static int denali_check_erased_page(struct mtd_info *mtd,
> > > - struct nand_chip *chip, uint8_t *buf,
> > > +static int denali_check_erased_page(struct nand_chip *chip,
> > > + struct denali_nand_info *denali, u8 *buf,
> >
> > You don't need to pass both chip and denali, as one can be extracted
> > from the other.
> >
> > > unsigned long uncor_ecc_flags,
> > > unsigned int max_bitflips)
> > > {
> > > - struct denali_nand_info *denali = mtd_to_denali(mtd);
> > > + struct mtd_ecc_stats *ecc_stats = &nand_to_mtd(chip)->ecc_stats;
> > > uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
> > > int ecc_steps = chip->ecc.steps;
> > > int ecc_size = chip->ecc.size;
> > > @@ -303,9 +308,9 @@ static int denali_check_erased_page(struct mtd_info
> > > *mtd,
> > > NULL, 0,
> > > chip->ecc.strength);
> > > if (stat < 0) {
> > > - mtd->ecc_stats.failed++;
> > > + ecc_stats->failed++;
> > > } else {
> > > - mtd->ecc_stats.corrected += stat;
> > > + ecc_stats->corrected += stat;
> > > max_bitflips = max_t(unsigned int, max_bitflips,
> > > stat);
> > > }
> > >
> > > @@ -316,11 +321,11 @@ static int denali_check_erased_page(struct mtd_info
> > > *mtd,
> > > return max_bitflips;
> > > }
> > >
> > > -static int denali_hw_ecc_fixup(struct mtd_info *mtd,
> > > +static int denali_hw_ecc_fixup(struct nand_chip *chip,
> > >struct denali_nand_info *denali,
> >
> > Ditto.
> >
>
> I am fine with the series in its current state, please submit a v5
> with Boris comment's addressed and I'll queue it right away to next.
>
OK, I will submit v5 shortly.
--
Best Regards
Masahiro Yamada
Re: [PATCH] regulator: wm8400: Get rid of wm8400_block_read/wm8400_set_bits functions
On Wed, 27 Feb 2019, Axel Lin wrote: > The only user of wm8400_block_read/wm8400_set_bits functions is the > wm8400 regulator driver. At the context of all the callers, we can > use regmap_bulk_read/regmap_update_bits directly. > Thus remove wm8400_block_read/wm8400_set_bits functions. > > Signed-off-by: Axel Lin > --- > drivers/mfd/wm8400-core.c| 6 -- Acked-by: Lee Jones Mark, can you take this? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] io_uring: introduce inline reqs for IORING_SETUP_IOPOLL & direct_io
On 4/1/19 9:10 PM, Jianchao Wang wrote:
> For the IORING_SETUP_IOPOLL & direct_io case, all of the submission
> and completion are handled under ctx->uring_lock or in SQ poll thread
> context, so io_get_req and io_put_req has been serialized well.
>
> Based on this, we introduce the preallocated reqs ring per ctx and
> needn't to provide any lock to serialize the updating of the head
> and tail. The performacne benefits from this. The test result of
> following fio command
>
> fio --name=io_uring_test --ioengine=io_uring --hipri --fixedbufs
> --iodepth=16 --direct=1 --numjobs=1 --filename=/dev/nvme0n1 --bs=4k
> --group_reporting --runtime=10
>
> shows IOPS upgrade from 197K to 206K.
I like this idea, but not a fan of the execution of it. See below.
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 6aaa3058..40837e4 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -104,11 +104,17 @@ struct async_list {
> size_t io_pages;
> };
>
> +#define INLINE_REQS_TOTAL 128
> +
> struct io_ring_ctx {
> struct {
> struct percpu_ref refs;
> } cacheline_aligned_in_smp;
>
> + struct io_kiocb *inline_reqs[INLINE_REQS_TOTAL];
> + struct io_kiocb *inline_req_array;
> + unsigned long inline_reqs_h, inline_reqs_t;
Why not just use a list? The req has a list member anyway. Then you don't
need a huge array, just a count.
> +
> struct {
> unsigned intflags;
> boolcompat;
> @@ -183,7 +189,9 @@ struct io_ring_ctx {
>
> struct sqe_submit {
> const struct io_uring_sqe *sqe;
> + struct file *file;
> unsigned short index;
> + boolis_fixed;
> boolhas_user;
> boolneeds_lock;
> boolneeds_fixed_file;
Not sure why you're moving these to the sqe_submit?
> @@ -228,7 +236,7 @@ struct io_kiocb {
> #define REQ_F_PREPPED16 /* prep already done */
> u64 user_data;
> u64 error;
> -
> + boolctx_inline;
> struct work_struct work;
> };
ctx_inline should just be a req flag.
>
> @@ -397,7 +405,8 @@ static void io_ring_drop_ctx_refs(struct io_ring_ctx
> *ctx, unsigned refs)
> }
>
> static struct io_kiocb *io_get_req(struct io_ring_ctx *ctx,
> -struct io_submit_state *state)
> +struct io_submit_state *state,
> +bool direct_io)
> {
> gfp_t gfp = GFP_KERNEL | __GFP_NOWARN;
> struct io_kiocb *req;
> @@ -405,10 +414,19 @@ static struct io_kiocb *io_get_req(struct io_ring_ctx
> *ctx,
> if (!percpu_ref_tryget(&ctx->refs))
> return NULL;
>
> - if (!state) {
> + /*
> + * Avoid race with workqueue context that handle buffered IO.
> + */
> + if (direct_io &&
> + ctx->inline_reqs_h - ctx->inline_reqs_t < INLINE_REQS_TOTAL) {
> + req = ctx->inline_reqs[ctx->inline_reqs_h % INLINE_REQS_TOTAL];
> + ctx->inline_reqs_h++;
> + req->ctx_inline = true;
> + } else if (!state) {
What happens for O_DIRECT that ends up being punted to async context?
We need a clearer indication of whether or not we're under the lock or
not, and then get rid of the direct_io "limitation" for this. Arguably,
cached buffered IO needs this even more than O_DIRECT does, since that
is much faster.
--
Jens Axboe
Re: [PATCH v5] mfd: cros_ec_dev: Register cros_ec_accel_legacy driver as a subdevice
On Wed, 27 Feb 2019, Gwendal Grignou wrote:
> From: Enric Balletbo i Serra
>
> With this patch, the cros_ec_ctl driver will register the legacy
> accelerometer driver (named cros_ec_accel_legacy) if it fails to
> register sensors through the usual path cros_ec_sensors_register().
> This legacy device is present on Chromebook devices with older EC
> firmware only supporting deprecated EC commands (Glimmer based devices).
>
> Tested-by: Gwendal Grignou
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Gwendal Grignou
> Reviewed-by: Andy Shevchenko
> ---
> Changes in v5:
> - Remove unnecessary white lines.
>
> Changes in v4:
> - [5/8] Nit: EC -> ECs (Lee Jones)
> - [5/8] Statically define cros_ec_accel_legacy_cells (Lee Jones)
>
> Changes in v3:
> - [5/8] Add the Reviewed-by Andy Shevchenko.
>
> Changes in v2:
> - [5/8] Add the Reviewed-by Gwendal.
>
> drivers/mfd/cros_ec_dev.c | 66 +++
> 1 file changed, 66 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index d275deaecb12..64567bd0a081 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -376,6 +376,69 @@ static void cros_ec_sensors_register(struct cros_ec_dev
> *ec)
> kfree(msg);
> }
>
> +static struct cros_ec_sensor_platform sensor_platforms[] = {
> + { .sensor_num = 0 },
> + { .sensor_num = 1 }
> +};
I'm still very uncomfortable with this struct.
Other than these indices, the sensors have no other distinguishing
features, thus there should be no need to identify or distinguish
between them in this way.
> +static const struct mfd_cell cros_ec_accel_legacy_cells[] = {
> + {
> + .name = "cros-ec-accel-legacy",
> + .id = 0,
> + .platform_data = &sensor_platforms[0],
> + .pdata_size = sizeof(struct cros_ec_sensor_platform),
> + },
> + {
> + .name = "cros-ec-accel-legacy",
> + .id = 1,
> + .platform_data = &sensor_platforms[1],
> + .pdata_size = sizeof(struct cros_ec_sensor_platform),
> + }
> +};
> +
> +static void cros_ec_accel_legacy_register(struct cros_ec_dev *ec)
> +{
> + struct cros_ec_device *ec_dev = ec->ec_dev;
> + u8 status;
> + int ret;
> +
> + /*
> + * ECs that need legacy support are the main EC, directly connected to
> + * the AP.
> + */
> + if (ec->cmd_offset != 0)
> + return;
> +
> + /*
> + * Check if EC supports direct memory reads and if EC has
> + * accelerometers.
> + */
> + if (!ec_dev->cmd_readmem)
> + return;
> +
> + ret = ec_dev->cmd_readmem(ec_dev, EC_MEMMAP_ACC_STATUS, 1, &status);
> + if (ret < 0) {
> + dev_warn(ec->dev, "EC does not support direct reads.\n");
> + return;
> + }
> +
> + /* Check if EC has accelerometers. */
> + if (!(status & EC_MEMMAP_ACC_STATUS_PRESENCE_BIT)) {
> + dev_info(ec->dev, "EC does not have accelerometers.\n");
> + return;
> + }
> +
> + /*
> + * Register 2 accelerometers
> + */
> + ret = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
Using PLATFORM_DEVID_AUTO whilst providing the MFD cells with IDs
doesn't make any sense. Please remove the IDs from the cells.
> + cros_ec_accel_legacy_cells,
> + ARRAY_SIZE(cros_ec_accel_legacy_cells),
> + NULL, 0, NULL);
> + if (ret)
> + dev_err(ec_dev->dev, "failed to add EC sensors\n");
> +}
> +
> static const struct mfd_cell cros_ec_cec_cells[] = {
> { .name = "cros-ec-cec" }
> };
> @@ -437,6 +500,9 @@ static int ec_device_probe(struct platform_device *pdev)
> /* check whether this EC is a sensor hub. */
> if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec);
> + else
> + /* Workaroud for older EC firmware */
> + cros_ec_accel_legacy_register(ec);
>
> /* Check whether this EC instance has CEC host command support */
> if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v8 1/2] dt-bindings: misc: aspeed-p2a-ctrl: add support
Hi Patrick,
I held off on reviewing this until we'd hashed out what we needed in the driver.
I have some comments below.
On Sat, 30 Mar 2019, at 01:40, Patrick Venture wrote:
> Document the ast2400, ast2500 PCI-to-AHB bridge control driver bindings.
>
> Signed-off-by: Patrick Venture
> Reviewed-by: Rob Herring
> ---
> Changes for v8:
> - None
> Changes for v7:
> - Moved node under the syscon node it requires
> Changes for v6:
> - None
> Changes for v5:
> - None
> Changes for v4:
> - None
> Changes for v3:
> - None
> Changes for v2:
> - Added comment about syscon required parameter.
> ---
> .../bindings/misc/aspeed-p2a-ctrl.txt | 48 +++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> new file mode 100644
> index 0..088cc4e3dc54b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> @@ -0,0 +1,48 @@
> +==
> +Device tree bindings for Aspeed AST2400/AST2500 PCI-to-AHB Bridge
> Control Driver
> +==
> +
> +The bridge is available on platforms with the VGA enabled on the
> Aspeed device.
> +In this case, the host has access to a 64KiB window into all of the
> BMC's
> +memory. The BMC can disable this bridge. If the bridge is enabled,
> the host
> +has read access to all the regions of memory, however the host only
> has read
> +and write access depending on a register controlled by the BMC.
> +
> +Required properties:
> +===
> +
> + - compatible: must be one of:
> + - "aspeed,ast2400-p2a-ctrl"
> + - "aspeed,ast2500-p2a-ctrl"
> +
> + - syscon: handle to syscon device node controlling PCI.
The p2a-ctrl node is meant to be a child of the syscon. I noted this in my
review
of the associated driver - you need to remove the description of the syscon
property.
> +
> +Optional properties:
> +===
> +
> +- memory-region: A phandle to a reserved_memory region to be used for
> the PCI
> + to AHB mapping
> +
> +The p2a-control node should be the child of a syscon node with the
> required
> +property:
> +
> +- compatible : Should be one of the following:
> + "aspeed,ast2400-scu", "syscon", "simple-mfd"
> + "aspeed,g4-scu", "syscon", "simple-mfd"
> + "aspeed,ast2500-scu", "syscon", "simple-mfd"
> + "aspeed,g5-scu", "syscon", "simple-mfd"
The note above should go where you've described the syscon property above.
Cheers,
Andrew
> +
> +Example:
> +
> +g4 Example
> +--
> +
> +syscon: scu@1e6e2000 {
> + compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + p2a: p2a-control {
> + compatible = "aspeed,ast2400-p2a-ctrl";
> + memory-region = <&reserved_memory>;
> + };
> +};
> --
> 2.21.0.392.gf8f6787159e-goog
>
>
Re: [PATCH v8 2/2] drivers/misc: Add Aspeed P2A control driver
On Thu, 28 Mar 2019, at 07:52, Patrick Venture wrote: > The ASPEED AST2400, and AST2500 in some configurations include a > PCI-to-AHB MMIO bridge. This bridge allows a server to read and write > in the BMC's physical address space. This feature is especially useful > when using this bridge to send large files to the BMC. > > The host may use this to send down a firmware image by staging data at a > specific memory address, and in a coordinated effort with the BMC's > software stack and kernel, transmit the bytes. > > This driver enables the BMC to unlock the PCI bridge on demand, and > configure it via ioctl to allow the host to write bytes to an agreed > upon location. In the primary use-case, the region to use is known > apriori on the BMC, and the host requests this information. Once this > request is received, the BMC's software stack will enable the bridge and > the region and then using some software flow control (possibly via IPMI > packets), copy the bytes down. Once the process is complete, the BMC > will disable the bridge and unset any region involved. > > The default behavior of this bridge when present is: enabled and all > regions marked read-write. This driver will fix the regions to be > read-only and then disable the bridge entirely. > > The memory regions protected are: > * BMC flash MMIO window > * System flash MMIO windows > * SOC IO (peripheral MMIO) > * DRAM > > The DRAM region itself is all of DRAM and cannot be further specified. > Once the PCI bridge is enabled, the host can read all of DRAM, and if > the DRAM section is write-enabled, then it can write to all of it. > > Signed-off-by: Patrick Venture > --- > Changes for v8: > - Promoted u32 address values to u64 to be compatible with either. > Changes for v7: > - Moved node under the syscon node and changed therefore how it grabs > the phandle for the regmap. > Changes for v6: > - Cleaned up documentation > - Added missing machine-readable copyright lines. > - Fixed over 80 chars instances. > - Changed error from invalid memory-region node to ENODEV. > Changes for v5: > - Fixup missing exit condition and remove extra jump. > Changes for v4: > - Added ioctl for reading back the memory-region configuration. > - Cleaned up some unused variables. > Changes for v3: > - Deleted unused read and write methods. > Changes for v2: > - Dropped unused reads. > - Moved call to disable bridge to before registering device. > - Switch from using regs to using a syscon regmap. <<< IN PROGRESS > - Updated the commit message. <<< TODO > - Updated the bit flipped for SCU180_ENP2A > - Dropped boolean region_specified variable. > - Renamed p2a_ctrl in _probe to misc_ctrl per suggestion. > - Renamed aspeed_p2a_region_search to aspeed_p2a_region_acquire > - Updated commit message. > --- > drivers/misc/Kconfig | 8 + > drivers/misc/Makefile| 1 + > drivers/misc/aspeed-p2a-ctrl.c | 448 +++ > include/uapi/linux/aspeed-p2a-ctrl.h | 62 > 4 files changed, 519 insertions(+) > create mode 100644 drivers/misc/aspeed-p2a-ctrl.c > create mode 100644 include/uapi/linux/aspeed-p2a-ctrl.h > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 42ab8ec92a046..3209ee020b153 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -496,6 +496,14 @@ config VEXPRESS_SYSCFG > bus. System Configuration interface is one of the possible means > of generating transactions on this bus. > > +config ASPEED_P2A_CTRL > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON > + tristate "Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC bridge control" > + help > + Control Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC mappings > through > + ioctl()s, the driver also provides an interface for userspace > mappings to > + a pre-defined region. > + > config ASPEED_LPC_CTRL > depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON > tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control" > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile > index d5b7d3404dc78..c36239573a5ca 100644 > --- a/drivers/misc/Makefile > +++ b/drivers/misc/Makefile > @@ -56,6 +56,7 @@ obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o > obj-$(CONFIG_CXL_BASE) += cxl/ > obj-$(CONFIG_ASPEED_LPC_CTRL)+= aspeed-lpc-ctrl.o > obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o > +obj-$(CONFIG_ASPEED_P2A_CTRL)+= aspeed-p2a-ctrl.o > obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o > obj-$(CONFIG_OCXL) += ocxl/ > obj-y+= cardreader/ > diff --git a/drivers/misc/aspeed-p2a-ctrl.c > b/drivers/misc/aspeed-p2a-ctrl.c > new file mode 100644 > index 0..06afbfe51a279 > --- /dev/null > +++ b/drivers/misc/aspeed-p2a-ctrl.c > @@ -0,0 +1,448 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright 2
[PATCH 0/1] slob: Fix list_head bug during allocation
Hi Andrew,
This patch is in response to an email from the 0day kernel test robot
subject:
340d3d6178 ("mm/slob.c: respect list_head abstraction layer"): kernel BUG at
lib/list_debug.c:31!
This patch applies on top of linux-next tag: next-20190401
It fixes a patch that was merged recently into mm:
The patch titled
Subject: mm/slob.c: respect list_head abstraction layer
has been added to the -mm tree. Its filename is
slob-respect-list_head-abstraction-layer.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/slob-respect-list_head-abstraction-layer.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/slob-respect-list_head-abstraction-layer.patch
If reverting is easier than patching I can re-work this into another
version of the original (buggy) patch set which was the series:
[PATCH 0/4] mm: Use slab_list list_head instead of lru
Please don't be afraid to give a firm response. I'm new to mm and I'd
like to not be a nuisance if I can manage it ;) I'd also like to fix
this in a way that makes your day as easy as possible.
The 0day kernel test robot found a bug in the slob allocator caused by a
patch from me recently merged into the mm tree. This is the first time
the 0day has found a bug in already merged code of mine so I do not know
the exact protocol in regards to linking the fix with the report,
patching, reverting etc.
I was unable to reproduce the crash, I tried building with the config
attached to the email above but the kernel booted fine for me in Qemu.
So I re-worked the module originally used for testing, it can be found
here:
https://github.com/tcharding/ktest/tree/master/list_head
>From this I think the list.h code added prior to the buggy patch is
ok.
Next I tried to find the bug just using my eyes. This patch is the
result. Unfortunately I can not understand why this bug was not
triggered _before_ I originally patched it. Perhaps I'm not juggling
all the state perfectly in my head. Anyways, this patch stops and code
calling list manipulation functions if the slab_list page member has
been modified during allocation.
The code in question revolves around an optimisation aimed at preventing
fragmentation at the start of a slab due to the first fit nature of the
allocation algorithm.
Full explanation is in the commit log for the patch, the short version
is; skip optimisation if page list is modified, this only occurs when an
allocation completely fills the slab and in this case the optimisation
is unnecessary since we have not fragmented the slab by this allocation.
This is more than just a bug fix, it significantly reduces the
complexity of the function while still fixing the reason for originally
touching this code (violation of list_head abstraction).
The only testing I've done is to build and boot a kernel in Qemu (with
CONFIG_LIST_DEBUG and CONFIG_SLOB) enabled). However, as mentioned,
this method of testing did _not_ reproduce the 0day crash so if there
are better suggestions on how I should test these I'm happy to do so.
thanks,
Tobin.
Tobin C. Harding (1):
slob: Only use list functions when safe to do so
mm/slob.c | 50 ++
1 file changed, 30 insertions(+), 20 deletions(-)
--
2.21.0
Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok
On 2019/4/2 上午11:14, Rong Chen wrote:
>
> On 4/1/19 11:40 PM, David Sterba wrote:
>> On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
>>> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
On 2019/4/1 下午10:02, Chen, Rong A wrote:
> On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
>> On 1.04.19 г. 16:24 ч., kernel test robot wrote:
>>> FYI, we noticed the following commit (built with gcc-7):
>>>
>>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
>>> tree-checker: Verify dev item")
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
>>> master
>>>
>>> in testcase: trinity
>>> with following parameters:
>>>
>>> runtime: 300s
>>>
>>> test-description: Trinity is a linux system call fuzz tester.
>>> test-url: http://codemonkey.org.uk/projects/trinity/
>>>
>>>
>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge
>>> -smp
>>> 2 -m 2G
>>>
>>> caused below changes (please refer to attached dmesg/kmsg for entire
>>> log/backtrace):
>>>
>>>
>>> ++++
>>>
>>>
>>> |
>>> | 36b9d2bc69 | 70d28b0e4f |
>>> ++++
>>>
>>>
>>> |
>>> boot_successes
>>> | 14 | 0 |
>>> |
>>> boot_failures
>>> | 2 | 14 |
>>> |
>>> IP-Config:Auto-configuration_of_network_failed
>>> | 2 | |
>>> |
>>> BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
>>>
>>> | 0 | 14 |
>>> ++++
>>>
>>>
>>>
>>>
>>>
>>> early console in setup code
>>> Probing EDD (edd=off to disable)... ok
>>> BUG: kernel reboot-without-warning in early-boot stage, last printk:
>>> Probing EDD (edd=off to disable)... ok
>>> Linux version 5.0.0-rc8-00196-g70d28b0 #1
>>> Command line: ip=vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
>>> user=lkp
>>> job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
>>>
>>> ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
>>> branch=linux-devel/devel-hourly-2019032317
>>> commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
>>> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
>>>
>>> max_uptime=1500
>>> RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
>>>
>>> LKP_SERVER=inn debug apic=debug sysrq_always_enabled
>>> rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
>>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
>>> load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
>>> systemd.log_level=err ignore_loglevel console=tty0
>>> earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
>>> rcuperf.shutdown=0
>>>
>> Can this report be made useful by actually including output from
>> serial
>> console? For example possible bug-ons or whatnot? dmesg.xz just
>> contains
>> qemu's command line + some metadata about the test and :
>>
>> "BUG: kernel reboot-without-warning in early-boot stage, last printk:
>> Probing EDD (edd=off to disable)... ok"
>>
>> At least a stack trace would have been useful.
>>
>>
> Hi,
>
> We usually use the tool ("bin/lkp qemu -k job-script") to
> reproduce it. It seems no stack trace in the result:
So there is no regression at that commit right?
Just some false alert?
>>>
>>> Hi,
>>>
>>> I think there's a regression, it stopped in the early-boot stage .
>> Can you please provide any logs that would point at btrfs? If the module
>> is loaded or built-in started, there's a line about that. Besides that
>> it's preceded by messages from other subsystems' initialization.
>
>
> Hi,
>
> CONFIG_BTRFS_FS and CONFIG_BTRFS_FS_REF_VERIFY is enabled in the kconfig.
> I disabled them for the experiment, and the new kernel is bootable. I
> don't have more logs to prove it.
>
> $ grep BTRFS config-5.0.0-rc8-00196-g70d28b0
> CONFIG_BTRFS_FS=y
> # CONFIG_BTRFS_FS_POSIX_ACL is not set
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
> # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
> # CONFIG_BTRFS_DEBUG is not set
> # CONFIG_BTRFS_ASSERT is not set
> CONFIG_BTRFS_FS_REF_VERIFY=y
That's strange, r
[PATCH 1/1] slob: Only use list functions when safe to do so
Currently we call (indirectly) list_del() then we manually try to combat
the fact that the list may be in an undefined state by getting 'prev'
and 'next' pointers in a somewhat contrived manner. It is hard to
verify that this works for all initial states of the list. Clearly the
author (me) got it wrong the first time because the 0day kernel testing
robot managed to crash the kernel thanks to this code.
All this is done in order to do an optimisation aimed at preventing
fragmentation at the start of a slab. We can just skip this
optimisation any time the list is put into an undefined state since this
only occurs when an allocation completely fills the slab and in this
case the optimisation is unnecessary since we have not fragmented the slab
by this allocation.
Change the page pointer passed to slob_alloc_page() to be a double
pointer so that we can set it to NULL to indicate that the page was
removed from the list. Skip the optimisation if the page was removed.
Found thanks to the kernel test robot, email subject:
340d3d6178 ("mm/slob.c: respect list_head abstraction layer"): kernel
BUG at lib/list_debug.c:31!
Reported-by: kernel test robot
Signed-off-by: Tobin C. Harding
---
mm/slob.c | 50 ++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/mm/slob.c b/mm/slob.c
index 21af3fdb457a..c543da10df45 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -213,10 +213,18 @@ static void slob_free_pages(void *b, int order)
}
/*
- * Allocate a slob block within a given slob_page sp.
+ * slob_page_alloc() - Allocate a slob block within a given slob_page sp.
+ * @spp: Page to look in, return parameter.
+ * @size: Size of the allocation.
+ * @align: Allocation alignment.
+ *
+ * Tries to find a chunk of memory at least @size within page. If the
+ * allocation fills up page then page is removed from list, in this case
+ * *spp will be set to %NULL to signal that list removal occurred.
*/
-static void *slob_page_alloc(struct page *sp, size_t size, int align)
+static void *slob_page_alloc(struct page **spp, size_t size, int align)
{
+ struct page *sp = *spp;
slob_t *prev, *cur, *aligned = NULL;
int delta = 0, units = SLOB_UNITS(size);
@@ -254,8 +262,11 @@ static void *slob_page_alloc(struct page *sp, size_t size,
int align)
}
sp->units -= units;
- if (!sp->units)
+ if (!sp->units) {
clear_slob_page_free(sp);
+ /* Signal that page was removed from list. */
+ *spp = NULL;
+ }
return cur;
}
if (slob_last(cur))
@@ -268,7 +279,7 @@ static void *slob_page_alloc(struct page *sp, size_t size,
int align)
*/
static void *slob_alloc(size_t size, gfp_t gfp, int align, int node)
{
- struct page *sp, *prev, *next;
+ struct page *sp;
struct list_head *slob_list;
slob_t *b = NULL;
unsigned long flags;
@@ -283,6 +294,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int align,
int node)
spin_lock_irqsave(&slob_lock, flags);
/* Iterate through each partially free page, try to find room */
list_for_each_entry(sp, slob_list, slab_list) {
+ struct page **spp = &sp;
#ifdef CONFIG_NUMA
/*
* If there's a node specification, search for a partial
@@ -295,27 +307,25 @@ static void *slob_alloc(size_t size, gfp_t gfp, int
align, int node)
if (sp->units < SLOB_UNITS(size))
continue;
- /*
-* Cache previous entry because slob_page_alloc() may
-* remove sp from slob_list.
-*/
- prev = list_prev_entry(sp, slab_list);
-
/* Attempt to alloc */
- b = slob_page_alloc(sp, size, align);
+ b = slob_page_alloc(spp, size, align);
if (!b)
continue;
- next = list_next_entry(prev, slab_list); /* This may or may not
be sp */
-
/*
-* Improve fragment distribution and reduce our average
-* search time by starting our next search here. (see
-* Knuth vol 1, sec 2.5, pg 449)
+* If slob_page_alloc() removed sp from the list then we
+* cannot call list functions on sp. Just bail, don't
+* worry about the optimisation below.
*/
- if (!list_is_first(&next->slab_list, slob_list))
- list_rotate_to_front(&next->slab_list, slob_list);
-
+ if (*spp) {
+ /*
+* Improve fragment distribution and reduce our average
+* search time by starting our
Re: [mt76] c1e0d2be0a: BUG:pagefault_on_kernel_address#in_non-whitelisted_uaccess
On Tue, Apr 2, 2019 at 5:10 AM kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: c1e0d2be0acff5e99a59ddcc5af415e48abc6c5e ("mt76: mmio: introduce
> mt76x02_check_tx_hang watchdog")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[...]
> [ 10.383586] BUG: pagefault on kernel address 0x93d4b5cd8000 in
> non-whitelisted uaccess
> [ 10.390934] BUG: unable to handle kernel paging request at 93d4b5cd8000
> [ 10.390934] #PF error: [normal kernel read fault]
> [ 10.390934] PGD 21e00067 P4D 21e00067 PUD 21e04067 PMD 78b57067 PTE
> 800f8a327060
> [ 10.390934] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 10.390934] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT
> 5.0.0-rc1-00033-gc1e0d2b #1
> [ 10.390934] RIP: 0010:strncpy_from_user+0x87/0x10c
> [ 10.390934] Code: 00 00 66 66 90 4c 39 c2 48 bb ff fe fe fe fe fe fe fe 49
> ba 80 80 80 80 80 80 80 80 4c 0f 46 c2 31 c0 45 31 db eb 4c 44 89 d9 <4c> 8b
> 0c 06 85 c9 74 05 45 31 d2 eb 61 49 8d 0c 19 4c 89 0c 07 49
> [ 10.390934] RSP: :bd8c00323bc0 EFLAGS: 00010206
> [ 10.390934] RAX: 0028 RBX: fefefefefefefeff RCX:
>
> [ 10.390934] RDX: 0fe0 RSI: 93d4b5cd7fd6 RDI:
> 93d4af5e3020
> [ 10.390934] RBP: ff9c R08: 0fe0 R09:
> 8c93909d92868cd1
> [ 10.390934] R10: 8080808080808080 R11: R12:
> 93d4b5cd7fd6
> [ 10.390934] R13: 93d4b5cd7fd6 R14: R15:
>
> [ 10.390934] FS: () GS:93d4b640()
> knlGS:
> [ 10.390934] CS: 0010 DS: ES: CR0: 80050033
> [ 10.390934] CR2: 93d4b5cd8000 CR3: 20c15000 CR4:
> 06e0
> [ 10.390934] Call Trace:
> [ 10.390934] ? getname_flags+0x6f/0x199
> [ 10.390934] ? user_path_at_empty+0x18/0x2f
> [ 10.390934] ? vfs_statx+0x6d/0xb3
> [ 10.390934] ? clean_path+0x5c/0x102
> [ 10.390934] ? do_name+0xf4/0x40e
> [ 10.390934] ? write_buffer+0x52/0x8a
> [ 10.390934] ? flush_buffer+0xe7/0x140
> [ 10.390934] ? initrd_load+0xa8/0xa8
> [ 10.390934] ? __gunzip+0x53a/0x6b7
> [ 10.390934] ? bunzip2+0x76a/0x76a
> [ 10.390934] ? write_buffer+0x8a/0x8a
> [ 10.390934] ? gunzip+0x39/0x3d
> [ 10.390934] ? initrd_load+0xa8/0xa8
> [ 10.390934] ? unpack_to_rootfs+0x1c6/0x3c6
> [ 10.390934] ? initrd_load+0xa8/0xa8
> [ 10.390934] ? populate_rootfs+0x94/0x213
> [ 10.390934] ? clean_rootfs+0x23b/0x23b
> [ 10.390934] ? do_one_initcall+0x61/0x12a
> [ 10.390934] ? kernel_init_freeable+0x1a8/0x305
> [ 10.390934] ? rest_init+0x13a/0x13a
> [ 10.390934] ? kernel_init+0x5/0xeb
> [ 10.390934] ? ret_from_fork+0x35/0x40
> [ 10.390934] Modules linked in:
> [ 10.390934] CR2: 93d4b5cd8000
> [ 10.390934] ---[ end trace 81b307b1a0dd06e6 ]---
This was dealt with in commit 53a41cb7ed381edee91029cdcabe9b3250f43f4d
('Revert "x86/fault: BUG() when uaccess helpers fault on kernel
addresses"').
