Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
On Sat, Aug 25, 2018 at 10:06:41PM -0700, Andi Kleen wrote: > > > Cc: sta...@vger.kernel.org # 4.4 and 4.9 > > > > LGTM for v4.4.y but ... are you sure that this patch applies to v4.9.y ? > > Commit edc3b9129cec is 'native' in v4.9.y and has not been reverted there. > > You're right. I thought it was needed for 4.9 too, but yes it has the CPA pfn > patch. So for 4.9 the patch is not needed and in fact incorrect. > > The original report was for 4.4. > > Greg can you please revert/remove it again for 4.9? Now dropped, thanks. greg k-h
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
On Sat, Aug 25, 2018 at 10:06:41PM -0700, Andi Kleen wrote: > > > Cc: sta...@vger.kernel.org # 4.4 and 4.9 > > > > LGTM for v4.4.y but ... are you sure that this patch applies to v4.9.y ? > > Commit edc3b9129cec is 'native' in v4.9.y and has not been reverted there. > > You're right. I thought it was needed for 4.9 too, but yes it has the CPA pfn > patch. So for 4.9 the patch is not needed and in fact incorrect. > > The original report was for 4.4. > > Greg can you please revert/remove it again for 4.9? Now dropped, thanks. greg k-h
Re: TLB flushes on fixmap changes
at 9:43 PM, Kees Cook wrote: > On Sat, Aug 25, 2018 at 9:21 PM, Andy Lutomirski wrote: >> On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu >> wrote: >>> On Fri, 24 Aug 2018 21:23:26 -0700 >>> Andy Lutomirski wrote: Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3? >>> >>> No, since kmap_atomic() is only for x86_32 and highmem support kernel. >>> In x86-64, it seems that returns just a page address. That is not >>> good for text_poke, since it needs to make a writable alias for RO >>> code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses >>> ioremap_cache? >> >> I just re-read text_poke(). It's, um, horrible. Not only is the >> implementation overcomplicated and probably buggy, but it's SLOW. >> It's totally the wrong API -- poking one instruction at a time >> basically can't be efficient on x86. The API should either poke lots >> of instructions at once or should be text_poke_begin(); ...; >> text_poke_end();. >> >> Anyway, the attached patch seems to boot. Linus, Kees, etc: is this >> too scary of an approach? With the patch applied, text_poke() is a >> fantastic exploit target. On the other hand, even without the patch >> applied, text_poke() is every bit as juicy. > > I tried to convince Ingo to use this method for doing "write rarely" > and he soundly rejected it. :) I've always liked this because AFAICT, > it's local to the CPU. I had proposed it in > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/write-rarely=9ab0cb2618ebbc51f830ceaa06b7d2182fe1a52d > > With that, text_poke() mostly becomes: > > rare_write_begin() > memcpy(addr, opcode, len); > rare_write_end() > > As for juiciness, if an attacker already has execution control, they > can do more interesting things than text_poke(). But regardless, yes, > it's always made me uncomfortable. :) I think that the key to harden the security of text_poke() against its use as a gadget in a ROP/JOP attack is to add a check/assertion for the old (expected) value, such as: rare_write_begin() if (*addr == prev_opcode) memcpy(addr, opcode, len); rare_write_end()
Re: TLB flushes on fixmap changes
at 9:43 PM, Kees Cook wrote: > On Sat, Aug 25, 2018 at 9:21 PM, Andy Lutomirski wrote: >> On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu >> wrote: >>> On Fri, 24 Aug 2018 21:23:26 -0700 >>> Andy Lutomirski wrote: Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3? >>> >>> No, since kmap_atomic() is only for x86_32 and highmem support kernel. >>> In x86-64, it seems that returns just a page address. That is not >>> good for text_poke, since it needs to make a writable alias for RO >>> code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses >>> ioremap_cache? >> >> I just re-read text_poke(). It's, um, horrible. Not only is the >> implementation overcomplicated and probably buggy, but it's SLOW. >> It's totally the wrong API -- poking one instruction at a time >> basically can't be efficient on x86. The API should either poke lots >> of instructions at once or should be text_poke_begin(); ...; >> text_poke_end();. >> >> Anyway, the attached patch seems to boot. Linus, Kees, etc: is this >> too scary of an approach? With the patch applied, text_poke() is a >> fantastic exploit target. On the other hand, even without the patch >> applied, text_poke() is every bit as juicy. > > I tried to convince Ingo to use this method for doing "write rarely" > and he soundly rejected it. :) I've always liked this because AFAICT, > it's local to the CPU. I had proposed it in > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/write-rarely=9ab0cb2618ebbc51f830ceaa06b7d2182fe1a52d > > With that, text_poke() mostly becomes: > > rare_write_begin() > memcpy(addr, opcode, len); > rare_write_end() > > As for juiciness, if an attacker already has execution control, they > can do more interesting things than text_poke(). But regardless, yes, > it's always made me uncomfortable. :) I think that the key to harden the security of text_poke() against its use as a gadget in a ROP/JOP attack is to add a check/assertion for the old (expected) value, such as: rare_write_begin() if (*addr == prev_opcode) memcpy(addr, opcode, len); rare_write_end()
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
> > Cc: sta...@vger.kernel.org # 4.4 and 4.9 > > LGTM for v4.4.y but ... are you sure that this patch applies to v4.9.y ? > Commit edc3b9129cec is 'native' in v4.9.y and has not been reverted there. You're right. I thought it was needed for 4.9 too, but yes it has the CPA pfn patch. So for 4.9 the patch is not needed and in fact incorrect. The original report was for 4.4. Greg can you please revert/remove it again for 4.9? -Andi
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
> > Cc: sta...@vger.kernel.org # 4.4 and 4.9 > > LGTM for v4.4.y but ... are you sure that this patch applies to v4.9.y ? > Commit edc3b9129cec is 'native' in v4.9.y and has not been reverted there. You're right. I thought it was needed for 4.9 too, but yes it has the CPA pfn patch. So for 4.9 the patch is not needed and in fact incorrect. The original report was for 4.4. Greg can you please revert/remove it again for 4.9? -Andi
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
On Sat, Aug 25, 2018 at 06:50:15AM -0700, Andi Kleen wrote: > From: Andi Kleen > > Patch for stable only to fix boot resets caused by the L1TF patches. > > Stable trees reverted the following patch > > Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" > > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. > > but the L1TF patch backported here > >x86/mm/pat: Make set_memory_np() L1TF safe > > commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream > > set_memory_np() is used to mark kernel mappings not present, but it has > it's own open coded mechanism which does not have the L1TF protection of > inverting the address bits. > > assumed that cpa->pfn contains a PFN. With the above patch reverted > it does not, which causes the PMD to be set to an incorrect address > shifted by 12 bits, which can cause early boot reset on some > systems, like an Apollo Lake embedded system. > > Convert the address to a PFN before passing it to pmd_pfn() > > Thanks to Bernhard for bisecting and testing. > Thanks a lot to you for tracking it down, and sorry for messing it up. > Cc: sta...@vger.kernel.org # 4.4 and 4.9 LGTM for v4.4.y but ... are you sure that this patch applies to v4.9.y ? Commit edc3b9129cec is 'native' in v4.9.y and has not been reverted there. $ git log --oneline v4.4..linux-4.9.y | grep "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" edc3b9129cec x86/mm/pat: Ensure cpa->pfn only contains page frame numbers Guenter > Reported-by: Bernhard Kaindl > Tested-by: Bernhard Kaindl > Signed-off-by: Andi Kleen > --- > arch/x86/mm/pageattr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c > index 27610c2d1821..1007fa80f5a6 100644 > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -1006,7 +1006,7 @@ static int populate_pmd(struct cpa_data *cpa, > > pmd = pmd_offset(pud, start); > > - set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn, > + set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn >> PAGE_SHIFT, > canon_pgprot(pmd_pgprot; > > start += PMD_SIZE;
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
On Sat, Aug 25, 2018 at 06:50:15AM -0700, Andi Kleen wrote: > From: Andi Kleen > > Patch for stable only to fix boot resets caused by the L1TF patches. > > Stable trees reverted the following patch > > Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" > > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. > > but the L1TF patch backported here > >x86/mm/pat: Make set_memory_np() L1TF safe > > commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream > > set_memory_np() is used to mark kernel mappings not present, but it has > it's own open coded mechanism which does not have the L1TF protection of > inverting the address bits. > > assumed that cpa->pfn contains a PFN. With the above patch reverted > it does not, which causes the PMD to be set to an incorrect address > shifted by 12 bits, which can cause early boot reset on some > systems, like an Apollo Lake embedded system. > > Convert the address to a PFN before passing it to pmd_pfn() > > Thanks to Bernhard for bisecting and testing. > Thanks a lot to you for tracking it down, and sorry for messing it up. > Cc: sta...@vger.kernel.org # 4.4 and 4.9 LGTM for v4.4.y but ... are you sure that this patch applies to v4.9.y ? Commit edc3b9129cec is 'native' in v4.9.y and has not been reverted there. $ git log --oneline v4.4..linux-4.9.y | grep "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" edc3b9129cec x86/mm/pat: Ensure cpa->pfn only contains page frame numbers Guenter > Reported-by: Bernhard Kaindl > Tested-by: Bernhard Kaindl > Signed-off-by: Andi Kleen > --- > arch/x86/mm/pageattr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c > index 27610c2d1821..1007fa80f5a6 100644 > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -1006,7 +1006,7 @@ static int populate_pmd(struct cpa_data *cpa, > > pmd = pmd_offset(pud, start); > > - set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn, > + set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn >> PAGE_SHIFT, > canon_pgprot(pmd_pgprot; > > start += PMD_SIZE;
Re: TLB flushes on fixmap changes
On Sat, Aug 25, 2018 at 9:21 PM, Andy Lutomirski wrote: > On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu wrote: >> On Fri, 24 Aug 2018 21:23:26 -0700 >> Andy Lutomirski wrote: >>> Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3? >> >> No, since kmap_atomic() is only for x86_32 and highmem support kernel. >> In x86-64, it seems that returns just a page address. That is not >> good for text_poke, since it needs to make a writable alias for RO >> code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses >> ioremap_cache? >> > > I just re-read text_poke(). It's, um, horrible. Not only is the > implementation overcomplicated and probably buggy, but it's SLOW. > It's totally the wrong API -- poking one instruction at a time > basically can't be efficient on x86. The API should either poke lots > of instructions at once or should be text_poke_begin(); ...; > text_poke_end();. > > Anyway, the attached patch seems to boot. Linus, Kees, etc: is this > too scary of an approach? With the patch applied, text_poke() is a > fantastic exploit target. On the other hand, even without the patch > applied, text_poke() is every bit as juicy. I tried to convince Ingo to use this method for doing "write rarely" and he soundly rejected it. :) I've always liked this because AFAICT, it's local to the CPU. I had proposed it in https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/write-rarely=9ab0cb2618ebbc51f830ceaa06b7d2182fe1a52d With that, text_poke() mostly becomes: rare_write_begin() memcpy(addr, opcode, len); rare_write_end() As for juiciness, if an attacker already has execution control, they can do more interesting things than text_poke(). But regardless, yes, it's always made me uncomfortable. :) -Kees -- Kees Cook Pixel Security
Re: TLB flushes on fixmap changes
On Sat, Aug 25, 2018 at 9:21 PM, Andy Lutomirski wrote: > On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu wrote: >> On Fri, 24 Aug 2018 21:23:26 -0700 >> Andy Lutomirski wrote: >>> Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3? >> >> No, since kmap_atomic() is only for x86_32 and highmem support kernel. >> In x86-64, it seems that returns just a page address. That is not >> good for text_poke, since it needs to make a writable alias for RO >> code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses >> ioremap_cache? >> > > I just re-read text_poke(). It's, um, horrible. Not only is the > implementation overcomplicated and probably buggy, but it's SLOW. > It's totally the wrong API -- poking one instruction at a time > basically can't be efficient on x86. The API should either poke lots > of instructions at once or should be text_poke_begin(); ...; > text_poke_end();. > > Anyway, the attached patch seems to boot. Linus, Kees, etc: is this > too scary of an approach? With the patch applied, text_poke() is a > fantastic exploit target. On the other hand, even without the patch > applied, text_poke() is every bit as juicy. I tried to convince Ingo to use this method for doing "write rarely" and he soundly rejected it. :) I've always liked this because AFAICT, it's local to the CPU. I had proposed it in https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/write-rarely=9ab0cb2618ebbc51f830ceaa06b7d2182fe1a52d With that, text_poke() mostly becomes: rare_write_begin() memcpy(addr, opcode, len); rare_write_end() As for juiciness, if an attacker already has execution control, they can do more interesting things than text_poke(). But regardless, yes, it's always made me uncomfortable. :) -Kees -- Kees Cook Pixel Security
Re: TLB flushes on fixmap changes
On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu wrote:
> On Fri, 24 Aug 2018 21:23:26 -0700
> Andy Lutomirski wrote:
>> Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3?
>
> No, since kmap_atomic() is only for x86_32 and highmem support kernel.
> In x86-64, it seems that returns just a page address. That is not
> good for text_poke, since it needs to make a writable alias for RO
> code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses ioremap_cache?
>
I just re-read text_poke(). It's, um, horrible. Not only is the
implementation overcomplicated and probably buggy, but it's SLOW.
It's totally the wrong API -- poking one instruction at a time
basically can't be efficient on x86. The API should either poke lots
of instructions at once or should be text_poke_begin(); ...;
text_poke_end();.
Anyway, the attached patch seems to boot. Linus, Kees, etc: is this
too scary of an approach? With the patch applied, text_poke() is a
fantastic exploit target. On the other hand, even without the patch
applied, text_poke() is every bit as juicy.
--Andy
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 014f214da581..811c8735b129 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -690,40 +690,15 @@ void *__init_or_module text_poke_early(void *addr, const void *opcode,
void *text_poke(void *addr, const void *opcode, size_t len)
{
unsigned long flags;
- char *vaddr;
- struct page *pages[2];
- int i;
-
- /*
- * While boot memory allocator is runnig we cannot use struct
- * pages as they are not yet initialized.
- */
- BUG_ON(!after_bootmem);
+ unsigned long old_cr0;
- if (!core_kernel_text((unsigned long)addr)) {
- pages[0] = vmalloc_to_page(addr);
- pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
- } else {
- pages[0] = virt_to_page(addr);
- WARN_ON(!PageReserved(pages[0]));
- pages[1] = virt_to_page(addr + PAGE_SIZE);
- }
- BUG_ON(!pages[0]);
local_irq_save(flags);
- set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
- if (pages[1])
- set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
- vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
- memcpy([(unsigned long)addr & ~PAGE_MASK], opcode, len);
- clear_fixmap(FIX_TEXT_POKE0);
- if (pages[1])
- clear_fixmap(FIX_TEXT_POKE1);
- local_flush_tlb();
- sync_core();
- /* Could also do a CLFLUSH here to speed up CPU recovery; but
- that causes hangs on some VIA CPUs. */
- for (i = 0; i < len; i++)
- BUG_ON(((char *)addr)[i] != ((char *)opcode)[i]);
+ old_cr0 = read_cr0();
+ write_cr0(old_cr0 & ~X86_CR0_WP);
+
+ memcpy(addr, opcode, len);
+
+ write_cr0(old_cr0); /* also serializes */
local_irq_restore(flags);
return addr;
}
Re: TLB flushes on fixmap changes
On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu wrote:
> On Fri, 24 Aug 2018 21:23:26 -0700
> Andy Lutomirski wrote:
>> Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3?
>
> No, since kmap_atomic() is only for x86_32 and highmem support kernel.
> In x86-64, it seems that returns just a page address. That is not
> good for text_poke, since it needs to make a writable alias for RO
> code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses ioremap_cache?
>
I just re-read text_poke(). It's, um, horrible. Not only is the
implementation overcomplicated and probably buggy, but it's SLOW.
It's totally the wrong API -- poking one instruction at a time
basically can't be efficient on x86. The API should either poke lots
of instructions at once or should be text_poke_begin(); ...;
text_poke_end();.
Anyway, the attached patch seems to boot. Linus, Kees, etc: is this
too scary of an approach? With the patch applied, text_poke() is a
fantastic exploit target. On the other hand, even without the patch
applied, text_poke() is every bit as juicy.
--Andy
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 014f214da581..811c8735b129 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -690,40 +690,15 @@ void *__init_or_module text_poke_early(void *addr, const void *opcode,
void *text_poke(void *addr, const void *opcode, size_t len)
{
unsigned long flags;
- char *vaddr;
- struct page *pages[2];
- int i;
-
- /*
- * While boot memory allocator is runnig we cannot use struct
- * pages as they are not yet initialized.
- */
- BUG_ON(!after_bootmem);
+ unsigned long old_cr0;
- if (!core_kernel_text((unsigned long)addr)) {
- pages[0] = vmalloc_to_page(addr);
- pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
- } else {
- pages[0] = virt_to_page(addr);
- WARN_ON(!PageReserved(pages[0]));
- pages[1] = virt_to_page(addr + PAGE_SIZE);
- }
- BUG_ON(!pages[0]);
local_irq_save(flags);
- set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
- if (pages[1])
- set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
- vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
- memcpy([(unsigned long)addr & ~PAGE_MASK], opcode, len);
- clear_fixmap(FIX_TEXT_POKE0);
- if (pages[1])
- clear_fixmap(FIX_TEXT_POKE1);
- local_flush_tlb();
- sync_core();
- /* Could also do a CLFLUSH here to speed up CPU recovery; but
- that causes hangs on some VIA CPUs. */
- for (i = 0; i < len; i++)
- BUG_ON(((char *)addr)[i] != ((char *)opcode)[i]);
+ old_cr0 = read_cr0();
+ write_cr0(old_cr0 & ~X86_CR0_WP);
+
+ memcpy(addr, opcode, len);
+
+ write_cr0(old_cr0); /* also serializes */
local_irq_restore(flags);
return addr;
}
Re: PAYMENT From RBS/COUTTS
Royal Bank of Scotland Address: Ealing Broadway Shopping Centre, 14 High St, Ealing, London W5 5EB, , United Kingdom Our Ref: RBS/COUTTS/INT/UK/08/18 Beneficiary, Please be informed that we have discovered a floating payment in your name but surprisingly with a Power of Attorney in your file authorizing the transfer of this fund to a Cayman Island bank account. We have contacted you because we needed to verify this from you to ascertain if you have actually authorized the transfer of this fund into the bank account below of Matthew Creagh who claimed to be your partner. Bank name:BFC International Bank Bank Address:Georgetown, Cayman Islands Bank FAX: 1-866-328-3507 Account number: 1087564120 Swift number: 487654 Account name:Matthew Creagh If you have not authorized your fund transferred to the above stated bank account, please contact us immediately, we expect your response within the next 24 to 48 hour. Your full details below are also required. (1)Your Full Name And Address:.. . (2) Your Age And Marital Status:... .. (3) Your Occupation:... .. (4) Your Telephone Number:... (5)Your Nationality:.. . (6) Your Bank Details... . The account details were the fund will be re-directed to, if you have not authorized the transfer, also indicate if you can can come down in person for direct cash payment. Sincerely yours, Douglas McDougall Head of Department E-wire Department
Re: PAYMENT From RBS/COUTTS
Royal Bank of Scotland Address: Ealing Broadway Shopping Centre, 14 High St, Ealing, London W5 5EB, , United Kingdom Our Ref: RBS/COUTTS/INT/UK/08/18 Beneficiary, Please be informed that we have discovered a floating payment in your name but surprisingly with a Power of Attorney in your file authorizing the transfer of this fund to a Cayman Island bank account. We have contacted you because we needed to verify this from you to ascertain if you have actually authorized the transfer of this fund into the bank account below of Matthew Creagh who claimed to be your partner. Bank name:BFC International Bank Bank Address:Georgetown, Cayman Islands Bank FAX: 1-866-328-3507 Account number: 1087564120 Swift number: 487654 Account name:Matthew Creagh If you have not authorized your fund transferred to the above stated bank account, please contact us immediately, we expect your response within the next 24 to 48 hour. Your full details below are also required. (1)Your Full Name And Address:.. . (2) Your Age And Marital Status:... .. (3) Your Occupation:... .. (4) Your Telephone Number:... (5)Your Nationality:.. . (6) Your Bank Details... . The account details were the fund will be re-directed to, if you have not authorized the transfer, also indicate if you can can come down in person for direct cash payment. Sincerely yours, Douglas McDougall Head of Department E-wire Department
Re: TLB flushes on fixmap changes
On Fri, 24 Aug 2018 21:23:26 -0700 Andy Lutomirski wrote: > On Fri, Aug 24, 2018 at 7:29 PM, wrote: > > > > > > On August 24, 2018 5:58:43 PM PDT, Linus Torvalds > > wrote: > >>Adding a few people to the cc. > >> > >>On Fri, Aug 24, 2018 at 1:24 PM Nadav Amit > >>wrote: > >>> > > >>> > Can you actually find something that changes the fixmaps after boot > >>> > (again, ignoring kmap)? > >>> > >>> At least the alternatives mechanism appears to do so. > >>> > >>> IIUC the following path is possible when adding a module: > >>> > >>> jump_label_add_module() > >>> ->__jump_label_update() > >>> ->arch_jump_label_transform() > >>> ->__jump_label_transform() > >>> ->text_poke_bp() > >>> ->text_poke() > >>> ->set_fixmap() > >> > >>Yeah, that looks a bit iffy. > >> > >>But making the tlb flush global wouldn't help. This is running on a > >>local core, and if there are other CPU's that can do this at the same > >>time, then they'd just fight about the same mapping. > >> > >>Honestly, I think it's ok just because I *hope* this is all serialized > >>anyway (jump_label_lock? But what about other users of text_poke?). > > > > The users should hold text_mutex. > > > >> > >>But I'd be a lot happier about it if it either used an explicit lock > >>to make sure, or used per-cpu fixmap entries. > > > > My concern is that despite the lock, one core would do a speculative page > > walk and cache a translation that soon after would become stale. > > > >> > >>And the tlb flush is done *after* the address is used, which is bogus > >>anyway. > > > > It seems to me that it is intended to remove the mapping that might be a > > security issue. > > > > But anyhow, set_fixmap and clear_fixmap perform a local TLB flush, (in > > __set_pte_vaddr()) so locally things should be fine. > > > >> > >>> And a similar path can happen when static_key_enable/disable() is > >>called. > >> > >>Same comments. > >> > >>How about replacing that > >> > >>local_irq_save(flags); > >> ... do critical things here ... > >>local_irq_restore(flags); > >> > >>in text_poke() with > >> > >>static DEFINE_SPINLOCK(poke_lock); > >> > >>spin_lock_irqsave(_lock, flags); > >> ... do critical things here ... > >>spin_unlock_irqrestore(_lock, flags); > >> > >>and moving the local_flush_tlb() to after the set_fixmaps, but before > >>the access through the virtual address. > >> > >>But changing things to do a global tlb flush would just be wrong. > > > > As I noted, I think that locking and local flushes as they are right now > > are fine (besides the redundant flush). > > > > My concern is merely that speculative page walks on other cores would cache > > stale entries. > > > > > > This is almost certainly a bug, or even two bugs. Bug 1: why on > Earth do we flush in __set_pte_vaddr()? We should flush when > *clearing* or when modifying an existing fixmap entry. Right now, if > we do text_poke() after boot, then the TLB entry will stick around and > will be a nice exploit target. > > Bug 2: what you're describing. It's racy. > > Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3? No, since kmap_atomic() is only for x86_32 and highmem support kernel. In x86-64, it seems that returns just a page address. That is not good for text_poke, since it needs to make a writable alias for RO code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses ioremap_cache? Thank you, -- Masami Hiramatsu
Re: TLB flushes on fixmap changes
On Fri, 24 Aug 2018 21:23:26 -0700 Andy Lutomirski wrote: > On Fri, Aug 24, 2018 at 7:29 PM, wrote: > > > > > > On August 24, 2018 5:58:43 PM PDT, Linus Torvalds > > wrote: > >>Adding a few people to the cc. > >> > >>On Fri, Aug 24, 2018 at 1:24 PM Nadav Amit > >>wrote: > >>> > > >>> > Can you actually find something that changes the fixmaps after boot > >>> > (again, ignoring kmap)? > >>> > >>> At least the alternatives mechanism appears to do so. > >>> > >>> IIUC the following path is possible when adding a module: > >>> > >>> jump_label_add_module() > >>> ->__jump_label_update() > >>> ->arch_jump_label_transform() > >>> ->__jump_label_transform() > >>> ->text_poke_bp() > >>> ->text_poke() > >>> ->set_fixmap() > >> > >>Yeah, that looks a bit iffy. > >> > >>But making the tlb flush global wouldn't help. This is running on a > >>local core, and if there are other CPU's that can do this at the same > >>time, then they'd just fight about the same mapping. > >> > >>Honestly, I think it's ok just because I *hope* this is all serialized > >>anyway (jump_label_lock? But what about other users of text_poke?). > > > > The users should hold text_mutex. > > > >> > >>But I'd be a lot happier about it if it either used an explicit lock > >>to make sure, or used per-cpu fixmap entries. > > > > My concern is that despite the lock, one core would do a speculative page > > walk and cache a translation that soon after would become stale. > > > >> > >>And the tlb flush is done *after* the address is used, which is bogus > >>anyway. > > > > It seems to me that it is intended to remove the mapping that might be a > > security issue. > > > > But anyhow, set_fixmap and clear_fixmap perform a local TLB flush, (in > > __set_pte_vaddr()) so locally things should be fine. > > > >> > >>> And a similar path can happen when static_key_enable/disable() is > >>called. > >> > >>Same comments. > >> > >>How about replacing that > >> > >>local_irq_save(flags); > >> ... do critical things here ... > >>local_irq_restore(flags); > >> > >>in text_poke() with > >> > >>static DEFINE_SPINLOCK(poke_lock); > >> > >>spin_lock_irqsave(_lock, flags); > >> ... do critical things here ... > >>spin_unlock_irqrestore(_lock, flags); > >> > >>and moving the local_flush_tlb() to after the set_fixmaps, but before > >>the access through the virtual address. > >> > >>But changing things to do a global tlb flush would just be wrong. > > > > As I noted, I think that locking and local flushes as they are right now > > are fine (besides the redundant flush). > > > > My concern is merely that speculative page walks on other cores would cache > > stale entries. > > > > > > This is almost certainly a bug, or even two bugs. Bug 1: why on > Earth do we flush in __set_pte_vaddr()? We should flush when > *clearing* or when modifying an existing fixmap entry. Right now, if > we do text_poke() after boot, then the TLB entry will stick around and > will be a nice exploit target. > > Bug 2: what you're describing. It's racy. > > Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3? No, since kmap_atomic() is only for x86_32 and highmem support kernel. In x86-64, it seems that returns just a page address. That is not good for text_poke, since it needs to make a writable alias for RO code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses ioremap_cache? Thank you, -- Masami Hiramatsu
Re: [PATCH v1] tools/vm/slabinfo.c: fix sign-compare warning
On Fri, Aug 24, 2018 at 06:32:14PM +0900, Naoya Horiguchi wrote: > - int hwcache_align, object_size, objs_per_slab; > - int sanity_checks, slab_size, store_user, trace; > + int hwcache_align, objs_per_slab; > + int sanity_checks, store_user, trace; > int order, poison, reclaim_account, red_zone; > + unsigned int object_size, slab_size; Surely hwcache_align and objs_per_slab can't be negative either? Nor the other three. So maybe convert all seven of these variables to unsigned int?
Re: [PATCH v1] tools/vm/slabinfo.c: fix sign-compare warning
On Fri, Aug 24, 2018 at 06:32:14PM +0900, Naoya Horiguchi wrote: > - int hwcache_align, object_size, objs_per_slab; > - int sanity_checks, slab_size, store_user, trace; > + int hwcache_align, objs_per_slab; > + int sanity_checks, store_user, trace; > int order, poison, reclaim_account, red_zone; > + unsigned int object_size, slab_size; Surely hwcache_align and objs_per_slab can't be negative either? Nor the other three. So maybe convert all seven of these variables to unsigned int?
Re: [PATCH] drivers: qcom: rpmh: avoid sending sleep/wake sets immediately
On Sat, Aug 25 2018 at 13:34 -0600, Raju P.L.S.S.S.N wrote:
Fix the redundant call being made to send the sleep and wake requests
immediately to the controller.
As per the patch[1], the sleep and wake request votes are cached in rpmh
controller and sent during rpmh_flush(). These requests needs to be sent
only during entry of deeper system low power modes or suspend.
[1]https://patchwork.kernel.org/patch/10477533/
Signed-off-by: Raju P.L.S.S.S.N
Reviewed-by: Lina Iyer
---
drivers/soc/qcom/rpmh.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
index f81488b..390e779 100644
--- a/drivers/soc/qcom/rpmh.c
+++ b/drivers/soc/qcom/rpmh.c
@@ -237,9 +237,8 @@ static int __rpmh_write(const struct device *dev, enum
rpmh_state state,
WARN_ON(irqs_disabled());
ret = rpmh_rsc_send_data(ctrlr_to_drv(ctrlr), _msg->msg);
} else {
- ret = rpmh_rsc_write_ctrl_data(ctrlr_to_drv(ctrlr),
- _msg->msg);
/* Clean up our call by spoofing tx_done */
+ ret = 0;
rpmh_tx_done(_msg->msg, ret);
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
the Code Aurora Forum, hosted by The Linux Foundation.
Re: [PATCH] drivers: qcom: rpmh: avoid sending sleep/wake sets immediately
On Sat, Aug 25 2018 at 13:34 -0600, Raju P.L.S.S.S.N wrote:
Fix the redundant call being made to send the sleep and wake requests
immediately to the controller.
As per the patch[1], the sleep and wake request votes are cached in rpmh
controller and sent during rpmh_flush(). These requests needs to be sent
only during entry of deeper system low power modes or suspend.
[1]https://patchwork.kernel.org/patch/10477533/
Signed-off-by: Raju P.L.S.S.S.N
Reviewed-by: Lina Iyer
---
drivers/soc/qcom/rpmh.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
index f81488b..390e779 100644
--- a/drivers/soc/qcom/rpmh.c
+++ b/drivers/soc/qcom/rpmh.c
@@ -237,9 +237,8 @@ static int __rpmh_write(const struct device *dev, enum
rpmh_state state,
WARN_ON(irqs_disabled());
ret = rpmh_rsc_send_data(ctrlr_to_drv(ctrlr), _msg->msg);
} else {
- ret = rpmh_rsc_write_ctrl_data(ctrlr_to_drv(ctrlr),
- _msg->msg);
/* Clean up our call by spoofing tx_done */
+ ret = 0;
rpmh_tx_done(_msg->msg, ret);
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
the Code Aurora Forum, hosted by The Linux Foundation.
Re: Disabling CPU vulnerabilities workarounds
On 08/25/2018 06:39 PM, Casey Schaufler wrote:
On 8/25/2018 3:42 AM, Artem S. Tashkinov wrote:
Hello LKML,
As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are
added to the Linux kernel without a simple way to disable them all in one fell
swoop.
Many of the mitigations are unrelated to each other. There is no one
aspect of the system that identifies a behavior as a security issue.
I don't know anyone who could create a list of all the "fixes" that
have gone in over the years. Realize that features like speculative
execution have had security issues that are unrelated to obscure attacks
like side-channels. While you may think that you don't care, some of
those flaws affect correctness. My bet is you wouldn't want to disable
those.
As far as I know mitigations started to appear in January 2018 and
kernels released prior to this date all work just fine without any
issues with "correctness", so I'm not sure what you're talking about.
I'm quite sure at least Intel perfectly knows, as well as Linus Torvalds
who coordinates everything.
Also
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f73fa6f6d85e..e6362717c895 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -991,7 +991,7 @@ static void __init cpu_set_bug_bits(struct
cpuinfo_x86 *c)
{
u64 ia32_cap = 0;
- if (x86_match_cpu(cpu_no_speculation))
+ //if (x86_match_cpu(cpu_no_speculation))
return;
setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
and setting this in .config:
CONFIG_RETPOLINE=n
CONFIG_PAGE_TABLE_ISOLATION=n
Ostensibly disables all mitigations and everything continues to work
just fine.
Disabling is a good option for strictly confined environments where no 3d party
untrusted code is ever to be run, e.g. a rendering farm, a supercomputer, or
even a home server which runs Samba/SSH server and nothing else.
Like maybe the software in centrifuges in a nuclear fuel processing plant?
All the examples you've cited are network connected and are vulnerable to
attack.
And don't try the "no untrusted code" argument. You'll have code on those
systems
that has been known vulnerable for decades.
I'm not sure
1) why you're trying to mix unrelated classes of vulnerabilities - of
course there are vulnerabilities other than the ones caused by
speculative execution;
2) why you're insisting that my argument, that someone may never run
untrusted code, has no merit. I may perfectly have a standard Linux
distro installed on my PC/server and never run a web browser or any
similar applications other than the ones provided by my distro in a form
of various packages - which means I will never run any untrusted code. I
will also never run any scriptable applications
(bash/python/php/ruby/etc) from the net either. How such a configuration
might be susceptible to speculative execution attacks?
I wonder if someone could wrote a patch which implemented the following two
options for the kernel:
* A boot option option which allows to disable most runtime protections/workarounds/fixes (as far
as I understand some of them can't be reverted since they are compiled in or use certain GCC
flags), e.g. let's call it "insecure" or "insecurecpumode".
That would be an interesting exercise for the opposite case. A boot option
that enables all the runtime protections would certainly be interesting to
some people. If you could implement one, you could do the other.
I would be happy to review such a patch. Go for it.
I'd love to leave that task to those who are more proficient in writing
kernel code and whose work is more likely to be merged. My patch might
be never streamlined for totally unrelated reasons (and we've seen too
many examples of that already).
* A compile-time CONFIG_ option which disables all these fixes _permanently_
without a way to turn them later back on during runtime.
This suffers from all the challenges previously mentioned, but would
be equally interesting, again for the opposite case.
Again, I see no challenges since, for instance, RHEL has gone as far as
to backport all the patches to previously released officially
unmaintained kernels, so all these patches could be easily disabled if
one really wanted to.
Right now linux/Documentation/admin-guide/kernel-parameters.txt is a mess of
various things which take ages to sift through and there's zero understanding
whether you've found everything and correctly disabled it.
I can't argue with you on that. Again, I believe the greater value would
come from documenting how to turn everything on.
I guess you meant "turn everything off".
Best regards,
Artem
Re: Disabling CPU vulnerabilities workarounds
On 08/25/2018 06:39 PM, Casey Schaufler wrote:
On 8/25/2018 3:42 AM, Artem S. Tashkinov wrote:
Hello LKML,
As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are
added to the Linux kernel without a simple way to disable them all in one fell
swoop.
Many of the mitigations are unrelated to each other. There is no one
aspect of the system that identifies a behavior as a security issue.
I don't know anyone who could create a list of all the "fixes" that
have gone in over the years. Realize that features like speculative
execution have had security issues that are unrelated to obscure attacks
like side-channels. While you may think that you don't care, some of
those flaws affect correctness. My bet is you wouldn't want to disable
those.
As far as I know mitigations started to appear in January 2018 and
kernels released prior to this date all work just fine without any
issues with "correctness", so I'm not sure what you're talking about.
I'm quite sure at least Intel perfectly knows, as well as Linus Torvalds
who coordinates everything.
Also
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f73fa6f6d85e..e6362717c895 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -991,7 +991,7 @@ static void __init cpu_set_bug_bits(struct
cpuinfo_x86 *c)
{
u64 ia32_cap = 0;
- if (x86_match_cpu(cpu_no_speculation))
+ //if (x86_match_cpu(cpu_no_speculation))
return;
setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
and setting this in .config:
CONFIG_RETPOLINE=n
CONFIG_PAGE_TABLE_ISOLATION=n
Ostensibly disables all mitigations and everything continues to work
just fine.
Disabling is a good option for strictly confined environments where no 3d party
untrusted code is ever to be run, e.g. a rendering farm, a supercomputer, or
even a home server which runs Samba/SSH server and nothing else.
Like maybe the software in centrifuges in a nuclear fuel processing plant?
All the examples you've cited are network connected and are vulnerable to
attack.
And don't try the "no untrusted code" argument. You'll have code on those
systems
that has been known vulnerable for decades.
I'm not sure
1) why you're trying to mix unrelated classes of vulnerabilities - of
course there are vulnerabilities other than the ones caused by
speculative execution;
2) why you're insisting that my argument, that someone may never run
untrusted code, has no merit. I may perfectly have a standard Linux
distro installed on my PC/server and never run a web browser or any
similar applications other than the ones provided by my distro in a form
of various packages - which means I will never run any untrusted code. I
will also never run any scriptable applications
(bash/python/php/ruby/etc) from the net either. How such a configuration
might be susceptible to speculative execution attacks?
I wonder if someone could wrote a patch which implemented the following two
options for the kernel:
* A boot option option which allows to disable most runtime protections/workarounds/fixes (as far
as I understand some of them can't be reverted since they are compiled in or use certain GCC
flags), e.g. let's call it "insecure" or "insecurecpumode".
That would be an interesting exercise for the opposite case. A boot option
that enables all the runtime protections would certainly be interesting to
some people. If you could implement one, you could do the other.
I would be happy to review such a patch. Go for it.
I'd love to leave that task to those who are more proficient in writing
kernel code and whose work is more likely to be merged. My patch might
be never streamlined for totally unrelated reasons (and we've seen too
many examples of that already).
* A compile-time CONFIG_ option which disables all these fixes _permanently_
without a way to turn them later back on during runtime.
This suffers from all the challenges previously mentioned, but would
be equally interesting, again for the opposite case.
Again, I see no challenges since, for instance, RHEL has gone as far as
to backport all the patches to previously released officially
unmaintained kernels, so all these patches could be easily disabled if
one really wanted to.
Right now linux/Documentation/admin-guide/kernel-parameters.txt is a mess of
various things which take ages to sift through and there's zero understanding
whether you've found everything and correctly disabled it.
I can't argue with you on that. Again, I believe the greater value would
come from documenting how to turn everything on.
I guess you meant "turn everything off".
Best regards,
Artem
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_1650' declared with attribute error: BUILD_BUG_ON failed: plen_reg(nfp_prog) != reg_b(STATIC_REG_PKT_LEN)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b326272010b6656210193d7ab93fa184087e8ee1 commit: 0c26159352ba1cdc5a8c8d74131cc19cdfdf9371 nfp: bpf: xdp_adjust_tail support date: 3 weeks ago config: i386-randconfig-b0-08260429 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout 0c26159352ba1cdc5a8c8d74131cc19cdfdf9371 # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shr_imm64 Cyclomatic Complexity 4 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__shl_imm64 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shl_imm64 Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shl_imm Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_outro_tc_da Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_outro_xdp Cyclomatic Complexity 4 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_outro Cyclomatic Complexity 50 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__emit_br_bit Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:emit_br_bit_relo Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:emit_br_bset Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:ashr_reg64 Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shr_reg64 Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shl_reg64 Cyclomatic Complexity 7 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_jmp_code_get Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:cmp_reg Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:cmp_imm Cyclomatic Complexity 23 drivers/net/ethernet/netronome/nfp/bpf/../nfp_asm.h:__enc_swreg_lm Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:adjust_head Cyclomatic Complexity 22 drivers/net/ethernet/netronome/nfp/bpf/jit.c:wrp_lmem_store Cyclomatic Complexity 5 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_ldx_xdp Cyclomatic Complexity 7 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_ldx_skb Cyclomatic Complexity 20 drivers/net/ethernet/netronome/nfp/bpf/jit.c:wrp_lmem_load Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_queue_select Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx_xdp Cyclomatic Complexity 5 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ld Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:construct_data_ind_ld Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ind_ld1 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ind_ld2 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ind_ld4 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_intro Cyclomatic Complexity 4 drivers/net/ethernet/netronome/nfp/bpf/jit.c:adjust_tail Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:wrp_immed_relo Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_perf_event_output Cyclomatic Complexity 43 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__emit_lcsr Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:emit_csr_wr Cyclomatic Complexity 7 drivers/net/ethernet/netronome/nfp/bpf/jit.c:map_call_stack_common Cyclomatic Complexity 11 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_op_stack Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx_stack Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_ldx_stack Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__emit_csr_rd Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_get_prandom_u32 Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:call Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:re_load_imm_any Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx_data Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx8 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx1 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx2 Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx4 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_st_data Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_st Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_st8 Cyclomatic
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_1650' declared with attribute error: BUILD_BUG_ON failed: plen_reg(nfp_prog) != reg_b(STATIC_REG_PKT_LEN)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b326272010b6656210193d7ab93fa184087e8ee1 commit: 0c26159352ba1cdc5a8c8d74131cc19cdfdf9371 nfp: bpf: xdp_adjust_tail support date: 3 weeks ago config: i386-randconfig-b0-08260429 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout 0c26159352ba1cdc5a8c8d74131cc19cdfdf9371 # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shr_imm64 Cyclomatic Complexity 4 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__shl_imm64 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shl_imm64 Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shl_imm Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_outro_tc_da Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_outro_xdp Cyclomatic Complexity 4 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_outro Cyclomatic Complexity 50 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__emit_br_bit Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:emit_br_bit_relo Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:emit_br_bset Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:ashr_reg64 Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shr_reg64 Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:shl_reg64 Cyclomatic Complexity 7 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_jmp_code_get Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:cmp_reg Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:cmp_imm Cyclomatic Complexity 23 drivers/net/ethernet/netronome/nfp/bpf/../nfp_asm.h:__enc_swreg_lm Cyclomatic Complexity 6 drivers/net/ethernet/netronome/nfp/bpf/jit.c:adjust_head Cyclomatic Complexity 22 drivers/net/ethernet/netronome/nfp/bpf/jit.c:wrp_lmem_store Cyclomatic Complexity 5 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_ldx_xdp Cyclomatic Complexity 7 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_ldx_skb Cyclomatic Complexity 20 drivers/net/ethernet/netronome/nfp/bpf/jit.c:wrp_lmem_load Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_queue_select Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx_xdp Cyclomatic Complexity 5 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ld Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:construct_data_ind_ld Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ind_ld1 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ind_ld2 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:data_ind_ld4 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_intro Cyclomatic Complexity 4 drivers/net/ethernet/netronome/nfp/bpf/jit.c:adjust_tail Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:wrp_immed_relo Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_perf_event_output Cyclomatic Complexity 43 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__emit_lcsr Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:emit_csr_wr Cyclomatic Complexity 7 drivers/net/ethernet/netronome/nfp/bpf/jit.c:map_call_stack_common Cyclomatic Complexity 11 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_op_stack Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx_stack Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_ldx_stack Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:__emit_csr_rd Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:nfp_get_prandom_u32 Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:call Cyclomatic Complexity 9 drivers/net/ethernet/netronome/nfp/bpf/jit.c:re_load_imm_any Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx_data Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx8 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx1 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx2 Cyclomatic Complexity 3 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_stx4 Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_st_data Cyclomatic Complexity 2 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_st Cyclomatic Complexity 1 drivers/net/ethernet/netronome/nfp/bpf/jit.c:mem_st8 Cyclomatic
Please Dear, I Need An Investment Partner
-- Dear Assalamu Alaikum, I came across your contact during my private search Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan president, I have funds the sum of $27.5 million USD for investment, I am interested in you for investment project assistance in your country, i shall compensate you 30% of the total sum after the funds are transfer into your account, Greetings from Mrs Aisha Al-Qaddafi Mrs Aisha Al-Qaddafi --
Please Dear, I Need An Investment Partner
-- Dear Assalamu Alaikum, I came across your contact during my private search Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan president, I have funds the sum of $27.5 million USD for investment, I am interested in you for investment project assistance in your country, i shall compensate you 30% of the total sum after the funds are transfer into your account, Greetings from Mrs Aisha Al-Qaddafi Mrs Aisha Al-Qaddafi --
Honest And Truthful 08/252018
I wish to seek for your assistance in a deal that will be of mutual benefit for the both of us from Camp Stanley, Stationed in Uijeongbu, South Korea. Please get back to me for more info. Thank you for your time. Sgt.Joan Martinez
Honest And Truthful 08/252018
I wish to seek for your assistance in a deal that will be of mutual benefit for the both of us from Camp Stanley, Stationed in Uijeongbu, South Korea. Please get back to me for more info. Thank you for your time. Sgt.Joan Martinez
[GIT PULL] ARM: SoC late branch
Hi Linus, The following changes since commit 29ed45fff05899f6f39d05fe1c32b1bc51f8926b: Merge tag 'v4.18-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into next/drivers (2018-07-26 13:08:01 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-late for you to fetch changes up to 1aa55ca9b14af6cfd987ce4fdaf548f7067a5d07: iommu/rockchip: Move irq request past pm_runtime_enable (2018-08-24 08:50:32 -0700) ARM: SoC: late updates A couple of late-merged changes that would be useful to get in this merge window: - Driver support for reset of audio complex on Meson platforms. The audio driver went in this merge window, and these changes have been in -next for a while (just not in our tree). - Power management fixes for IOMMU on Rockchip platforms, getting closer to kexec working on them, including Chromebooks. - Another pass updating "arm,psci" -> "psci" for some properties that have snuck in since last time it was done. Amit Kucheria (1): arm64: dts: Fix various entry-method properties to reflect documentation Jerome Brunet (2): reset: meson: add dt-bindings for meson-axg audio arb reset: meson: add meson audio arb driver Leonard Crestez (1): reset: imx7: Fix always writing bits as 0 Marc Zyngier (4): ARM: rockchip: Force CONFIG_PM on Rockchip systems arm64: rockchip: Force CONFIG_PM on Rockchip systems iommu/rockchip: Handle errors returned from PM framework iommu/rockchip: Move irq request past pm_runtime_enable Olof Johansson (2): Merge tag 'reset-for-4.19-2' of git://git.pengutronix.de/git/pza/linux into next/late Merge tag 'reset-fixes-for-4.18' of git://git.pengutronix.de/git/pza/linux into next/late .../devicetree/bindings/arm/cpu-capacity.txt | 2 +- .../devicetree/bindings/arm/idle-states.txt| 4 +- .../bindings/reset/amlogic,meson-axg-audio-arb.txt | 21 +++ arch/arm/mach-rockchip/Kconfig | 1 + arch/arm64/Kconfig.platforms | 1 + arch/arm64/boot/dts/arm/juno-r1.dts| 2 +- arch/arm64/boot/dts/arm/juno-r2.dts| 2 +- arch/arm64/boot/dts/arm/juno.dts | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 2 +- arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 2 +- arch/arm64/boot/dts/sprd/sc9860.dtsi | 2 +- arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 2 +- drivers/iommu/rockchip-iommu.c | 45 +++--- drivers/reset/Kconfig | 7 + drivers/reset/Makefile | 1 + drivers/reset/reset-imx7.c | 2 +- drivers/reset/reset-meson-audio-arb.c | 168 + .../reset/amlogic,meson-axg-audio-arb.h| 17 +++ 20 files changed, 257 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.txt create mode 100644 drivers/reset/reset-meson-audio-arb.c create mode 100644 include/dt-bindings/reset/amlogic,meson-axg-audio-arb.h
[GIT PULL] ARM: SoC late branch
Hi Linus, The following changes since commit 29ed45fff05899f6f39d05fe1c32b1bc51f8926b: Merge tag 'v4.18-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into next/drivers (2018-07-26 13:08:01 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-late for you to fetch changes up to 1aa55ca9b14af6cfd987ce4fdaf548f7067a5d07: iommu/rockchip: Move irq request past pm_runtime_enable (2018-08-24 08:50:32 -0700) ARM: SoC: late updates A couple of late-merged changes that would be useful to get in this merge window: - Driver support for reset of audio complex on Meson platforms. The audio driver went in this merge window, and these changes have been in -next for a while (just not in our tree). - Power management fixes for IOMMU on Rockchip platforms, getting closer to kexec working on them, including Chromebooks. - Another pass updating "arm,psci" -> "psci" for some properties that have snuck in since last time it was done. Amit Kucheria (1): arm64: dts: Fix various entry-method properties to reflect documentation Jerome Brunet (2): reset: meson: add dt-bindings for meson-axg audio arb reset: meson: add meson audio arb driver Leonard Crestez (1): reset: imx7: Fix always writing bits as 0 Marc Zyngier (4): ARM: rockchip: Force CONFIG_PM on Rockchip systems arm64: rockchip: Force CONFIG_PM on Rockchip systems iommu/rockchip: Handle errors returned from PM framework iommu/rockchip: Move irq request past pm_runtime_enable Olof Johansson (2): Merge tag 'reset-for-4.19-2' of git://git.pengutronix.de/git/pza/linux into next/late Merge tag 'reset-fixes-for-4.18' of git://git.pengutronix.de/git/pza/linux into next/late .../devicetree/bindings/arm/cpu-capacity.txt | 2 +- .../devicetree/bindings/arm/idle-states.txt| 4 +- .../bindings/reset/amlogic,meson-axg-audio-arb.txt | 21 +++ arch/arm/mach-rockchip/Kconfig | 1 + arch/arm64/Kconfig.platforms | 1 + arch/arm64/boot/dts/arm/juno-r1.dts| 2 +- arch/arm64/boot/dts/arm/juno-r2.dts| 2 +- arch/arm64/boot/dts/arm/juno.dts | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 2 +- arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 2 +- arch/arm64/boot/dts/sprd/sc9860.dtsi | 2 +- arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 2 +- drivers/iommu/rockchip-iommu.c | 45 +++--- drivers/reset/Kconfig | 7 + drivers/reset/Makefile | 1 + drivers/reset/reset-imx7.c | 2 +- drivers/reset/reset-meson-audio-arb.c | 168 + .../reset/amlogic,meson-axg-audio-arb.h| 17 +++ 20 files changed, 257 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.txt create mode 100644 drivers/reset/reset-meson-audio-arb.c create mode 100644 include/dt-bindings/reset/amlogic,meson-axg-audio-arb.h
[PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..0d0233e 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -26,7 +26,7 @@
#define DRV_NAME "ahci"
-static const struct ata_port_info ahci_port_info = {
+static struct ata_port_info ahci_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
@@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ struct acpi_device_info *info;
+ acpi_status status;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
+ status = acpi_get_object_info(ACPI_HANDLE(dev), );
+ if (ACPI_SUCCESS(status)) {
+ if (info->valid & ACPI_VALID_HID) {
+ if (!strcmp("APMC0D33", info->hardware_id.string))
+ ahci_port_info.flags |= ATA_FLAG_NO_LPM;
+ }
+ ACPI_FREE(info);
+ }
+
rc = ahci_platform_init_host(pdev, hpriv, _port_info,
_platform_sht);
if (rc)
--
1.8.3.1
[PATCH] ata: Disable AHCI ALPM feature for Ampere Computing eMAG SATA
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 99f9a89..0d0233e 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -26,7 +26,7 @@
#define DRV_NAME "ahci"
-static const struct ata_port_info ahci_port_info = {
+static struct ata_port_info ahci_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
@@ -41,6 +41,8 @@ static int ahci_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct ahci_host_priv *hpriv;
+ struct acpi_device_info *info;
+ acpi_status status;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -57,6 +59,15 @@ static int ahci_probe(struct platform_device *pdev)
if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
+ status = acpi_get_object_info(ACPI_HANDLE(dev), );
+ if (ACPI_SUCCESS(status)) {
+ if (info->valid & ACPI_VALID_HID) {
+ if (!strcmp("APMC0D33", info->hardware_id.string))
+ ahci_port_info.flags |= ATA_FLAG_NO_LPM;
+ }
+ ACPI_FREE(info);
+ }
+
rc = ahci_platform_init_host(pdev, hpriv, _port_info,
_platform_sht);
if (rc)
--
1.8.3.1
[PATCH 4/4] MAINTAINERS: add entry for fxas21002c gyro driver
Add entry for fxas21002c gyroscope driver and add myself as maintainer of this driver. Signed-off-by: Afonso Bordado --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2b7b24b145f0..faf5f41b1465 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5838,6 +5838,13 @@ L: linuxppc-...@lists.ozlabs.org S: Maintained F: drivers/usb/gadget/udc/fsl* +FREESCALE FXAS21002C +M: Afonso Bordado +L: linux-...@vger.kernel.org +S: Maintained +F: drivers/iio/gyro/fxas21002.c +F: Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt + FREEVXFS FILESYSTEM M: Christoph Hellwig W: ftp://ftp.openlinux.org/pub/people/hch/vxfs -- 2.18.0
[PATCH 1/4] iio: gyro: add support for fxas21002c
FXAS21002C is a 3 axis gyroscope with integrated temperature sensor
Signed-off-by: Afonso Bordado
---
drivers/iio/gyro/Kconfig | 11 ++
drivers/iio/gyro/Makefile | 1 +
drivers/iio/gyro/fxas21002c.c | 363 ++
3 files changed, 375 insertions(+)
create mode 100644 drivers/iio/gyro/fxas21002c.c
diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig
index 3126cf05e6b9..d71e33ea9fa4 100644
--- a/drivers/iio/gyro/Kconfig
+++ b/drivers/iio/gyro/Kconfig
@@ -73,6 +73,17 @@ config BMG160_SPI
tristate
select REGMAP_SPI
+config FXAS21002C
+ tristate "Freescale FXAS21002C Gyroscope"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say yes here to build support for the Freescale FXAS21002C Gyroscope
+ driver connected via I2C.
+
+ This driver can also be built as a module. If so, the module
+ will be called fxas21002c.
+
config HID_SENSOR_GYRO_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/gyro/Makefile b/drivers/iio/gyro/Makefile
index 295ec780c4eb..ec3e2aeae92a 100644
--- a/drivers/iio/gyro/Makefile
+++ b/drivers/iio/gyro/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_ADXRS450) += adxrs450.o
obj-$(CONFIG_BMG160) += bmg160_core.o
obj-$(CONFIG_BMG160_I2C) += bmg160_i2c.o
obj-$(CONFIG_BMG160_SPI) += bmg160_spi.o
+obj-$(CONFIG_FXAS21002C) += fxas21002c.o
obj-$(CONFIG_HID_SENSOR_GYRO_3D) += hid-sensor-gyro-3d.o
diff --git a/drivers/iio/gyro/fxas21002c.c b/drivers/iio/gyro/fxas21002c.c
new file mode 100644
index ..7626b2f88d72
--- /dev/null
+++ b/drivers/iio/gyro/fxas21002c.c
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * FXAS21002C - Digital Angular Rate Gyroscope driver
+ *
+ * Copyright (c) 2018, Afonso Bordado
+ *
+ * IIO driver for FXAS21002C (7-bit I2C slave address 0x20 or 0x21).
+ * Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf
+ * TODO:
+ *ODR / Scale Support
+ *Devicetree
+ *Power management
+ *LowPass/HighPass Filters
+ *Buffers
+ *Interrupts
+ *Alarms
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define FXAS21002C_DRV_NAME "fxas21002c"
+
+#define FXAS21002C_MAX_TRANSITION_TIME_MS 61
+
+#define FXAS21002C_CHIP_ID 0xD7
+
+#define FXAS21002C_REG_STATUS 0x00
+#define FXAS21002C_REG_OUT_X_MSB 0x01
+#define FXAS21002C_REG_OUT_X_LSB 0x02
+#define FXAS21002C_REG_OUT_Y_MSB 0x03
+#define FXAS21002C_REG_OUT_Y_LSB 0x04
+#define FXAS21002C_REG_OUT_Z_MSB 0x05
+#define FXAS21002C_REG_OUT_Z_LSB 0x06
+#define FXAS21002C_REG_DR_STATUS 0x07
+#define FXAS21002C_REG_F_STATUS0x08
+#define FXAS21002C_REG_F_SETUP 0x09
+#define FXAS21002C_REG_F_EVENT 0x0A
+#define FXAS21002C_REG_INT_SRC_FLAG0x0B
+#define FXAS21002C_REG_WHO_AM_I0x0C
+#define FXAS21002C_REG_CTRL_REG0 0x0D
+#define FXAS21002C_REG_RT_CFG 0x0E
+#define FXAS21002C_REG_RT_SRC 0x0F
+#define FXAS21002C_REG_RT_THS 0x10
+#define FXAS21002C_REG_RT_COUNT0x11
+#define FXAS21002C_REG_TEMP0x12
+
+#define FXAS21002C_REG_CTRL_REG1 0x13
+#define FXAS21002C_RST_BIT BIT(6)
+#define FXAS21002C_ACTIVE_BIT BIT(1)
+#define FXAS21002C_READY_BIT BIT(0)
+
+#define FXAS21002C_REG_CTRL_REG2 0x14
+#define FXAS21002C_REG_CTRL_REG3 0x15
+
+#define FXAS21002C_DEFAULT_ODR_HZ 800
+
+// 0.0625 deg/s
+#define FXAS21002C_DEFAULT_SENSITIVITY IIO_DEGREE_TO_RAD(62500)
+
+enum fxas21002c_id {
+ ID_FXAS21002C,
+};
+
+enum fxas21002c_operating_mode {
+ FXAS21002C_OM_BOOT,
+ FXAS21002C_OM_STANDBY,
+ FXAS21002C_OM_READY,
+ FXAS21002C_OM_ACTIVE,
+};
+
+struct fxas21002c_data {
+ struct i2c_client *client;
+ struct regmap *regmap;
+};
+
+static const struct regmap_range fxas21002c_writable_ranges[] = {
+ regmap_reg_range(FXAS21002C_REG_F_SETUP, FXAS21002C_REG_F_SETUP),
+ regmap_reg_range(FXAS21002C_REG_CTRL_REG0, FXAS21002C_REG_RT_CFG),
+ regmap_reg_range(FXAS21002C_REG_RT_THS, FXAS21002C_REG_RT_COUNT),
+ regmap_reg_range(FXAS21002C_REG_CTRL_REG1, FXAS21002C_REG_CTRL_REG3),
+};
+
+static const struct regmap_access_table fxas21002c_writable_table = {
+ .yes_ranges = fxas21002c_writable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(fxas21002c_writable_ranges),
+};
+
+static const struct regmap_range fxas21002c_volatile_ranges[] = {
+ regmap_reg_range(FXAS21002C_REG_STATUS, FXAS21002C_REG_F_STATUS),
+ regmap_reg_range(FXAS21002C_REG_F_EVENT, FXAS21002C_REG_INT_SRC_FLAG),
+ regmap_reg_range(FXAS21002C_REG_RT_COUNT, FXAS21002C_REG_CTRL_REG1),
+};
+
+static const struct regmap_access_table fxas21002c_volatile_table = {
+ .yes_ranges = fxas21002c_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(fxas21002c_volatile_ranges),
+};
+
+const
[PATCH 2/4] iio: gyro: add device tree support for fxas21002c
This patch adds device tree support for the fxas21002c driver, including
bindings.
Signed-off-by: Afonso Bordado
---
.../bindings/iio/gyroscope/fsl,fxas21002c.txt| 12
drivers/iio/gyro/fxas21002c.c| 10 +-
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
b/Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
new file mode 100644
index ..62f8c1bad85a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
@@ -0,0 +1,12 @@
+* Freescale FXAS21002C Digital Angular Rate Gyroscope
+
+Required properties:
+
+ - compatible: must be "fsl,fxas21002c"
+ - reg : the I2C address of the sensor
+
+Example:
+gyroscope@0 {
+ compatible = "fsl,fxas21002c";
+ reg = <0x20>;
+};
diff --git a/drivers/iio/gyro/fxas21002c.c b/drivers/iio/gyro/fxas21002c.c
index 7626b2f88d72..6fef210630e0 100644
--- a/drivers/iio/gyro/fxas21002c.c
+++ b/drivers/iio/gyro/fxas21002c.c
@@ -8,7 +8,6 @@
* Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf
* TODO:
*ODR / Scale Support
- *Devicetree
*Power management
*LowPass/HighPass Filters
*Buffers
@@ -340,6 +339,14 @@ static int fxas21002c_remove(struct i2c_client *client)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id fxas21002c_of_ids[] = {
+ {.compatible = "fsl,fxas21002c"},
+ {}
+};
+MODULE_DEVICE_TABLE(of, fxas21002c_of_ids);
+#endif
+
static const struct i2c_device_id fxas21002c_id[] = {
{"fxas21002c", ID_FXAS21002C},
{}
@@ -350,6 +357,7 @@ MODULE_DEVICE_TABLE(i2c, fxas21002c_id);
static struct i2c_driver fxas21002c_driver = {
.driver = {
.name = FXAS21002C_DRV_NAME,
+ .of_match_table = of_match_ptr(fxas21002c_of_ids),
},
.probe = fxas21002c_probe,
.remove = fxas21002c_remove,
--
2.18.0
[PATCH 3/4] iio: fxas21002c: add ODR/Scale support
This patch adds support for reading/writing ODR/Scale
We don't support the scale boost modes.
Signed-off-by: Afonso Bordado
---
drivers/iio/gyro/fxas21002c.c | 162 +++---
1 file changed, 149 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/gyro/fxas21002c.c b/drivers/iio/gyro/fxas21002c.c
index 6fef210630e0..dc0cb9848386 100644
--- a/drivers/iio/gyro/fxas21002c.c
+++ b/drivers/iio/gyro/fxas21002c.c
@@ -7,7 +7,7 @@
* IIO driver for FXAS21002C (7-bit I2C slave address 0x20 or 0x21).
* Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf
* TODO:
- *ODR / Scale Support
+ *Scale boost mode
*Power management
*LowPass/HighPass Filters
*Buffers
@@ -40,7 +40,10 @@
#define FXAS21002C_REG_F_EVENT 0x0A
#define FXAS21002C_REG_INT_SRC_FLAG0x0B
#define FXAS21002C_REG_WHO_AM_I0x0C
+
#define FXAS21002C_REG_CTRL_REG0 0x0D
+#define FXAS21002C_SCALE_MASK (BIT(0) | BIT(1))
+
#define FXAS21002C_REG_RT_CFG 0x0E
#define FXAS21002C_REG_RT_SRC 0x0F
#define FXAS21002C_REG_RT_THS 0x10
@@ -52,13 +55,12 @@
#define FXAS21002C_ACTIVE_BIT BIT(1)
#define FXAS21002C_READY_BIT BIT(0)
-#define FXAS21002C_REG_CTRL_REG2 0x14
-#define FXAS21002C_REG_CTRL_REG3 0x15
+#define FXAS21002C_ODR_SHIFT 2
+#define FXAS21002C_ODR_MASK(BIT(2) | BIT(3) | BIT(4))
-#define FXAS21002C_DEFAULT_ODR_HZ 800
-// 0.0625 deg/s
-#define FXAS21002C_DEFAULT_SENSITIVITY IIO_DEGREE_TO_RAD(62500)
+#define FXAS21002C_REG_CTRL_REG2 0x14
+#define FXAS21002C_REG_CTRL_REG3 0x15
enum fxas21002c_id {
ID_FXAS21002C,
@@ -76,6 +78,40 @@ struct fxas21002c_data {
struct regmap *regmap;
};
+enum fxas21002c_scale {
+ FXAS21002C_SCALE_62MDPS,
+ FXAS21002C_SCALE_31MDPS,
+ FXAS21002C_SCALE_15MDPS,
+ FXAS21002C_SCALE_7MDPS,
+};
+
+static const int fxas21002c_anglevel_scale_avail[4][2] = {
+ [FXAS21002C_SCALE_62MDPS] = { 0, IIO_DEGREE_TO_RAD(62500) },
+ [FXAS21002C_SCALE_31MDPS] = { 0, IIO_DEGREE_TO_RAD(31250) },
+ [FXAS21002C_SCALE_15MDPS] = { 0, IIO_DEGREE_TO_RAD(15625) },
+ [FXAS21002C_SCALE_7MDPS] = { 0, IIO_DEGREE_TO_RAD(7812) },
+};
+
+enum fxas21002c_odr {
+ FXAS21002C_ODR_800,
+ FXAS21002C_ODR_400,
+ FXAS21002C_ODR_200,
+ FXAS21002C_ODR_100,
+ FXAS21002C_ODR_50,
+ FXAS21002C_ODR_25,
+ FXAS21002C_ODR_12_5,
+};
+
+static const int fxas21002c_sample_freq_avail[7][2] = {
+ [FXAS21002C_ODR_800] = { 800, 0 },
+ [FXAS21002C_ODR_400] = { 400, 0 },
+ [FXAS21002C_ODR_200] = { 200, 0 },
+ [FXAS21002C_ODR_100] = { 100, 0 },
+ [FXAS21002C_ODR_50] = { 50, 0 },
+ [FXAS21002C_ODR_25] = { 25, 0 },
+ [FXAS21002C_ODR_12_5] = { 12, 50 },
+};
+
static const struct regmap_range fxas21002c_writable_ranges[] = {
regmap_reg_range(FXAS21002C_REG_F_SETUP, FXAS21002C_REG_F_SETUP),
regmap_reg_range(FXAS21002C_REG_CTRL_REG0, FXAS21002C_REG_RT_CFG),
@@ -242,6 +278,47 @@ static int fxas21002c_read_oneshot(struct fxas21002c_data
*data,
return IIO_VAL_INT;
}
+static int fxas21002c_scale_read(struct fxas21002c_data *data, int *val,
+int *val2)
+{
+ int ret;
+ unsigned int raw;
+
+ ret = regmap_read(data->regmap, FXAS21002C_REG_CTRL_REG0, );
+ if (ret)
+ return ret;
+
+ raw &= FXAS21002C_SCALE_MASK;
+
+ *val = fxas21002c_anglevel_scale_avail[raw][0];
+ *val2 = fxas21002c_anglevel_scale_avail[raw][1];
+
+ return IIO_VAL_INT_PLUS_MICRO;
+}
+
+static int fxas21002c_odr_read(struct fxas21002c_data *data, int *val,
+ int *val2)
+{
+ int ret;
+ unsigned int raw;
+
+ ret = regmap_read(data->regmap, FXAS21002C_REG_CTRL_REG1, );
+ if (ret)
+ return ret;
+
+ raw = (raw & FXAS21002C_ODR_MASK) >> FXAS21002C_ODR_SHIFT;
+
+ // We don't use this mode but according to the datasheet its
+ // also a 12.5Hz
+ if (raw == 7)
+ raw = FXAS21002C_ODR_12_5;
+
+ *val = fxas21002c_sample_freq_avail[raw][0];
+ *val2 = fxas21002c_sample_freq_avail[raw][1];
+
+ return IIO_VAL_INT_PLUS_MICRO;
+}
+
static int fxas21002c_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan, int *val,
int *val2, long mask)
@@ -255,24 +332,83 @@ static int fxas21002c_read_raw(struct iio_dev *indio_dev,
if (chan->type != IIO_ANGL_VEL)
return -EINVAL;
- *val = 0;
- *val2 = FXAS21002C_DEFAULT_SENSITIVITY;
-
- return IIO_VAL_INT_PLUS_MICRO;
+ return fxas21002c_scale_read(data, val, val2);
case IIO_CHAN_INFO_SAMP_FREQ:
if
[PATCH 4/4] MAINTAINERS: add entry for fxas21002c gyro driver
Add entry for fxas21002c gyroscope driver and add myself as maintainer of this driver. Signed-off-by: Afonso Bordado --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2b7b24b145f0..faf5f41b1465 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5838,6 +5838,13 @@ L: linuxppc-...@lists.ozlabs.org S: Maintained F: drivers/usb/gadget/udc/fsl* +FREESCALE FXAS21002C +M: Afonso Bordado +L: linux-...@vger.kernel.org +S: Maintained +F: drivers/iio/gyro/fxas21002.c +F: Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt + FREEVXFS FILESYSTEM M: Christoph Hellwig W: ftp://ftp.openlinux.org/pub/people/hch/vxfs -- 2.18.0
[PATCH 1/4] iio: gyro: add support for fxas21002c
FXAS21002C is a 3 axis gyroscope with integrated temperature sensor
Signed-off-by: Afonso Bordado
---
drivers/iio/gyro/Kconfig | 11 ++
drivers/iio/gyro/Makefile | 1 +
drivers/iio/gyro/fxas21002c.c | 363 ++
3 files changed, 375 insertions(+)
create mode 100644 drivers/iio/gyro/fxas21002c.c
diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig
index 3126cf05e6b9..d71e33ea9fa4 100644
--- a/drivers/iio/gyro/Kconfig
+++ b/drivers/iio/gyro/Kconfig
@@ -73,6 +73,17 @@ config BMG160_SPI
tristate
select REGMAP_SPI
+config FXAS21002C
+ tristate "Freescale FXAS21002C Gyroscope"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say yes here to build support for the Freescale FXAS21002C Gyroscope
+ driver connected via I2C.
+
+ This driver can also be built as a module. If so, the module
+ will be called fxas21002c.
+
config HID_SENSOR_GYRO_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/gyro/Makefile b/drivers/iio/gyro/Makefile
index 295ec780c4eb..ec3e2aeae92a 100644
--- a/drivers/iio/gyro/Makefile
+++ b/drivers/iio/gyro/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_ADXRS450) += adxrs450.o
obj-$(CONFIG_BMG160) += bmg160_core.o
obj-$(CONFIG_BMG160_I2C) += bmg160_i2c.o
obj-$(CONFIG_BMG160_SPI) += bmg160_spi.o
+obj-$(CONFIG_FXAS21002C) += fxas21002c.o
obj-$(CONFIG_HID_SENSOR_GYRO_3D) += hid-sensor-gyro-3d.o
diff --git a/drivers/iio/gyro/fxas21002c.c b/drivers/iio/gyro/fxas21002c.c
new file mode 100644
index ..7626b2f88d72
--- /dev/null
+++ b/drivers/iio/gyro/fxas21002c.c
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * FXAS21002C - Digital Angular Rate Gyroscope driver
+ *
+ * Copyright (c) 2018, Afonso Bordado
+ *
+ * IIO driver for FXAS21002C (7-bit I2C slave address 0x20 or 0x21).
+ * Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf
+ * TODO:
+ *ODR / Scale Support
+ *Devicetree
+ *Power management
+ *LowPass/HighPass Filters
+ *Buffers
+ *Interrupts
+ *Alarms
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define FXAS21002C_DRV_NAME "fxas21002c"
+
+#define FXAS21002C_MAX_TRANSITION_TIME_MS 61
+
+#define FXAS21002C_CHIP_ID 0xD7
+
+#define FXAS21002C_REG_STATUS 0x00
+#define FXAS21002C_REG_OUT_X_MSB 0x01
+#define FXAS21002C_REG_OUT_X_LSB 0x02
+#define FXAS21002C_REG_OUT_Y_MSB 0x03
+#define FXAS21002C_REG_OUT_Y_LSB 0x04
+#define FXAS21002C_REG_OUT_Z_MSB 0x05
+#define FXAS21002C_REG_OUT_Z_LSB 0x06
+#define FXAS21002C_REG_DR_STATUS 0x07
+#define FXAS21002C_REG_F_STATUS0x08
+#define FXAS21002C_REG_F_SETUP 0x09
+#define FXAS21002C_REG_F_EVENT 0x0A
+#define FXAS21002C_REG_INT_SRC_FLAG0x0B
+#define FXAS21002C_REG_WHO_AM_I0x0C
+#define FXAS21002C_REG_CTRL_REG0 0x0D
+#define FXAS21002C_REG_RT_CFG 0x0E
+#define FXAS21002C_REG_RT_SRC 0x0F
+#define FXAS21002C_REG_RT_THS 0x10
+#define FXAS21002C_REG_RT_COUNT0x11
+#define FXAS21002C_REG_TEMP0x12
+
+#define FXAS21002C_REG_CTRL_REG1 0x13
+#define FXAS21002C_RST_BIT BIT(6)
+#define FXAS21002C_ACTIVE_BIT BIT(1)
+#define FXAS21002C_READY_BIT BIT(0)
+
+#define FXAS21002C_REG_CTRL_REG2 0x14
+#define FXAS21002C_REG_CTRL_REG3 0x15
+
+#define FXAS21002C_DEFAULT_ODR_HZ 800
+
+// 0.0625 deg/s
+#define FXAS21002C_DEFAULT_SENSITIVITY IIO_DEGREE_TO_RAD(62500)
+
+enum fxas21002c_id {
+ ID_FXAS21002C,
+};
+
+enum fxas21002c_operating_mode {
+ FXAS21002C_OM_BOOT,
+ FXAS21002C_OM_STANDBY,
+ FXAS21002C_OM_READY,
+ FXAS21002C_OM_ACTIVE,
+};
+
+struct fxas21002c_data {
+ struct i2c_client *client;
+ struct regmap *regmap;
+};
+
+static const struct regmap_range fxas21002c_writable_ranges[] = {
+ regmap_reg_range(FXAS21002C_REG_F_SETUP, FXAS21002C_REG_F_SETUP),
+ regmap_reg_range(FXAS21002C_REG_CTRL_REG0, FXAS21002C_REG_RT_CFG),
+ regmap_reg_range(FXAS21002C_REG_RT_THS, FXAS21002C_REG_RT_COUNT),
+ regmap_reg_range(FXAS21002C_REG_CTRL_REG1, FXAS21002C_REG_CTRL_REG3),
+};
+
+static const struct regmap_access_table fxas21002c_writable_table = {
+ .yes_ranges = fxas21002c_writable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(fxas21002c_writable_ranges),
+};
+
+static const struct regmap_range fxas21002c_volatile_ranges[] = {
+ regmap_reg_range(FXAS21002C_REG_STATUS, FXAS21002C_REG_F_STATUS),
+ regmap_reg_range(FXAS21002C_REG_F_EVENT, FXAS21002C_REG_INT_SRC_FLAG),
+ regmap_reg_range(FXAS21002C_REG_RT_COUNT, FXAS21002C_REG_CTRL_REG1),
+};
+
+static const struct regmap_access_table fxas21002c_volatile_table = {
+ .yes_ranges = fxas21002c_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(fxas21002c_volatile_ranges),
+};
+
+const
[PATCH 2/4] iio: gyro: add device tree support for fxas21002c
This patch adds device tree support for the fxas21002c driver, including
bindings.
Signed-off-by: Afonso Bordado
---
.../bindings/iio/gyroscope/fsl,fxas21002c.txt| 12
drivers/iio/gyro/fxas21002c.c| 10 +-
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
b/Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
new file mode 100644
index ..62f8c1bad85a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyroscope/fsl,fxas21002c.txt
@@ -0,0 +1,12 @@
+* Freescale FXAS21002C Digital Angular Rate Gyroscope
+
+Required properties:
+
+ - compatible: must be "fsl,fxas21002c"
+ - reg : the I2C address of the sensor
+
+Example:
+gyroscope@0 {
+ compatible = "fsl,fxas21002c";
+ reg = <0x20>;
+};
diff --git a/drivers/iio/gyro/fxas21002c.c b/drivers/iio/gyro/fxas21002c.c
index 7626b2f88d72..6fef210630e0 100644
--- a/drivers/iio/gyro/fxas21002c.c
+++ b/drivers/iio/gyro/fxas21002c.c
@@ -8,7 +8,6 @@
* Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf
* TODO:
*ODR / Scale Support
- *Devicetree
*Power management
*LowPass/HighPass Filters
*Buffers
@@ -340,6 +339,14 @@ static int fxas21002c_remove(struct i2c_client *client)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id fxas21002c_of_ids[] = {
+ {.compatible = "fsl,fxas21002c"},
+ {}
+};
+MODULE_DEVICE_TABLE(of, fxas21002c_of_ids);
+#endif
+
static const struct i2c_device_id fxas21002c_id[] = {
{"fxas21002c", ID_FXAS21002C},
{}
@@ -350,6 +357,7 @@ MODULE_DEVICE_TABLE(i2c, fxas21002c_id);
static struct i2c_driver fxas21002c_driver = {
.driver = {
.name = FXAS21002C_DRV_NAME,
+ .of_match_table = of_match_ptr(fxas21002c_of_ids),
},
.probe = fxas21002c_probe,
.remove = fxas21002c_remove,
--
2.18.0
[PATCH 3/4] iio: fxas21002c: add ODR/Scale support
This patch adds support for reading/writing ODR/Scale
We don't support the scale boost modes.
Signed-off-by: Afonso Bordado
---
drivers/iio/gyro/fxas21002c.c | 162 +++---
1 file changed, 149 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/gyro/fxas21002c.c b/drivers/iio/gyro/fxas21002c.c
index 6fef210630e0..dc0cb9848386 100644
--- a/drivers/iio/gyro/fxas21002c.c
+++ b/drivers/iio/gyro/fxas21002c.c
@@ -7,7 +7,7 @@
* IIO driver for FXAS21002C (7-bit I2C slave address 0x20 or 0x21).
* Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf
* TODO:
- *ODR / Scale Support
+ *Scale boost mode
*Power management
*LowPass/HighPass Filters
*Buffers
@@ -40,7 +40,10 @@
#define FXAS21002C_REG_F_EVENT 0x0A
#define FXAS21002C_REG_INT_SRC_FLAG0x0B
#define FXAS21002C_REG_WHO_AM_I0x0C
+
#define FXAS21002C_REG_CTRL_REG0 0x0D
+#define FXAS21002C_SCALE_MASK (BIT(0) | BIT(1))
+
#define FXAS21002C_REG_RT_CFG 0x0E
#define FXAS21002C_REG_RT_SRC 0x0F
#define FXAS21002C_REG_RT_THS 0x10
@@ -52,13 +55,12 @@
#define FXAS21002C_ACTIVE_BIT BIT(1)
#define FXAS21002C_READY_BIT BIT(0)
-#define FXAS21002C_REG_CTRL_REG2 0x14
-#define FXAS21002C_REG_CTRL_REG3 0x15
+#define FXAS21002C_ODR_SHIFT 2
+#define FXAS21002C_ODR_MASK(BIT(2) | BIT(3) | BIT(4))
-#define FXAS21002C_DEFAULT_ODR_HZ 800
-// 0.0625 deg/s
-#define FXAS21002C_DEFAULT_SENSITIVITY IIO_DEGREE_TO_RAD(62500)
+#define FXAS21002C_REG_CTRL_REG2 0x14
+#define FXAS21002C_REG_CTRL_REG3 0x15
enum fxas21002c_id {
ID_FXAS21002C,
@@ -76,6 +78,40 @@ struct fxas21002c_data {
struct regmap *regmap;
};
+enum fxas21002c_scale {
+ FXAS21002C_SCALE_62MDPS,
+ FXAS21002C_SCALE_31MDPS,
+ FXAS21002C_SCALE_15MDPS,
+ FXAS21002C_SCALE_7MDPS,
+};
+
+static const int fxas21002c_anglevel_scale_avail[4][2] = {
+ [FXAS21002C_SCALE_62MDPS] = { 0, IIO_DEGREE_TO_RAD(62500) },
+ [FXAS21002C_SCALE_31MDPS] = { 0, IIO_DEGREE_TO_RAD(31250) },
+ [FXAS21002C_SCALE_15MDPS] = { 0, IIO_DEGREE_TO_RAD(15625) },
+ [FXAS21002C_SCALE_7MDPS] = { 0, IIO_DEGREE_TO_RAD(7812) },
+};
+
+enum fxas21002c_odr {
+ FXAS21002C_ODR_800,
+ FXAS21002C_ODR_400,
+ FXAS21002C_ODR_200,
+ FXAS21002C_ODR_100,
+ FXAS21002C_ODR_50,
+ FXAS21002C_ODR_25,
+ FXAS21002C_ODR_12_5,
+};
+
+static const int fxas21002c_sample_freq_avail[7][2] = {
+ [FXAS21002C_ODR_800] = { 800, 0 },
+ [FXAS21002C_ODR_400] = { 400, 0 },
+ [FXAS21002C_ODR_200] = { 200, 0 },
+ [FXAS21002C_ODR_100] = { 100, 0 },
+ [FXAS21002C_ODR_50] = { 50, 0 },
+ [FXAS21002C_ODR_25] = { 25, 0 },
+ [FXAS21002C_ODR_12_5] = { 12, 50 },
+};
+
static const struct regmap_range fxas21002c_writable_ranges[] = {
regmap_reg_range(FXAS21002C_REG_F_SETUP, FXAS21002C_REG_F_SETUP),
regmap_reg_range(FXAS21002C_REG_CTRL_REG0, FXAS21002C_REG_RT_CFG),
@@ -242,6 +278,47 @@ static int fxas21002c_read_oneshot(struct fxas21002c_data
*data,
return IIO_VAL_INT;
}
+static int fxas21002c_scale_read(struct fxas21002c_data *data, int *val,
+int *val2)
+{
+ int ret;
+ unsigned int raw;
+
+ ret = regmap_read(data->regmap, FXAS21002C_REG_CTRL_REG0, );
+ if (ret)
+ return ret;
+
+ raw &= FXAS21002C_SCALE_MASK;
+
+ *val = fxas21002c_anglevel_scale_avail[raw][0];
+ *val2 = fxas21002c_anglevel_scale_avail[raw][1];
+
+ return IIO_VAL_INT_PLUS_MICRO;
+}
+
+static int fxas21002c_odr_read(struct fxas21002c_data *data, int *val,
+ int *val2)
+{
+ int ret;
+ unsigned int raw;
+
+ ret = regmap_read(data->regmap, FXAS21002C_REG_CTRL_REG1, );
+ if (ret)
+ return ret;
+
+ raw = (raw & FXAS21002C_ODR_MASK) >> FXAS21002C_ODR_SHIFT;
+
+ // We don't use this mode but according to the datasheet its
+ // also a 12.5Hz
+ if (raw == 7)
+ raw = FXAS21002C_ODR_12_5;
+
+ *val = fxas21002c_sample_freq_avail[raw][0];
+ *val2 = fxas21002c_sample_freq_avail[raw][1];
+
+ return IIO_VAL_INT_PLUS_MICRO;
+}
+
static int fxas21002c_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan, int *val,
int *val2, long mask)
@@ -255,24 +332,83 @@ static int fxas21002c_read_raw(struct iio_dev *indio_dev,
if (chan->type != IIO_ANGL_VEL)
return -EINVAL;
- *val = 0;
- *val2 = FXAS21002C_DEFAULT_SENSITIVITY;
-
- return IIO_VAL_INT_PLUS_MICRO;
+ return fxas21002c_scale_read(data, val, val2);
case IIO_CHAN_INFO_SAMP_FREQ:
if
Re: linux-next: build warnings from the build of Linus' tree
On Sat, Aug 25, 2018 at 8:53 PM Masami Hiramatsu wrote:
> On Fri, 24 Aug 2018 14:46:16 +0200
> Arnd Bergmann wrote:
> > On Fri, Aug 24, 2018 at 10:23 AM Masami Hiramatsu
> > wrote:
> > >
> > > On Fri, 24 Aug 2018 13:32:06 +1000
> > > Stephen Rothwell wrote:
> > >
> > > > Hi all,
> > > >
> > > > After merging the origin tree, today's linux-next build (powerpc
> > > > allyesconfig) produced these warnings:
> > > >
> > > > Maybe introduced by commit
> > > >
> > > > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace
> > > > subsystem")
> > > >
> > > > I am guessing, but that is the only new thing that affects all of
> > > > kernel/trace ...
> > >
> > > Yes, I agree. But I just followed Documentation/dev-tools/gcov.rst
> > > to enable profiling in kernel/trace. Hmm, doesn't ppc64 support
> > > GCOV_PROFILE? (But as far as I can see, ARCH_HAS_GCOV_PROFILE_ALL
> > > is enabled in arch/powerpc/Kconfig)
> > >
> > > Anyway, I'll try to reproduce it.
> >
> > Thje same commit causes a link failure on ARM with a randconfig
> > kernel (see https://pastebin.com/KspjpyKG for the .config):
>
> OK, I confirmed that this happened with both gcc-7.3.0 and gcc-8.1.0
> with your config.
> I also confirmed that CONFIG_GCOV_PROFILE_ALL causes same issue.
> (Note that CONFIG_GCOV_PROFILE_ALL depends on !CONFIG_COMPILE_TEST,
> so allyesconfig disables it always)
>
> Hmm, now gcov kernel itself might have a problem on arm and
> powerpc(on gcc-8)?
Yes, that is very possible. I always force CONFIG_COMPILE_TEST=y
in my randconfig tests, so I miss that kind of problem.
Arnd
Re: linux-next: build warnings from the build of Linus' tree
On Sat, Aug 25, 2018 at 8:53 PM Masami Hiramatsu wrote:
> On Fri, 24 Aug 2018 14:46:16 +0200
> Arnd Bergmann wrote:
> > On Fri, Aug 24, 2018 at 10:23 AM Masami Hiramatsu
> > wrote:
> > >
> > > On Fri, 24 Aug 2018 13:32:06 +1000
> > > Stephen Rothwell wrote:
> > >
> > > > Hi all,
> > > >
> > > > After merging the origin tree, today's linux-next build (powerpc
> > > > allyesconfig) produced these warnings:
> > > >
> > > > Maybe introduced by commit
> > > >
> > > > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace
> > > > subsystem")
> > > >
> > > > I am guessing, but that is the only new thing that affects all of
> > > > kernel/trace ...
> > >
> > > Yes, I agree. But I just followed Documentation/dev-tools/gcov.rst
> > > to enable profiling in kernel/trace. Hmm, doesn't ppc64 support
> > > GCOV_PROFILE? (But as far as I can see, ARCH_HAS_GCOV_PROFILE_ALL
> > > is enabled in arch/powerpc/Kconfig)
> > >
> > > Anyway, I'll try to reproduce it.
> >
> > Thje same commit causes a link failure on ARM with a randconfig
> > kernel (see https://pastebin.com/KspjpyKG for the .config):
>
> OK, I confirmed that this happened with both gcc-7.3.0 and gcc-8.1.0
> with your config.
> I also confirmed that CONFIG_GCOV_PROFILE_ALL causes same issue.
> (Note that CONFIG_GCOV_PROFILE_ALL depends on !CONFIG_COMPILE_TEST,
> so allyesconfig disables it always)
>
> Hmm, now gcov kernel itself might have a problem on arm and
> powerpc(on gcc-8)?
Yes, that is very possible. I always force CONFIG_COMPILE_TEST=y
in my randconfig tests, so I miss that kind of problem.
Arnd
Re: linux-next: build warnings from the build of Linus' tree
Hi Arnd,
On Fri, 24 Aug 2018 14:46:16 +0200
Arnd Bergmann wrote:
> On Fri, Aug 24, 2018 at 10:23 AM Masami Hiramatsu wrote:
> >
> > On Fri, 24 Aug 2018 13:32:06 +1000
> > Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > After merging the origin tree, today's linux-next build (powerpc
> > > allyesconfig) produced these warnings:
> > >
> > > Maybe introduced by commit
> > >
> > > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
> > >
> > > I am guessing, but that is the only new thing that affects all of
> > > kernel/trace ...
> >
> > Yes, I agree. But I just followed Documentation/dev-tools/gcov.rst
> > to enable profiling in kernel/trace. Hmm, doesn't ppc64 support
> > GCOV_PROFILE? (But as far as I can see, ARCH_HAS_GCOV_PROFILE_ALL
> > is enabled in arch/powerpc/Kconfig)
> >
> > Anyway, I'll try to reproduce it.
>
> Thje same commit causes a link failure on ARM with a randconfig
> kernel (see https://pastebin.com/KspjpyKG for the .config):
OK, I confirmed that this happened with both gcc-7.3.0 and gcc-8.1.0
with your config.
I also confirmed that CONFIG_GCOV_PROFILE_ALL causes same issue.
(Note that CONFIG_GCOV_PROFILE_ALL depends on !CONFIG_COMPILE_TEST,
so allyesconfig disables it always)
Hmm, now gcov kernel itself might have a problem on arm and
powerpc(on gcc-8)?
Thanks,
--
Masami Hiramatsu
Re: linux-next: build warnings from the build of Linus' tree
Hi Arnd,
On Fri, 24 Aug 2018 14:46:16 +0200
Arnd Bergmann wrote:
> On Fri, Aug 24, 2018 at 10:23 AM Masami Hiramatsu wrote:
> >
> > On Fri, 24 Aug 2018 13:32:06 +1000
> > Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > After merging the origin tree, today's linux-next build (powerpc
> > > allyesconfig) produced these warnings:
> > >
> > > Maybe introduced by commit
> > >
> > > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
> > >
> > > I am guessing, but that is the only new thing that affects all of
> > > kernel/trace ...
> >
> > Yes, I agree. But I just followed Documentation/dev-tools/gcov.rst
> > to enable profiling in kernel/trace. Hmm, doesn't ppc64 support
> > GCOV_PROFILE? (But as far as I can see, ARCH_HAS_GCOV_PROFILE_ALL
> > is enabled in arch/powerpc/Kconfig)
> >
> > Anyway, I'll try to reproduce it.
>
> Thje same commit causes a link failure on ARM with a randconfig
> kernel (see https://pastebin.com/KspjpyKG for the .config):
OK, I confirmed that this happened with both gcc-7.3.0 and gcc-8.1.0
with your config.
I also confirmed that CONFIG_GCOV_PROFILE_ALL causes same issue.
(Note that CONFIG_GCOV_PROFILE_ALL depends on !CONFIG_COMPILE_TEST,
so allyesconfig disables it always)
Hmm, now gcov kernel itself might have a problem on arm and
powerpc(on gcc-8)?
Thanks,
--
Masami Hiramatsu
Re: Disabling CPU vulnerabilities workarounds
On 8/25/2018 3:42 AM, Artem S. Tashkinov wrote: > Hello LKML, > > As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are > added to the Linux kernel without a simple way to disable them all in one > fell swoop. Many of the mitigations are unrelated to each other. There is no one aspect of the system that identifies a behavior as a security issue. I don't know anyone who could create a list of all the "fixes" that have gone in over the years. Realize that features like speculative execution have had security issues that are unrelated to obscure attacks like side-channels. While you may think that you don't care, some of those flaws affect correctness. My bet is you wouldn't want to disable those. > Disabling is a good option for strictly confined environments where no 3d > party untrusted code is ever to be run, e.g. a rendering farm, a > supercomputer, or even a home server which runs Samba/SSH server and nothing > else. Like maybe the software in centrifuges in a nuclear fuel processing plant? All the examples you've cited are network connected and are vulnerable to attack. And don't try the "no untrusted code" argument. You'll have code on those systems that has been known vulnerable for decades. > I wonder if someone could wrote a patch which implemented the following two > options for the kernel: > > * A boot option option which allows to disable most runtime > protections/workarounds/fixes (as far as I understand some of them can't be > reverted since they are compiled in or use certain GCC flags), e.g. let's > call it "insecure" or "insecurecpumode". That would be an interesting exercise for the opposite case. A boot option that enables all the runtime protections would certainly be interesting to some people. If you could implement one, you could do the other. I would be happy to review such a patch. Go for it. > * A compile-time CONFIG_ option which disables all these fixes _permanently_ > without a way to turn them later back on during runtime. This suffers from all the challenges previously mentioned, but would be equally interesting, again for the opposite case. > > Right now linux/Documentation/admin-guide/kernel-parameters.txt is a mess of > various things which take ages to sift through and there's zero understanding > whether you've found everything and correctly disabled it. I can't argue with you on that. Again, I believe the greater value would come from documenting how to turn everything on. > Best regards, > Artem
Re: Disabling CPU vulnerabilities workarounds
On 8/25/2018 3:42 AM, Artem S. Tashkinov wrote: > Hello LKML, > > As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are > added to the Linux kernel without a simple way to disable them all in one > fell swoop. Many of the mitigations are unrelated to each other. There is no one aspect of the system that identifies a behavior as a security issue. I don't know anyone who could create a list of all the "fixes" that have gone in over the years. Realize that features like speculative execution have had security issues that are unrelated to obscure attacks like side-channels. While you may think that you don't care, some of those flaws affect correctness. My bet is you wouldn't want to disable those. > Disabling is a good option for strictly confined environments where no 3d > party untrusted code is ever to be run, e.g. a rendering farm, a > supercomputer, or even a home server which runs Samba/SSH server and nothing > else. Like maybe the software in centrifuges in a nuclear fuel processing plant? All the examples you've cited are network connected and are vulnerable to attack. And don't try the "no untrusted code" argument. You'll have code on those systems that has been known vulnerable for decades. > I wonder if someone could wrote a patch which implemented the following two > options for the kernel: > > * A boot option option which allows to disable most runtime > protections/workarounds/fixes (as far as I understand some of them can't be > reverted since they are compiled in or use certain GCC flags), e.g. let's > call it "insecure" or "insecurecpumode". That would be an interesting exercise for the opposite case. A boot option that enables all the runtime protections would certainly be interesting to some people. If you could implement one, you could do the other. I would be happy to review such a patch. Go for it. > * A compile-time CONFIG_ option which disables all these fixes _permanently_ > without a way to turn them later back on during runtime. This suffers from all the challenges previously mentioned, but would be equally interesting, again for the opposite case. > > Right now linux/Documentation/admin-guide/kernel-parameters.txt is a mess of > various things which take ages to sift through and there's zero understanding > whether you've found everything and correctly disabled it. I can't argue with you on that. Again, I believe the greater value would come from documenting how to turn everything on. > Best regards, > Artem
Re: Query on skip_onerr field in struct cpuhp_step
On Tue, 21 Aug 2018, Mukesh Ojha wrote: > On 8/21/2018 7:27 PM, Thomas Gleixner wrote: > > > If it is specifically was dependent on notifiers, did we missed to remove > > > it as the notifiers are gone or the usecase still there? > > As the comment says > > Thanks for your reply > Sorry, for further question but i did not get the comment ..did you mean, we > can remove this from the structure as notifier are not their now. ? Yes, that's why the comment for that member says: Remove after conversion. > Also if you are aware with the history, can you tell , why would i want to > avoid a call in undo_cpu_up path? Because the notifiers worked completely differently. Go back in the git history where the initial conversion from notifiers to the state machine happened. Thanks, tglx
Re: Query on skip_onerr field in struct cpuhp_step
On Tue, 21 Aug 2018, Mukesh Ojha wrote: > On 8/21/2018 7:27 PM, Thomas Gleixner wrote: > > > If it is specifically was dependent on notifiers, did we missed to remove > > > it as the notifiers are gone or the usecase still there? > > As the comment says > > Thanks for your reply > Sorry, for further question but i did not get the comment ..did you mean, we > can remove this from the structure as notifier are not their now. ? Yes, that's why the comment for that member says: Remove after conversion. > Also if you are aware with the history, can you tell , why would i want to > avoid a call in undo_cpu_up path? Because the notifiers worked completely differently. Go back in the git history where the initial conversion from notifiers to the state machine happened. Thanks, tglx
[PATCH v2] compiler.h: give up __compiletime_assert_fallback()
__compiletime_assert_fallback() is supposed to stop building earlier
by using the negative-array-size method in case the compiler does not
support "error" attribute, but has never worked like that.
You can simply try:
BUILD_BUG_ON(1);
GCC immediately terminates the build, but Clang does not report
anything because Clang does not support the "error" attribute now.
It will later fail at link time, but __compiletime_assert_fallback()
is not working at least.
The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation
of `condition' in BUILD_BUG_ON"). Prior to that commit, BUILD_BUG_ON()
was checked by the negative-array-size method *and* the link-time trick.
Since that commit, the negative-array-size is not effective because
'__cond' is no longer constant. As the comment in
says, GCC (and Clang as well) only emits the error for obvious cases.
When '__cond' is a variable,
((void)sizeof(char[1 - 2 * __cond]))
... is not obvious for the compiler to know the array size is negative.
Reverting that commit would break BUILD_BUG() because negative-size-array
is evaluated before the code is optimized out.
Let's give up __compiletime_assert_fallback(). This commit does not
change the current behavior since it just rips off the useless code.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Nick Desaulniers
---
Changes in v2:
- Rebase
include/linux/compiler.h | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 681d866..87c776c 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -314,29 +314,14 @@ static inline void *offset_to_ptr(const int *off)
#endif
#ifndef __compiletime_error
# define __compiletime_error(message)
-/*
- * Sparse complains of variable sized arrays due to the temporary variable in
- * __compiletime_assert. Unfortunately we can't just expand it out to make
- * sparse see a constant array size without breaking compiletime_assert on old
- * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
- */
-# ifndef __CHECKER__
-# define __compiletime_error_fallback(condition) \
- do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
-# endif
-#endif
-#ifndef __compiletime_error_fallback
-# define __compiletime_error_fallback(condition) do { } while (0)
#endif
#ifdef __OPTIMIZE__
# define __compiletime_assert(condition, msg, prefix, suffix) \
do {\
- int __cond = !(condition); \
extern void prefix ## suffix(void) __compiletime_error(msg); \
- if (__cond) \
+ if (!(condition)) \
prefix ## suffix(); \
- __compiletime_error_fallback(__cond); \
} while (0)
#else
# define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0)
--
2.7.4
[PATCH v2] compiler.h: give up __compiletime_assert_fallback()
__compiletime_assert_fallback() is supposed to stop building earlier
by using the negative-array-size method in case the compiler does not
support "error" attribute, but has never worked like that.
You can simply try:
BUILD_BUG_ON(1);
GCC immediately terminates the build, but Clang does not report
anything because Clang does not support the "error" attribute now.
It will later fail at link time, but __compiletime_assert_fallback()
is not working at least.
The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation
of `condition' in BUILD_BUG_ON"). Prior to that commit, BUILD_BUG_ON()
was checked by the negative-array-size method *and* the link-time trick.
Since that commit, the negative-array-size is not effective because
'__cond' is no longer constant. As the comment in
says, GCC (and Clang as well) only emits the error for obvious cases.
When '__cond' is a variable,
((void)sizeof(char[1 - 2 * __cond]))
... is not obvious for the compiler to know the array size is negative.
Reverting that commit would break BUILD_BUG() because negative-size-array
is evaluated before the code is optimized out.
Let's give up __compiletime_assert_fallback(). This commit does not
change the current behavior since it just rips off the useless code.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Nick Desaulniers
---
Changes in v2:
- Rebase
include/linux/compiler.h | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 681d866..87c776c 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -314,29 +314,14 @@ static inline void *offset_to_ptr(const int *off)
#endif
#ifndef __compiletime_error
# define __compiletime_error(message)
-/*
- * Sparse complains of variable sized arrays due to the temporary variable in
- * __compiletime_assert. Unfortunately we can't just expand it out to make
- * sparse see a constant array size without breaking compiletime_assert on old
- * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
- */
-# ifndef __CHECKER__
-# define __compiletime_error_fallback(condition) \
- do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
-# endif
-#endif
-#ifndef __compiletime_error_fallback
-# define __compiletime_error_fallback(condition) do { } while (0)
#endif
#ifdef __OPTIMIZE__
# define __compiletime_assert(condition, msg, prefix, suffix) \
do {\
- int __cond = !(condition); \
extern void prefix ## suffix(void) __compiletime_error(msg); \
- if (__cond) \
+ if (!(condition)) \
prefix ## suffix(); \
- __compiletime_error_fallback(__cond); \
} while (0)
#else
# define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0)
--
2.7.4
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
Hi Daniel,
2018-08-21 17:11 GMT+09:00 Daniel Santos :
> On 08/19/2018 03:25 PM, Nick Desaulniers wrote:
>> + gbiv who wrote this cool paste (showing alternatives to
>> _Static_assert, which is supported by both compilers in -std=gnu89,
>> but not until gcc 4.6): https://godbolt.org/g/DuLsxu
>>
>> I can't help but think that BUILD_BUG_ON_MSG should use
>> _Static_assert, then have fallbacks for gcc < 4.6.
>
> Unfortunately _Static_assert is a woefully inadequate replacement
> because it requires a C constant expression. Example:
>
> int a = 1;
> _Static_assert(a == 1, "a != 1");
>
> results in "error: expression in static assertion is not constant."
You are right.
I tried diagnose_if from Clang:
static inline void assert_d(int i) __attribute__((diagnose_if(!i, "oh
no", "error")))
{
}
Clang is silent about
int a = 1;
assert_d(a);
But,
if (0)
assert_d(0);
is error.
Hence, it cannot be used for BUILD_BUG().
Anyway, I will just try to rebase this patch and send it to Linus.
> Language standards tend to shy away from defining implementation details
> like optimizations, but we need to have completed a good data flow
> analysis and constant propagation in order to do BUILD_BUG_ON_MSG, et.
> al.; this is why they only work when optimizations are enabled. As the
> optimizer improves, new expressions can be used with BUILD_BUG_ON*. I
> did an analysis of this back in 2012 of how various types of variables
> could be resolved to constants at compile-time and how that evolved from
> gcc 3.4 to 4.7:
>
> https://drive.google.com/open?id=1cQRAAOzjFy6Aw7CDc4QauHvd_spVkd5a
>
> This changed again when -findirect-inline was added -- i.e.,
> BUILD_BUG_ON could be used on parameters of inline functions even when
> called by pointer, although the caller needed __flatten in some cases --
> a bit messy.
>
> Daniel
--
Best Regards
Masahiro Yamada
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
Hi Daniel,
2018-08-21 17:11 GMT+09:00 Daniel Santos :
> On 08/19/2018 03:25 PM, Nick Desaulniers wrote:
>> + gbiv who wrote this cool paste (showing alternatives to
>> _Static_assert, which is supported by both compilers in -std=gnu89,
>> but not until gcc 4.6): https://godbolt.org/g/DuLsxu
>>
>> I can't help but think that BUILD_BUG_ON_MSG should use
>> _Static_assert, then have fallbacks for gcc < 4.6.
>
> Unfortunately _Static_assert is a woefully inadequate replacement
> because it requires a C constant expression. Example:
>
> int a = 1;
> _Static_assert(a == 1, "a != 1");
>
> results in "error: expression in static assertion is not constant."
You are right.
I tried diagnose_if from Clang:
static inline void assert_d(int i) __attribute__((diagnose_if(!i, "oh
no", "error")))
{
}
Clang is silent about
int a = 1;
assert_d(a);
But,
if (0)
assert_d(0);
is error.
Hence, it cannot be used for BUILD_BUG().
Anyway, I will just try to rebase this patch and send it to Linus.
> Language standards tend to shy away from defining implementation details
> like optimizations, but we need to have completed a good data flow
> analysis and constant propagation in order to do BUILD_BUG_ON_MSG, et.
> al.; this is why they only work when optimizations are enabled. As the
> optimizer improves, new expressions can be used with BUILD_BUG_ON*. I
> did an analysis of this back in 2012 of how various types of variables
> could be resolved to constants at compile-time and how that evolved from
> gcc 3.4 to 4.7:
>
> https://drive.google.com/open?id=1cQRAAOzjFy6Aw7CDc4QauHvd_spVkd5a
>
> This changed again when -findirect-inline was added -- i.e.,
> BUILD_BUG_ON could be used on parameters of inline functions even when
> called by pointer, although the caller needed __flatten in some cases --
> a bit messy.
>
> Daniel
--
Best Regards
Masahiro Yamada
[PATCH] pinctrl: ingenic: Fix group & function error checking
Commit a203728ac6bb ("pinctrl: core: Return selector to the pinctrl
driver") and commit f913cfce4ee4 ("pinctrl: pinmux: Return selector to
the pinctrl driver") modified the return values of
pinctrl_generic_add_group() and pinmux_generic_add_function()
respectively, but did so without updating their callers. This broke the
pinctrl-ingenic driver, which treats non-zero return values from these
functions as errors & fails to probe. For example on a MIPS Ci20:
pinctrl-ingenic 1001.pin-controller: Failed to register group uart0-hwflow
pinctrl-ingenic: probe of 1001.pin-controller failed with error 1
Without the pinctrl driver probed, other drivers go on to fail to probe
too & the system is unusable.
Fix this by modifying the error checks to treat only negative values as
errors, matching the commits that introduced the breakage & similar
changes made to other drivers.
Signed-off-by: Paul Burton
Fixes: a203728ac6bb ("pinctrl: core: Return selector to the pinctrl driver")
Fixes: f913cfce4ee4 ("pinctrl: pinmux: Return selector to the pinctrl driver")
Cc: Linus Walleij
Cc: Paul Cercueil
Cc: Tony Lindgren
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pinctrl/pinctrl-ingenic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 6a1b6058b991..628817c40e3b 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -793,7 +793,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinctrl_generic_add_group(jzpc->pctl, group->name,
group->pins, group->num_pins, group->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register group %s\n",
group->name);
return err;
@@ -806,7 +806,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinmux_generic_add_function(jzpc->pctl, func->name,
func->group_names, func->num_group_names,
func->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register function %s\n",
func->name);
return err;
--
2.18.0
[PATCH] pinctrl: ingenic: Fix group & function error checking
Commit a203728ac6bb ("pinctrl: core: Return selector to the pinctrl
driver") and commit f913cfce4ee4 ("pinctrl: pinmux: Return selector to
the pinctrl driver") modified the return values of
pinctrl_generic_add_group() and pinmux_generic_add_function()
respectively, but did so without updating their callers. This broke the
pinctrl-ingenic driver, which treats non-zero return values from these
functions as errors & fails to probe. For example on a MIPS Ci20:
pinctrl-ingenic 1001.pin-controller: Failed to register group uart0-hwflow
pinctrl-ingenic: probe of 1001.pin-controller failed with error 1
Without the pinctrl driver probed, other drivers go on to fail to probe
too & the system is unusable.
Fix this by modifying the error checks to treat only negative values as
errors, matching the commits that introduced the breakage & similar
changes made to other drivers.
Signed-off-by: Paul Burton
Fixes: a203728ac6bb ("pinctrl: core: Return selector to the pinctrl driver")
Fixes: f913cfce4ee4 ("pinctrl: pinmux: Return selector to the pinctrl driver")
Cc: Linus Walleij
Cc: Paul Cercueil
Cc: Tony Lindgren
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pinctrl/pinctrl-ingenic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 6a1b6058b991..628817c40e3b 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -793,7 +793,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinctrl_generic_add_group(jzpc->pctl, group->name,
group->pins, group->num_pins, group->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register group %s\n",
group->name);
return err;
@@ -806,7 +806,7 @@ static int ingenic_pinctrl_probe(struct platform_device
*pdev)
err = pinmux_generic_add_function(jzpc->pctl, func->name,
func->group_names, func->num_group_names,
func->data);
- if (err) {
+ if (err < 0) {
dev_err(dev, "Failed to register function %s\n",
func->name);
return err;
--
2.18.0
[GIT PULL] more Kbuild updates for v4.19
Hi Linus,
Please pull more Kbuild updates.
Thanks.
The following changes since commit ad1d69735878a6bf797705b5d2a20316d35e1113:
Merge tag 'fuse-update-4.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse
(2018-08-21 18:47:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v4.19-2
for you to fetch changes up to d503ac531a5246e4d910f971b213807fea925956:
kbuild: rename LDFLAGS to KBUILD_LDFLAGS (2018-08-24 08:22:08 +0900)
Kbuild updates for v4.19 (2nd)
- add build_{menu,n,g,x}config targets for compile-testing Kconfig
- fix and improve recursive dependency detection in Kconfig
- fix parallel building of menuconfig/nconfig
- fix syntax error in clang-version.sh
- suppress distracting log from syncconfig
- remove obsolete "rpm" target
- remove VMLINUX_SYMBOL(_STR) macro entirely
- fix microblaze build with CONFIG_DYNAMIC_FTRACE
- move compiler test for dead code/data elimination to Kconfig
- rename well-known LDFLAGS variable to KBUILD_LDFLAGS
- misc fixes and cleanups
Andrzej Pietrasiewicz (1):
kbuild: make sorting initramfs contents independent of locale
Masahiro Yamada (13):
scripts/dtc: consolidate include path options in Makefile
kconfig: error out when seeing recursive dependency
kconfig: report recursive dependency involving 'imply'
kconfig: improve the recursive dependency report
kconfig: fix "Can't open ..." in parallel build
kconfig: suppress "configuration written to .config" for syncconfig
kbuild: remove "rpm" target, which is alias of "rpm-pkg"
export.h: remove VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR()
vmlinux.lds.h: remove stale include
initramfs: move gen_initramfs_list.sh from scripts/ to usr/
kbuild: test dead code/data elimination support in Kconfig
kbuild: pass LDFLAGS to recordmcount.pl
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Michael Forney (1):
kbuild: Add a space after `!` to prevent parsing as file pattern
Michal Suchanek (1):
kbuild: Fix LOADLIBES rename in Documentation/kbuild/makefiles.txt
Randy Dunlap (2):
kconfig: add build-only configurator targets
scripts: modpost: check memory allocation results
zhong jiang (1):
Coccinelle: remove pci_alloc_consistent semantic to detect in
zalloc-simple.cocci
Documentation/early-userspace/README | 6 +-
.../filesystems/ramfs-rootfs-initramfs.txt | 2 +-
Documentation/kbuild/kconfig-language.txt | 3 +-
Documentation/kbuild/makefiles.txt | 2 +-
Makefile | 18 ++---
arch/arc/Makefile | 2 +-
arch/arm/Makefile | 4 +-
arch/arm64/Makefile| 4 +-
arch/c6x/Makefile | 3 +-
arch/h8300/Makefile| 2 +-
arch/hexagon/Makefile | 4 +-
arch/m68k/Makefile | 2 +-
arch/microblaze/Makefile | 4 +-
arch/mips/Makefile | 2 +-
arch/mips/boot/compressed/Makefile | 2 +-
arch/mips/lasat/image/Makefile | 2 +-
arch/nds32/Makefile| 4 +-
arch/powerpc/Makefile | 6 +-
arch/riscv/Makefile| 4 +-
arch/s390/Makefile | 2 +-
arch/sh/Makefile | 4 +-
arch/sparc/Makefile| 4 +-
arch/um/Makefile | 2 +-
arch/x86/Makefile | 4 +-
arch/x86/Makefile.um | 4 +-
arch/x86/boot/compressed/Makefile | 6 +-
arch/xtensa/Makefile | 2 +-
arch/xtensa/boot/boot-elf/Makefile | 2 +-
certs/system_certificates.S| 16 ++---
include/asm-generic/vmlinux.lds.h | 2 -
include/linux/export.h | 7 --
init/Kconfig | 2 +
scripts/Kbuild.include | 4 +-
scripts/Makefile.build | 6 +-
scripts/Makefile.lib | 2 +-
scripts/Makefile.modpost | 2 +-
scripts/clang-version.sh | 2 +-
.../api/alloc/zalloc-simple.cocci | 41 +---
scripts/dtc/Makefile | 18 ++---
scripts/kconfig/Makefile | 16 -
scripts/kconfig/conf.c | 5 ++
scripts/kconfig/symbol.c | 58 -
.../Kconfig| 3 +-
.../tests/err_recursive_dep/__init__.py| 10 +++
.../err_recursive_dep/expected_stderr | 38 +++
.../tests/warn_recursive_dep/__init__.py | 9 ---
[GIT PULL] more Kbuild updates for v4.19
Hi Linus,
Please pull more Kbuild updates.
Thanks.
The following changes since commit ad1d69735878a6bf797705b5d2a20316d35e1113:
Merge tag 'fuse-update-4.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse
(2018-08-21 18:47:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v4.19-2
for you to fetch changes up to d503ac531a5246e4d910f971b213807fea925956:
kbuild: rename LDFLAGS to KBUILD_LDFLAGS (2018-08-24 08:22:08 +0900)
Kbuild updates for v4.19 (2nd)
- add build_{menu,n,g,x}config targets for compile-testing Kconfig
- fix and improve recursive dependency detection in Kconfig
- fix parallel building of menuconfig/nconfig
- fix syntax error in clang-version.sh
- suppress distracting log from syncconfig
- remove obsolete "rpm" target
- remove VMLINUX_SYMBOL(_STR) macro entirely
- fix microblaze build with CONFIG_DYNAMIC_FTRACE
- move compiler test for dead code/data elimination to Kconfig
- rename well-known LDFLAGS variable to KBUILD_LDFLAGS
- misc fixes and cleanups
Andrzej Pietrasiewicz (1):
kbuild: make sorting initramfs contents independent of locale
Masahiro Yamada (13):
scripts/dtc: consolidate include path options in Makefile
kconfig: error out when seeing recursive dependency
kconfig: report recursive dependency involving 'imply'
kconfig: improve the recursive dependency report
kconfig: fix "Can't open ..." in parallel build
kconfig: suppress "configuration written to .config" for syncconfig
kbuild: remove "rpm" target, which is alias of "rpm-pkg"
export.h: remove VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR()
vmlinux.lds.h: remove stale include
initramfs: move gen_initramfs_list.sh from scripts/ to usr/
kbuild: test dead code/data elimination support in Kconfig
kbuild: pass LDFLAGS to recordmcount.pl
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Michael Forney (1):
kbuild: Add a space after `!` to prevent parsing as file pattern
Michal Suchanek (1):
kbuild: Fix LOADLIBES rename in Documentation/kbuild/makefiles.txt
Randy Dunlap (2):
kconfig: add build-only configurator targets
scripts: modpost: check memory allocation results
zhong jiang (1):
Coccinelle: remove pci_alloc_consistent semantic to detect in
zalloc-simple.cocci
Documentation/early-userspace/README | 6 +-
.../filesystems/ramfs-rootfs-initramfs.txt | 2 +-
Documentation/kbuild/kconfig-language.txt | 3 +-
Documentation/kbuild/makefiles.txt | 2 +-
Makefile | 18 ++---
arch/arc/Makefile | 2 +-
arch/arm/Makefile | 4 +-
arch/arm64/Makefile| 4 +-
arch/c6x/Makefile | 3 +-
arch/h8300/Makefile| 2 +-
arch/hexagon/Makefile | 4 +-
arch/m68k/Makefile | 2 +-
arch/microblaze/Makefile | 4 +-
arch/mips/Makefile | 2 +-
arch/mips/boot/compressed/Makefile | 2 +-
arch/mips/lasat/image/Makefile | 2 +-
arch/nds32/Makefile| 4 +-
arch/powerpc/Makefile | 6 +-
arch/riscv/Makefile| 4 +-
arch/s390/Makefile | 2 +-
arch/sh/Makefile | 4 +-
arch/sparc/Makefile| 4 +-
arch/um/Makefile | 2 +-
arch/x86/Makefile | 4 +-
arch/x86/Makefile.um | 4 +-
arch/x86/boot/compressed/Makefile | 6 +-
arch/xtensa/Makefile | 2 +-
arch/xtensa/boot/boot-elf/Makefile | 2 +-
certs/system_certificates.S| 16 ++---
include/asm-generic/vmlinux.lds.h | 2 -
include/linux/export.h | 7 --
init/Kconfig | 2 +
scripts/Kbuild.include | 4 +-
scripts/Makefile.build | 6 +-
scripts/Makefile.lib | 2 +-
scripts/Makefile.modpost | 2 +-
scripts/clang-version.sh | 2 +-
.../api/alloc/zalloc-simple.cocci | 41 +---
scripts/dtc/Makefile | 18 ++---
scripts/kconfig/Makefile | 16 -
scripts/kconfig/conf.c | 5 ++
scripts/kconfig/symbol.c | 58 -
.../Kconfig| 3 +-
.../tests/err_recursive_dep/__init__.py| 10 +++
.../err_recursive_dep/expected_stderr | 38 +++
.../tests/warn_recursive_dep/__init__.py | 9 ---
Re: [PATCH 1/7] dt-bindings: Add DT bindings documentation for Allwinner Thermal Sensor Controller
Hi, On Fri, 24 Aug 2018 16:03:40 -0700 Eduardo Valentin wrote: > On Fri, Aug 24, 2018 at 09:59:21PM +0200, Emmanuel Vadot wrote: > > > > Hi, > > > > On Fri, 24 Aug 2018 16:58:40 +0200 > > Maxime Ripard wrote: > > > > > Hi, > > > > > > On Mon, Aug 20, 2018 at 04:27:15PM +0200, Emmanuel Vadot wrote: > > > > On Mon, 20 Aug 2018 16:07:37 +0200 > > > > Maxime Ripard wrote: > > > > > > > > > On Mon, Aug 20, 2018 at 07:41:22AM -0600, Rob Herring wrote: > > > > > > On Mon, Aug 20, 2018 at 5:17 AM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Aug 04, 2018 at 09:03:49AM +0200, Emmanuel Vadot wrote: > > > > > > > > This patch adds documentation for Device-Tree bindings for the > > > > > > > > Allwinner > > > > > > > > Thermal Sensor Controller found on the H3, H5 and A64 SoCs > > > > > > > > > > > > > > > > Signed-off-by: Emmanuel Vadot > > > > > > > > > > > > > > I'm not going to merge a binding for a device that doesn't have > > > > > > > any > > > > > > > driver implemented at the moment in Linux. > > > > > > > > > > > > I'll take it then. Linux is not the only DT client. > > > > > > > > > > Then don't complain if we ever have to break the ABI. We never tested > > > > > that hardware, never had any code running on it, and it *will* cause > > > > > some issues. For example, the calibration data have never been used > > > > > and how they should be represented have never been described, since no > > > > > one ever actually tried to use it. > > > > > > > > > > And sure, Linux is not the only DT client. Just like FreeBSD isn't. > > > > > > > > What kind of data would you need for me to make things better ? > > > > We have the driver in FreeBSD for almost two years now, whne I started > > > > to see how to upstream it I noticed a lot of problems and spent 4 or 5 > > > > days to try on all the SoCs mentionned in the serie, the only SoC I > > > > didn't include it the A83T as for some reason I couldn't make the > > > > driver work. > > > > > > Do you have a link to that driver? > > > > > > https://github.com/freebsd/freebsd/blob/master/sys/arm/allwinner/aw_thermal.c > > > > > How and how much did you test it? > > > > Using a cheap IR thermometer as it's all I can afford. > > Then running multiples cpufreq-a53 process and comparing the result. > > Did the same without using the calibration data, result where closer > > when I used them. > > > > > Are you using the calibration data stored in the SID? > > > > Yes, which is why the serie contain the nvmem cell for the SID. > > > > > > > > > I just hope that you understand that we cannot wait for Linux to > > > > have a driver to have some bindings. > > > > > > Just like I'm sure you can understand that just merging the DT bits > > > without testing anything caused some troubles in the past, and I don't > > > want to discover it in a year from now. > > > > I do, I don't like wrong DT info as much as you do I think. I had > > the unfortunate event to find that the sun4i-a10-timer compatible used > > in every soc is plain wrong for !A10 and !A13, patches comming soon. > > I want those bits merged but I also want that they reflect reality, > > this is not a hard driver to do, NetBSD also have one I think, maybe > > OpenBSD do to. > > > I would prefer to see a series of DT bindings + driver. Can you send > your next iteration with the driver so we can review both together? You mean a link to the FreeBSD driver (and OpenBSD since they have one too) in the cover letter ? > > > > > Maxime > > > > > > -- > > > Maxime Ripard, Bootlin > > > Embedded Linux and Kernel engineering > > > https://bootlin.com > > > > > > -- > > Emmanuel Vadot > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Emmanuel Vadot
Re: [PATCH 1/7] dt-bindings: Add DT bindings documentation for Allwinner Thermal Sensor Controller
Hi, On Fri, 24 Aug 2018 16:03:40 -0700 Eduardo Valentin wrote: > On Fri, Aug 24, 2018 at 09:59:21PM +0200, Emmanuel Vadot wrote: > > > > Hi, > > > > On Fri, 24 Aug 2018 16:58:40 +0200 > > Maxime Ripard wrote: > > > > > Hi, > > > > > > On Mon, Aug 20, 2018 at 04:27:15PM +0200, Emmanuel Vadot wrote: > > > > On Mon, 20 Aug 2018 16:07:37 +0200 > > > > Maxime Ripard wrote: > > > > > > > > > On Mon, Aug 20, 2018 at 07:41:22AM -0600, Rob Herring wrote: > > > > > > On Mon, Aug 20, 2018 at 5:17 AM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Aug 04, 2018 at 09:03:49AM +0200, Emmanuel Vadot wrote: > > > > > > > > This patch adds documentation for Device-Tree bindings for the > > > > > > > > Allwinner > > > > > > > > Thermal Sensor Controller found on the H3, H5 and A64 SoCs > > > > > > > > > > > > > > > > Signed-off-by: Emmanuel Vadot > > > > > > > > > > > > > > I'm not going to merge a binding for a device that doesn't have > > > > > > > any > > > > > > > driver implemented at the moment in Linux. > > > > > > > > > > > > I'll take it then. Linux is not the only DT client. > > > > > > > > > > Then don't complain if we ever have to break the ABI. We never tested > > > > > that hardware, never had any code running on it, and it *will* cause > > > > > some issues. For example, the calibration data have never been used > > > > > and how they should be represented have never been described, since no > > > > > one ever actually tried to use it. > > > > > > > > > > And sure, Linux is not the only DT client. Just like FreeBSD isn't. > > > > > > > > What kind of data would you need for me to make things better ? > > > > We have the driver in FreeBSD for almost two years now, whne I started > > > > to see how to upstream it I noticed a lot of problems and spent 4 or 5 > > > > days to try on all the SoCs mentionned in the serie, the only SoC I > > > > didn't include it the A83T as for some reason I couldn't make the > > > > driver work. > > > > > > Do you have a link to that driver? > > > > > > https://github.com/freebsd/freebsd/blob/master/sys/arm/allwinner/aw_thermal.c > > > > > How and how much did you test it? > > > > Using a cheap IR thermometer as it's all I can afford. > > Then running multiples cpufreq-a53 process and comparing the result. > > Did the same without using the calibration data, result where closer > > when I used them. > > > > > Are you using the calibration data stored in the SID? > > > > Yes, which is why the serie contain the nvmem cell for the SID. > > > > > > > > > I just hope that you understand that we cannot wait for Linux to > > > > have a driver to have some bindings. > > > > > > Just like I'm sure you can understand that just merging the DT bits > > > without testing anything caused some troubles in the past, and I don't > > > want to discover it in a year from now. > > > > I do, I don't like wrong DT info as much as you do I think. I had > > the unfortunate event to find that the sun4i-a10-timer compatible used > > in every soc is plain wrong for !A10 and !A13, patches comming soon. > > I want those bits merged but I also want that they reflect reality, > > this is not a hard driver to do, NetBSD also have one I think, maybe > > OpenBSD do to. > > > I would prefer to see a series of DT bindings + driver. Can you send > your next iteration with the driver so we can review both together? You mean a link to the FreeBSD driver (and OpenBSD since they have one too) in the cover letter ? > > > > > Maxime > > > > > > -- > > > Maxime Ripard, Bootlin > > > Embedded Linux and Kernel engineering > > > https://bootlin.com > > > > > > -- > > Emmanuel Vadot > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Emmanuel Vadot
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
On Sat, Aug 25, 2018 at 06:50:15AM -0700, Andi Kleen wrote: > From: Andi Kleen > > Patch for stable only to fix boot resets caused by the L1TF patches. > > Stable trees reverted the following patch > > Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" > > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. > > but the L1TF patch backported here > >x86/mm/pat: Make set_memory_np() L1TF safe > > commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream > > set_memory_np() is used to mark kernel mappings not present, but it has > it's own open coded mechanism which does not have the L1TF protection of > inverting the address bits. > > assumed that cpa->pfn contains a PFN. With the above patch reverted > it does not, which causes the PMD to be set to an incorrect address > shifted by 12 bits, which can cause early boot reset on some > systems, like an Apollo Lake embedded system. > > Convert the address to a PFN before passing it to pmd_pfn() > > Thanks to Bernhard for bisecting and testing. > > Cc: sta...@vger.kernel.org # 4.4 and 4.9 > Reported-by: Bernhard Kaindl > Tested-by: Bernhard Kaindl > Signed-off-by: Andi Kleen > --- > arch/x86/mm/pageattr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for this, now queued up. greg k-h
Re: [PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
On Sat, Aug 25, 2018 at 06:50:15AM -0700, Andi Kleen wrote: > From: Andi Kleen > > Patch for stable only to fix boot resets caused by the L1TF patches. > > Stable trees reverted the following patch > > Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" > > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. > > but the L1TF patch backported here > >x86/mm/pat: Make set_memory_np() L1TF safe > > commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream > > set_memory_np() is used to mark kernel mappings not present, but it has > it's own open coded mechanism which does not have the L1TF protection of > inverting the address bits. > > assumed that cpa->pfn contains a PFN. With the above patch reverted > it does not, which causes the PMD to be set to an incorrect address > shifted by 12 bits, which can cause early boot reset on some > systems, like an Apollo Lake embedded system. > > Convert the address to a PFN before passing it to pmd_pfn() > > Thanks to Bernhard for bisecting and testing. > > Cc: sta...@vger.kernel.org # 4.4 and 4.9 > Reported-by: Bernhard Kaindl > Tested-by: Bernhard Kaindl > Signed-off-by: Andi Kleen > --- > arch/x86/mm/pageattr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for this, now queued up. greg k-h
TRADING ACCOUNT
Dear sir , I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL .Our Company specialised in Supplying computer hardware and Electronic .We want to extend our supplier list because of concurrency in prices on the international market. We are seeking a supplier with whom we can to have partnered long-term in order to have competitive prices . we are interested to buy the products you sell and want to place an order with you in big quantities. Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) ? What is the procedure for our account opening and credit line application ? Cordially KELLY ALAN CFM INTERNATIONAL 2 BOULEVARD DU GAL MARTIAL VALIN 75015 PARIS REG N° 302 527 700 VAT N° FR90 302527700 TEL +33171025367 FAX +33177759149 https://www.cfmaeroengines.com
TRADING ACCOUNT
Dear sir , I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL .Our Company specialised in Supplying computer hardware and Electronic .We want to extend our supplier list because of concurrency in prices on the international market. We are seeking a supplier with whom we can to have partnered long-term in order to have competitive prices . we are interested to buy the products you sell and want to place an order with you in big quantities. Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) ? What is the procedure for our account opening and credit line application ? Cordially KELLY ALAN CFM INTERNATIONAL 2 BOULEVARD DU GAL MARTIAL VALIN 75015 PARIS REG N° 302 527 700 VAT N° FR90 302527700 TEL +33171025367 FAX +33177759149 https://www.cfmaeroengines.com
Re: [PATCH] MIPS: BCM47XX: Enable USB power on Netgear WNDR3400v3
On 08/19/2018 09:20 PM, Tuomas Tynkkynen wrote:
> Setting GPIO 21 high seems to be required to enable power to USB ports
> on the WNDR3400v3. As there is already similar code for WNR3500L,
> make the existing USB power GPIO code generic and use that.
>
> Signed-off-by: Tuomas Tynkkynen
I didn't runtime tested this and didn't checked the board, but this
looks good.
Acked-by: Hauke Mehrtens
> ---
> arch/mips/bcm47xx/workarounds.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c
> index 1a8a07e7a563..46eddbec8d9f 100644
> --- a/arch/mips/bcm47xx/workarounds.c
> +++ b/arch/mips/bcm47xx/workarounds.c
> @@ -5,9 +5,8 @@
> #include
> #include
>
> -static void __init bcm47xx_workarounds_netgear_wnr3500l(void)
> +static void __init bcm47xx_workarounds_enable_usb_power(int usb_power)
> {
> - const int usb_power = 12;
> int err;
>
> err = gpio_request_one(usb_power, GPIOF_OUT_INIT_HIGH, "usb_power");
> @@ -23,7 +22,10 @@ void __init bcm47xx_workarounds(void)
>
> switch (board) {
> case BCM47XX_BOARD_NETGEAR_WNR3500L:
> - bcm47xx_workarounds_netgear_wnr3500l();
> + bcm47xx_workarounds_enable_usb_power(12);
> + break;
> + case BCM47XX_BOARD_NETGEAR_WNDR3400_V3:
> + bcm47xx_workarounds_enable_usb_power(21);
> break;
> default:
> /* No workaround(s) needed */
>
Re: [PATCH] MIPS: BCM47XX: Enable USB power on Netgear WNDR3400v3
On 08/19/2018 09:20 PM, Tuomas Tynkkynen wrote:
> Setting GPIO 21 high seems to be required to enable power to USB ports
> on the WNDR3400v3. As there is already similar code for WNR3500L,
> make the existing USB power GPIO code generic and use that.
>
> Signed-off-by: Tuomas Tynkkynen
I didn't runtime tested this and didn't checked the board, but this
looks good.
Acked-by: Hauke Mehrtens
> ---
> arch/mips/bcm47xx/workarounds.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c
> index 1a8a07e7a563..46eddbec8d9f 100644
> --- a/arch/mips/bcm47xx/workarounds.c
> +++ b/arch/mips/bcm47xx/workarounds.c
> @@ -5,9 +5,8 @@
> #include
> #include
>
> -static void __init bcm47xx_workarounds_netgear_wnr3500l(void)
> +static void __init bcm47xx_workarounds_enable_usb_power(int usb_power)
> {
> - const int usb_power = 12;
> int err;
>
> err = gpio_request_one(usb_power, GPIOF_OUT_INIT_HIGH, "usb_power");
> @@ -23,7 +22,10 @@ void __init bcm47xx_workarounds(void)
>
> switch (board) {
> case BCM47XX_BOARD_NETGEAR_WNR3500L:
> - bcm47xx_workarounds_netgear_wnr3500l();
> + bcm47xx_workarounds_enable_usb_power(12);
> + break;
> + case BCM47XX_BOARD_NETGEAR_WNDR3400_V3:
> + bcm47xx_workarounds_enable_usb_power(21);
> break;
> default:
> /* No workaround(s) needed */
>
Re: [PATCHv2 2/2] phy:phy-lantiq-rcu-usb2: Use PTR_ERR_OR_ZERO to replace the open coded version
On 08/16/2018 05:58 PM, zhong jiang wrote: > PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So > just replace them rather than duplicating its implement. > > Signed-off-by: zhong jiang Acked-by: Hauke Mehrtens > --- > drivers/phy/lantiq/phy-lantiq-rcu-usb2.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > index 986224f..a918c5b 100644 > --- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > +++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > @@ -196,10 +196,8 @@ static int ltq_rcu_usb2_of_parse(struct > ltq_rcu_usb2_priv *priv, > } > > priv->phy_reset = devm_reset_control_get_optional(dev, "phy"); > - if (IS_ERR(priv->phy_reset)) > - return PTR_ERR(priv->phy_reset); > > - return 0; > + return PTR_ERR_OR_ZERO(priv->phy_reset); > } > > static int ltq_rcu_usb2_phy_probe(struct platform_device *pdev) >
Re: [PATCHv2 2/2] phy:phy-lantiq-rcu-usb2: Use PTR_ERR_OR_ZERO to replace the open coded version
On 08/16/2018 05:58 PM, zhong jiang wrote: > PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So > just replace them rather than duplicating its implement. > > Signed-off-by: zhong jiang Acked-by: Hauke Mehrtens > --- > drivers/phy/lantiq/phy-lantiq-rcu-usb2.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > index 986224f..a918c5b 100644 > --- a/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > +++ b/drivers/phy/lantiq/phy-lantiq-rcu-usb2.c > @@ -196,10 +196,8 @@ static int ltq_rcu_usb2_of_parse(struct > ltq_rcu_usb2_priv *priv, > } > > priv->phy_reset = devm_reset_control_get_optional(dev, "phy"); > - if (IS_ERR(priv->phy_reset)) > - return PTR_ERR(priv->phy_reset); > > - return 0; > + return PTR_ERR_OR_ZERO(priv->phy_reset); > } > > static int ltq_rcu_usb2_phy_probe(struct platform_device *pdev) >
[PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
From: Andi Kleen Patch for stable only to fix boot resets caused by the L1TF patches. Stable trees reverted the following patch Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. but the L1TF patch backported here x86/mm/pat: Make set_memory_np() L1TF safe commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream set_memory_np() is used to mark kernel mappings not present, but it has it's own open coded mechanism which does not have the L1TF protection of inverting the address bits. assumed that cpa->pfn contains a PFN. With the above patch reverted it does not, which causes the PMD to be set to an incorrect address shifted by 12 bits, which can cause early boot reset on some systems, like an Apollo Lake embedded system. Convert the address to a PFN before passing it to pmd_pfn() Thanks to Bernhard for bisecting and testing. Cc: sta...@vger.kernel.org # 4.4 and 4.9 Reported-by: Bernhard Kaindl Tested-by: Bernhard Kaindl Signed-off-by: Andi Kleen --- arch/x86/mm/pageattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 27610c2d1821..1007fa80f5a6 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -1006,7 +1006,7 @@ static int populate_pmd(struct cpa_data *cpa, pmd = pmd_offset(pud, start); - set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn, + set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn >> PAGE_SHIFT, canon_pgprot(pmd_pgprot; start += PMD_SIZE; -- 2.17.1
[PATCH] x86/mm/pat: Fix L1TF stable backport for CPA
From: Andi Kleen Patch for stable only to fix boot resets caused by the L1TF patches. Stable trees reverted the following patch Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers" This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream. but the L1TF patch backported here x86/mm/pat: Make set_memory_np() L1TF safe commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream set_memory_np() is used to mark kernel mappings not present, but it has it's own open coded mechanism which does not have the L1TF protection of inverting the address bits. assumed that cpa->pfn contains a PFN. With the above patch reverted it does not, which causes the PMD to be set to an incorrect address shifted by 12 bits, which can cause early boot reset on some systems, like an Apollo Lake embedded system. Convert the address to a PFN before passing it to pmd_pfn() Thanks to Bernhard for bisecting and testing. Cc: sta...@vger.kernel.org # 4.4 and 4.9 Reported-by: Bernhard Kaindl Tested-by: Bernhard Kaindl Signed-off-by: Andi Kleen --- arch/x86/mm/pageattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 27610c2d1821..1007fa80f5a6 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -1006,7 +1006,7 @@ static int populate_pmd(struct cpa_data *cpa, pmd = pmd_offset(pud, start); - set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn, + set_pmd(pmd, pmd_mkhuge(pfn_pmd(cpa->pfn >> PAGE_SHIFT, canon_pgprot(pmd_pgprot; start += PMD_SIZE; -- 2.17.1
Re: [PATCH] cpuidle: menu: Retain tick when shallow state is selected
On Fri, Aug 24, 2018 at 5:52 PM Doug Smythies wrote: > > On 2018.08.24 02:44 Rafael J. Wysocki wrote: > > On Tuesday, August 21, 2018 10:44:10 AM CEST Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki > >> > >> The case addressed by commit 5ef499cd571c (cpuidle: menu: Handle > >> stopped tick more aggressively) in the stopped tick case is present > >> when the tick has not been stopped yet too. > > ... [snip] ... > > >> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with > >> stopped tick) > > ... [snip] ... > > > Due to the lack of objections, I'm inclined to queue this up. > > I have been following these threads. > Recall that I was involved, over a period of months, in the original > "powernightmare" stuff. > I have revived my tests (and wish I had left myself better notes), and > am establishing a baseline before adding and trying this patch. > My baseline is actually two tests with and without the previous two patches > (the ones > that were just sent a couple of days ago in "More power management updates > for v4.19-rc1". > I might have those results in some presentable form by later today (it looks > O.K.) > Results with this patch will take another couple of days. Thanks Doug, much appreciated! This patch has been queued up, but I will wait for your results for a few days before pushing it. Cheers, Rafael
Re: [PATCH] cpuidle: menu: Retain tick when shallow state is selected
On Fri, Aug 24, 2018 at 5:52 PM Doug Smythies wrote: > > On 2018.08.24 02:44 Rafael J. Wysocki wrote: > > On Tuesday, August 21, 2018 10:44:10 AM CEST Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki > >> > >> The case addressed by commit 5ef499cd571c (cpuidle: menu: Handle > >> stopped tick more aggressively) in the stopped tick case is present > >> when the tick has not been stopped yet too. > > ... [snip] ... > > >> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with > >> stopped tick) > > ... [snip] ... > > > Due to the lack of objections, I'm inclined to queue this up. > > I have been following these threads. > Recall that I was involved, over a period of months, in the original > "powernightmare" stuff. > I have revived my tests (and wish I had left myself better notes), and > am establishing a baseline before adding and trying this patch. > My baseline is actually two tests with and without the previous two patches > (the ones > that were just sent a couple of days ago in "More power management updates > for v4.19-rc1". > I might have those results in some presentable form by later today (it looks > O.K.) > Results with this patch will take another couple of days. Thanks Doug, much appreciated! This patch has been queued up, but I will wait for your results for a few days before pushing it. Cheers, Rafael
Disabling CPU vulnerabilities workarounds
Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Disabling is a good option for strictly confined environments where no 3d party untrusted code is ever to be run, e.g. a rendering farm, a supercomputer, or even a home server which runs Samba/SSH server and nothing else. I wonder if someone could wrote a patch which implemented the following two options for the kernel: * A boot option option which allows to disable most runtime protections/workarounds/fixes (as far as I understand some of them can't be reverted since they are compiled in or use certain GCC flags), e.g. let's call it "insecure" or "insecurecpumode". * A compile-time CONFIG_ option which disables all these fixes _permanently_ without a way to turn them later back on during runtime. Right now linux/Documentation/admin-guide/kernel-parameters.txt is a mess of various things which take ages to sift through and there's zero understanding whether you've found everything and correctly disabled it. Best regards, Artem
Disabling CPU vulnerabilities workarounds
Hello LKML, As time goes by more and more fixes of Intel/AMD/ARM CPUs vulnerabilities are added to the Linux kernel without a simple way to disable them all in one fell swoop. Disabling is a good option for strictly confined environments where no 3d party untrusted code is ever to be run, e.g. a rendering farm, a supercomputer, or even a home server which runs Samba/SSH server and nothing else. I wonder if someone could wrote a patch which implemented the following two options for the kernel: * A boot option option which allows to disable most runtime protections/workarounds/fixes (as far as I understand some of them can't be reverted since they are compiled in or use certain GCC flags), e.g. let's call it "insecure" or "insecurecpumode". * A compile-time CONFIG_ option which disables all these fixes _permanently_ without a way to turn them later back on during runtime. Right now linux/Documentation/admin-guide/kernel-parameters.txt is a mess of various things which take ages to sift through and there's zero understanding whether you've found everything and correctly disabled it. Best regards, Artem
Re: [PATCH] iio: dac: ti-dac5571: provide of_match_table to driver
On Fri, 24 Aug 2018 22:24:59 +0200
Marcus Folkesson wrote:
> Use the created list of of_device_id's as a match table.
>
> Signed-off-by: Marcus Folkesson
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Technically this isn't a regression as it will fall back to the oldschool
i2c matching (which hasn't gone away yet). Hence I don't plan to send it
as a fix during the cycle.
Jonathan
> ---
> drivers/iio/dac/ti-dac5571.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/dac/ti-dac5571.c b/drivers/iio/dac/ti-dac5571.c
> index e39d1e901353..f6dcd8bce2b0 100644
> --- a/drivers/iio/dac/ti-dac5571.c
> +++ b/drivers/iio/dac/ti-dac5571.c
> @@ -421,6 +421,7 @@ MODULE_DEVICE_TABLE(i2c, dac5571_id);
> static struct i2c_driver dac5571_driver = {
> .driver = {
> .name = "ti-dac5571",
> +.of_match_table = of_match_ptr(dac5571_of_id),
> },
> .probe= dac5571_probe,
> .remove = dac5571_remove,
Re: [PATCH] iio: dac: ti-dac5571: provide of_match_table to driver
On Fri, 24 Aug 2018 22:24:59 +0200
Marcus Folkesson wrote:
> Use the created list of of_device_id's as a match table.
>
> Signed-off-by: Marcus Folkesson
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Technically this isn't a regression as it will fall back to the oldschool
i2c matching (which hasn't gone away yet). Hence I don't plan to send it
as a fix during the cycle.
Jonathan
> ---
> drivers/iio/dac/ti-dac5571.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/dac/ti-dac5571.c b/drivers/iio/dac/ti-dac5571.c
> index e39d1e901353..f6dcd8bce2b0 100644
> --- a/drivers/iio/dac/ti-dac5571.c
> +++ b/drivers/iio/dac/ti-dac5571.c
> @@ -421,6 +421,7 @@ MODULE_DEVICE_TABLE(i2c, dac5571_id);
> static struct i2c_driver dac5571_driver = {
> .driver = {
> .name = "ti-dac5571",
> +.of_match_table = of_match_ptr(dac5571_of_id),
> },
> .probe= dac5571_probe,
> .remove = dac5571_remove,
Re: [PATCH] iio: dac: ti-dac5571: make vref regulator optional
On Fri, 24 Aug 2018 22:24:47 +0200
Marcus Folkesson wrote:
> The `vref` regulator is declared as optional in the device-tree binding,
> but the driver does require it.
>
> Go for the device-tree binding and make the `vref` regulator optional.
>
> Signed-off-by: Marcus Folkesson
Hmm.
If you do a voltage get on a stub regulator it will return an
error (IIRC).
So I am unconvinced this actually makes any real difference?
What am I missing?
Jonathan
> ---
> drivers/iio/dac/ti-dac5571.c | 30 ++
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/dac/ti-dac5571.c b/drivers/iio/dac/ti-dac5571.c
> index f6dcd8bce2b0..bf21cc312096 100644
> --- a/drivers/iio/dac/ti-dac5571.c
> +++ b/drivers/iio/dac/ti-dac5571.c
> @@ -251,6 +251,9 @@ static int dac5571_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
>
> case IIO_CHAN_INFO_SCALE:
> + if (!data->vref)
> + return -EOPNOTSUPP;
> +
> ret = regulator_get_voltage(data->vref);
> if (ret < 0)
> return ret;
> @@ -335,13 +338,21 @@ static int dac5571_probe(struct i2c_client *client,
> indio_dev->num_channels = spec->num_channels;
> data->spec = spec;
>
> - data->vref = devm_regulator_get(dev, "vref");
> - if (IS_ERR(data->vref))
> - return PTR_ERR(data->vref);
> + data->vref = devm_regulator_get_optional(dev, "vref");
> + if (IS_ERR(data->vref)) {
> + if (PTR_ERR(data->vref) == -ENODEV) {
> + data->vref = NULL;
> + } else {
> + dev_err(dev, "failed to get regulator (%ld)\n",
> + PTR_ERR(data->vref));
> + return PTR_ERR(data->vref);
That is as likely as not a deferred probe so it should not be
as noisy as this. It may happen during a normal boot process a lot
of times.
> + }
>
> - ret = regulator_enable(data->vref);
> - if (ret < 0)
> - return ret;
> + } else {
> + ret = regulator_enable(data->vref);
> + if (ret)
> + return ret;
> + }
>
> mutex_init(>lock);
>
> @@ -373,7 +384,9 @@ static int dac5571_probe(struct i2c_client *client,
> return 0;
>
> err:
> - regulator_disable(data->vref);
> + if (data->vref)
> + regulator_disable(data->vref);
> +
> return ret;
> }
>
> @@ -383,7 +396,8 @@ static int dac5571_remove(struct i2c_client *i2c)
> struct dac5571_data *data = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> - regulator_disable(data->vref);
> + if (data->vref)
> + regulator_disable(data->vref);
>
> return 0;
> }
Re: [PATCH] iio: dac: ti-dac5571: make vref regulator optional
On Fri, 24 Aug 2018 22:24:47 +0200
Marcus Folkesson wrote:
> The `vref` regulator is declared as optional in the device-tree binding,
> but the driver does require it.
>
> Go for the device-tree binding and make the `vref` regulator optional.
>
> Signed-off-by: Marcus Folkesson
Hmm.
If you do a voltage get on a stub regulator it will return an
error (IIRC).
So I am unconvinced this actually makes any real difference?
What am I missing?
Jonathan
> ---
> drivers/iio/dac/ti-dac5571.c | 30 ++
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/dac/ti-dac5571.c b/drivers/iio/dac/ti-dac5571.c
> index f6dcd8bce2b0..bf21cc312096 100644
> --- a/drivers/iio/dac/ti-dac5571.c
> +++ b/drivers/iio/dac/ti-dac5571.c
> @@ -251,6 +251,9 @@ static int dac5571_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
>
> case IIO_CHAN_INFO_SCALE:
> + if (!data->vref)
> + return -EOPNOTSUPP;
> +
> ret = regulator_get_voltage(data->vref);
> if (ret < 0)
> return ret;
> @@ -335,13 +338,21 @@ static int dac5571_probe(struct i2c_client *client,
> indio_dev->num_channels = spec->num_channels;
> data->spec = spec;
>
> - data->vref = devm_regulator_get(dev, "vref");
> - if (IS_ERR(data->vref))
> - return PTR_ERR(data->vref);
> + data->vref = devm_regulator_get_optional(dev, "vref");
> + if (IS_ERR(data->vref)) {
> + if (PTR_ERR(data->vref) == -ENODEV) {
> + data->vref = NULL;
> + } else {
> + dev_err(dev, "failed to get regulator (%ld)\n",
> + PTR_ERR(data->vref));
> + return PTR_ERR(data->vref);
That is as likely as not a deferred probe so it should not be
as noisy as this. It may happen during a normal boot process a lot
of times.
> + }
>
> - ret = regulator_enable(data->vref);
> - if (ret < 0)
> - return ret;
> + } else {
> + ret = regulator_enable(data->vref);
> + if (ret)
> + return ret;
> + }
>
> mutex_init(>lock);
>
> @@ -373,7 +384,9 @@ static int dac5571_probe(struct i2c_client *client,
> return 0;
>
> err:
> - regulator_disable(data->vref);
> + if (data->vref)
> + regulator_disable(data->vref);
> +
> return ret;
> }
>
> @@ -383,7 +396,8 @@ static int dac5571_remove(struct i2c_client *i2c)
> struct dac5571_data *data = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> - regulator_disable(data->vref);
> + if (data->vref)
> + regulator_disable(data->vref);
>
> return 0;
> }
Re: [PATCH] iio: dac: mcp4922: fix error handling in mcp4922_write_raw
On Fri, 24 Aug 2018 22:24:40 +0200
Marcus Folkesson wrote:
> Do not try to write negative values and make sure that the write goes well.
>
+CC Michael as it's his driver.
I'll take this as it 'appears' straight forward but I won't be pushing
it out as a non rebasing branch for a few days if I've missed anything.
Applied to the togreg branch of iio.git and pushed out for now as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> Signed-off-by: Marcus Folkesson
> ---
> drivers/iio/dac/mcp4922.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/dac/mcp4922.c b/drivers/iio/dac/mcp4922.c
> index bf9aa3fc0534..b5190d1dae8e 100644
> --- a/drivers/iio/dac/mcp4922.c
> +++ b/drivers/iio/dac/mcp4922.c
> @@ -94,17 +94,22 @@ static int mcp4922_write_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct mcp4922_state *state = iio_priv(indio_dev);
> + int ret;
>
> if (val2 != 0)
> return -EINVAL;
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> - if (val > GENMASK(chan->scan_type.realbits-1, 0))
> + if (val < 0 || val > GENMASK(chan->scan_type.realbits - 1, 0))
> return -EINVAL;
> val <<= chan->scan_type.shift;
> - state->value[chan->channel] = val;
> - return mcp4922_spi_write(state, chan->channel, val);
> +
> + ret = mcp4922_spi_write(state, chan->channel, val);
> + if (!ret)
> + state->value[chan->channel] = val;
> + return ret;
> +
> default:
> return -EINVAL;
> }
Re: [PATCH] iio: dac: mcp4922: fix error handling in mcp4922_write_raw
On Fri, 24 Aug 2018 22:24:40 +0200
Marcus Folkesson wrote:
> Do not try to write negative values and make sure that the write goes well.
>
+CC Michael as it's his driver.
I'll take this as it 'appears' straight forward but I won't be pushing
it out as a non rebasing branch for a few days if I've missed anything.
Applied to the togreg branch of iio.git and pushed out for now as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> Signed-off-by: Marcus Folkesson
> ---
> drivers/iio/dac/mcp4922.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/dac/mcp4922.c b/drivers/iio/dac/mcp4922.c
> index bf9aa3fc0534..b5190d1dae8e 100644
> --- a/drivers/iio/dac/mcp4922.c
> +++ b/drivers/iio/dac/mcp4922.c
> @@ -94,17 +94,22 @@ static int mcp4922_write_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct mcp4922_state *state = iio_priv(indio_dev);
> + int ret;
>
> if (val2 != 0)
> return -EINVAL;
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> - if (val > GENMASK(chan->scan_type.realbits-1, 0))
> + if (val < 0 || val > GENMASK(chan->scan_type.realbits - 1, 0))
> return -EINVAL;
> val <<= chan->scan_type.shift;
> - state->value[chan->channel] = val;
> - return mcp4922_spi_write(state, chan->channel, val);
> +
> + ret = mcp4922_spi_write(state, chan->channel, val);
> + if (!ret)
> + state->value[chan->channel] = val;
> + return ret;
> +
> default:
> return -EINVAL;
> }
[PATCH v9] ASoC: pxa: switch to new ac97 bus support
Switch to the new ac97 bus support in sound/ac97 instead of the legacy
snd_ac97 one.
Signed-off-by: Robert Jarzmik
---
Since v8: fixed the trivial compilation error
v7 was in https://patchwork.kernel.org/patch/9951919/
---
sound/arm/Kconfig | 1 -
sound/soc/pxa/Kconfig | 5 ++---
sound/soc/pxa/pxa2xx-ac97.c | 48 +++--
3 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/sound/arm/Kconfig b/sound/arm/Kconfig
index 5fbd47a9177e..28867732a318 100644
--- a/sound/arm/Kconfig
+++ b/sound/arm/Kconfig
@@ -31,7 +31,6 @@ endif # SND_ARM
config SND_PXA2XX_LIB
tristate
- select SND_AC97_CODEC if SND_PXA2XX_LIB_AC97
select SND_DMAENGINE_PCM
config SND_PXA2XX_LIB_AC97
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 776e148b0aa2..29f577e6dfc0 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -19,14 +19,13 @@ config SND_MMP_SOC
config SND_PXA2XX_AC97
tristate
- select SND_AC97_CODEC
config SND_PXA2XX_SOC_AC97
tristate
- select AC97_BUS
+ select AC97_BUS_NEW
select SND_PXA2XX_LIB
select SND_PXA2XX_LIB_AC97
- select SND_SOC_AC97_BUS
+ select SND_SOC_AC97_BUS_NEW
config SND_PXA2XX_SOC_I2S
select SND_PXA2XX_LIB
diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
index 9f779657bc86..f8a3aa6c6d4e 100644
--- a/sound/soc/pxa/pxa2xx-ac97.c
+++ b/sound/soc/pxa/pxa2xx-ac97.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -27,43 +28,35 @@
#include
#include
-static void pxa2xx_ac97_warm_reset(struct snd_ac97 *ac97)
+static void pxa2xx_ac97_warm_reset(struct ac97_controller *adrv)
{
pxa2xx_ac97_try_warm_reset();
pxa2xx_ac97_finish_reset();
}
-static void pxa2xx_ac97_cold_reset(struct snd_ac97 *ac97)
+static void pxa2xx_ac97_cold_reset(struct ac97_controller *adrv)
{
pxa2xx_ac97_try_cold_reset();
pxa2xx_ac97_finish_reset();
}
-static unsigned short pxa2xx_ac97_legacy_read(struct snd_ac97 *ac97,
- unsigned short reg)
+static int pxa2xx_ac97_read_actrl(struct ac97_controller *adrv, int slot,
+ unsigned short reg)
{
- int ret;
-
- ret = pxa2xx_ac97_read(ac97->num, reg);
- if (ret < 0)
- return 0;
- else
- return (unsigned short)(ret & 0x);
+ return pxa2xx_ac97_read(slot, reg);
}
-static void pxa2xx_ac97_legacy_write(struct snd_ac97 *ac97,
-unsigned short reg, unsigned short val)
+static int pxa2xx_ac97_write_actrl(struct ac97_controller *adrv, int slot,
+ unsigned short reg, unsigned short val)
{
- int ret;
-
- ret = pxa2xx_ac97_write(ac97->num, reg, val);
+ return pxa2xx_ac97_write(slot, reg, val);
}
-static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
- .read = pxa2xx_ac97_legacy_read,
- .write = pxa2xx_ac97_legacy_write,
+static struct ac97_controller_ops pxa2xx_ac97_ops = {
+ .read = pxa2xx_ac97_read_actrl,
+ .write = pxa2xx_ac97_write_actrl,
.warm_reset = pxa2xx_ac97_warm_reset,
.reset = pxa2xx_ac97_cold_reset,
};
@@ -233,6 +226,9 @@ MODULE_DEVICE_TABLE(of, pxa2xx_ac97_dt_ids);
static int pxa2xx_ac97_dev_probe(struct platform_device *pdev)
{
int ret;
+ struct ac97_controller *ctrl;
+ pxa2xx_audio_ops_t *pdata = pdev->dev.platform_data;
+ void **codecs_pdata;
if (pdev->id != -1) {
dev_err(>dev, "PXA2xx has only one AC97 port.\n");
@@ -245,10 +241,14 @@ static int pxa2xx_ac97_dev_probe(struct platform_device
*pdev)
return ret;
}
- ret = snd_soc_set_ac97_ops(_ac97_ops);
- if (ret != 0)
- return ret;
+ codecs_pdata = pdata ? pdata->codec_pdata : NULL;
+ ctrl = snd_ac97_controller_register(_ac97_ops, >dev,
+ AC97_SLOTS_AVAILABLE_ALL,
+ codecs_pdata);
+ if (IS_ERR(ctrl))
+ return PTR_ERR(ctrl);
+ platform_set_drvdata(pdev, ctrl);
/* Punt most of the init to the SoC probe; we may need the machine
* driver to do interesting things with the clocking to get us up
* and running.
@@ -259,8 +259,10 @@ static int pxa2xx_ac97_dev_probe(struct platform_device
*pdev)
static int pxa2xx_ac97_dev_remove(struct platform_device *pdev)
{
+ struct ac97_controller *ctrl = platform_get_drvdata(pdev);
+
snd_soc_unregister_component(>dev);
- snd_soc_set_ac97_ops(NULL);
+ snd_ac97_controller_unregister(ctrl);
pxa2xx_ac97_hw_remove(pdev);
return 0;
}
--
2.11.0
[PATCH v9] ASoC: pxa: switch to new ac97 bus support
Switch to the new ac97 bus support in sound/ac97 instead of the legacy
snd_ac97 one.
Signed-off-by: Robert Jarzmik
---
Since v8: fixed the trivial compilation error
v7 was in https://patchwork.kernel.org/patch/9951919/
---
sound/arm/Kconfig | 1 -
sound/soc/pxa/Kconfig | 5 ++---
sound/soc/pxa/pxa2xx-ac97.c | 48 +++--
3 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/sound/arm/Kconfig b/sound/arm/Kconfig
index 5fbd47a9177e..28867732a318 100644
--- a/sound/arm/Kconfig
+++ b/sound/arm/Kconfig
@@ -31,7 +31,6 @@ endif # SND_ARM
config SND_PXA2XX_LIB
tristate
- select SND_AC97_CODEC if SND_PXA2XX_LIB_AC97
select SND_DMAENGINE_PCM
config SND_PXA2XX_LIB_AC97
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 776e148b0aa2..29f577e6dfc0 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -19,14 +19,13 @@ config SND_MMP_SOC
config SND_PXA2XX_AC97
tristate
- select SND_AC97_CODEC
config SND_PXA2XX_SOC_AC97
tristate
- select AC97_BUS
+ select AC97_BUS_NEW
select SND_PXA2XX_LIB
select SND_PXA2XX_LIB_AC97
- select SND_SOC_AC97_BUS
+ select SND_SOC_AC97_BUS_NEW
config SND_PXA2XX_SOC_I2S
select SND_PXA2XX_LIB
diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
index 9f779657bc86..f8a3aa6c6d4e 100644
--- a/sound/soc/pxa/pxa2xx-ac97.c
+++ b/sound/soc/pxa/pxa2xx-ac97.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -27,43 +28,35 @@
#include
#include
-static void pxa2xx_ac97_warm_reset(struct snd_ac97 *ac97)
+static void pxa2xx_ac97_warm_reset(struct ac97_controller *adrv)
{
pxa2xx_ac97_try_warm_reset();
pxa2xx_ac97_finish_reset();
}
-static void pxa2xx_ac97_cold_reset(struct snd_ac97 *ac97)
+static void pxa2xx_ac97_cold_reset(struct ac97_controller *adrv)
{
pxa2xx_ac97_try_cold_reset();
pxa2xx_ac97_finish_reset();
}
-static unsigned short pxa2xx_ac97_legacy_read(struct snd_ac97 *ac97,
- unsigned short reg)
+static int pxa2xx_ac97_read_actrl(struct ac97_controller *adrv, int slot,
+ unsigned short reg)
{
- int ret;
-
- ret = pxa2xx_ac97_read(ac97->num, reg);
- if (ret < 0)
- return 0;
- else
- return (unsigned short)(ret & 0x);
+ return pxa2xx_ac97_read(slot, reg);
}
-static void pxa2xx_ac97_legacy_write(struct snd_ac97 *ac97,
-unsigned short reg, unsigned short val)
+static int pxa2xx_ac97_write_actrl(struct ac97_controller *adrv, int slot,
+ unsigned short reg, unsigned short val)
{
- int ret;
-
- ret = pxa2xx_ac97_write(ac97->num, reg, val);
+ return pxa2xx_ac97_write(slot, reg, val);
}
-static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
- .read = pxa2xx_ac97_legacy_read,
- .write = pxa2xx_ac97_legacy_write,
+static struct ac97_controller_ops pxa2xx_ac97_ops = {
+ .read = pxa2xx_ac97_read_actrl,
+ .write = pxa2xx_ac97_write_actrl,
.warm_reset = pxa2xx_ac97_warm_reset,
.reset = pxa2xx_ac97_cold_reset,
};
@@ -233,6 +226,9 @@ MODULE_DEVICE_TABLE(of, pxa2xx_ac97_dt_ids);
static int pxa2xx_ac97_dev_probe(struct platform_device *pdev)
{
int ret;
+ struct ac97_controller *ctrl;
+ pxa2xx_audio_ops_t *pdata = pdev->dev.platform_data;
+ void **codecs_pdata;
if (pdev->id != -1) {
dev_err(>dev, "PXA2xx has only one AC97 port.\n");
@@ -245,10 +241,14 @@ static int pxa2xx_ac97_dev_probe(struct platform_device
*pdev)
return ret;
}
- ret = snd_soc_set_ac97_ops(_ac97_ops);
- if (ret != 0)
- return ret;
+ codecs_pdata = pdata ? pdata->codec_pdata : NULL;
+ ctrl = snd_ac97_controller_register(_ac97_ops, >dev,
+ AC97_SLOTS_AVAILABLE_ALL,
+ codecs_pdata);
+ if (IS_ERR(ctrl))
+ return PTR_ERR(ctrl);
+ platform_set_drvdata(pdev, ctrl);
/* Punt most of the init to the SoC probe; we may need the machine
* driver to do interesting things with the clocking to get us up
* and running.
@@ -259,8 +259,10 @@ static int pxa2xx_ac97_dev_probe(struct platform_device
*pdev)
static int pxa2xx_ac97_dev_remove(struct platform_device *pdev)
{
+ struct ac97_controller *ctrl = platform_get_drvdata(pdev);
+
snd_soc_unregister_component(>dev);
- snd_soc_set_ac97_ops(NULL);
+ snd_ac97_controller_unregister(ctrl);
pxa2xx_ac97_hw_remove(pdev);
return 0;
}
--
2.11.0
[PATCH] gpio: pxa: handle corner case of unprobed device
In the corner case where the gpio driver probe fails, for whatever
reason, the suspend and resume handlers will still be called as they
have to be registered as syscore operations. This applies as well when
no probe was called while the driver has been built in the kernel.
Nicolas tracked this in :
https://bugzilla.kernel.org/show_bug.cgi?id=200905
Therefore, add a failsafe in these function, and test if a proper probe
succeeded and the driver is functional.
Signed-off-by: Robert Jarzmik
Reported-by: Nicolas Chauvet
---
drivers/gpio/gpio-pxa.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index c18712dabf93..bfe4c5c9f41c 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -776,6 +776,9 @@ static int pxa_gpio_suspend(void)
struct pxa_gpio_bank *c;
int gpio;
+ if (!pchip)
+ return 0;
+
for_each_gpio_bank(gpio, c, pchip) {
c->saved_gplr = readl_relaxed(c->regbase + GPLR_OFFSET);
c->saved_gpdr = readl_relaxed(c->regbase + GPDR_OFFSET);
@@ -794,6 +797,9 @@ static void pxa_gpio_resume(void)
struct pxa_gpio_bank *c;
int gpio;
+ if (!pchip)
+ return;
+
for_each_gpio_bank(gpio, c, pchip) {
/* restore level with set/clear */
writel_relaxed(c->saved_gplr, c->regbase + GPSR_OFFSET);
--
2.11.0
[PATCH] gpio: pxa: handle corner case of unprobed device
In the corner case where the gpio driver probe fails, for whatever
reason, the suspend and resume handlers will still be called as they
have to be registered as syscore operations. This applies as well when
no probe was called while the driver has been built in the kernel.
Nicolas tracked this in :
https://bugzilla.kernel.org/show_bug.cgi?id=200905
Therefore, add a failsafe in these function, and test if a proper probe
succeeded and the driver is functional.
Signed-off-by: Robert Jarzmik
Reported-by: Nicolas Chauvet
---
drivers/gpio/gpio-pxa.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index c18712dabf93..bfe4c5c9f41c 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -776,6 +776,9 @@ static int pxa_gpio_suspend(void)
struct pxa_gpio_bank *c;
int gpio;
+ if (!pchip)
+ return 0;
+
for_each_gpio_bank(gpio, c, pchip) {
c->saved_gplr = readl_relaxed(c->regbase + GPLR_OFFSET);
c->saved_gpdr = readl_relaxed(c->regbase + GPDR_OFFSET);
@@ -794,6 +797,9 @@ static void pxa_gpio_resume(void)
struct pxa_gpio_bank *c;
int gpio;
+ if (!pchip)
+ return;
+
for_each_gpio_bank(gpio, c, pchip) {
/* restore level with set/clear */
writel_relaxed(c->saved_gplr, c->regbase + GPSR_OFFSET);
--
2.11.0
Re: [PATCH 2/2] iio: adc: sc27xx: Add ADC scale calibration
On Fri, 24 Aug 2018 17:53:16 +0800
Baolin Wang wrote:
> This patch adds support to read calibration values from the eFuse
> controller to calibrate the ADC channel scales, which can make ADC
> sample data more accurate.
>
> Signed-off-by: Baolin Wang
This looks good to me. I'll leave it for now though given open questions
on patch 1 and to allow others time to comment on this if they wish -
particularly as it includes a binding addition.
Jonathan
> ---
> .../bindings/iio/adc/sprd,sc27xx-adc.txt |4 ++
> drivers/iio/adc/sc27xx_adc.c | 52
> ++--
> 2 files changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> b/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> index 8aad960..b4daa15 100644
> --- a/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> @@ -12,6 +12,8 @@ Required properties:
> - interrupts: The interrupt number for the ADC device.
> - #io-channel-cells: Number of cells in an IIO specifier.
> - hwlocks: Reference to a phandle of a hwlock provider node.
> +- nvmem-cells: A phandle to the calibration cells provided by eFuse device.
> +- nvmem-cell-names: Should be "big_scale_calib", "small_scale_calib".
>
> Example:
>
> @@ -32,5 +34,7 @@ Example:
> interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> #io-channel-cells = <1>;
> hwlocks = < 4>;
> + nvmem-cells = <_big_scale>, <_small_scale>;
> + nvmem-cell-names = "big_scale_calib",
> "small_scale_calib";
> };
> };
> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
> index 153c311..7ac78eda 100644
> --- a/drivers/iio/adc/sc27xx_adc.c
> +++ b/drivers/iio/adc/sc27xx_adc.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -87,16 +88,48 @@ struct sc27xx_adc_linear_graph {
> * should use the small-scale graph, and if more than 1.2v, we should use the
> * big-scale graph.
> */
> -static const struct sc27xx_adc_linear_graph big_scale_graph = {
> +static struct sc27xx_adc_linear_graph big_scale_graph = {
> 4200, 3310,
> 3600, 2832,
> };
>
> -static const struct sc27xx_adc_linear_graph small_scale_graph = {
> +static struct sc27xx_adc_linear_graph small_scale_graph = {
> 1000, 3413,
> 100, 341,
> };
>
> +static const struct sc27xx_adc_linear_graph big_scale_graph_calib = {
> + 4200, 856,
> + 3600, 733,
> +};
> +
> +static const struct sc27xx_adc_linear_graph small_scale_graph_calib = {
> + 1000, 833,
> + 100, 80,
> +};
> +
> +static int sc27xx_adc_get_calib_data(u32 calib_data, int calib_adc)
> +{
> + return ((calib_data & 0xff) + calib_adc - 128) * 4;
> +}
> +
> +static void
> +sc27xx_adc_scale_calibration(const struct sc27xx_adc_linear_graph
> *calib_graph,
> + u32 calib_data, bool big_scale)
> +{
> + struct sc27xx_adc_linear_graph *graph;
> +
> + if (big_scale)
> + graph = _scale_graph;
> + else
> + graph = _scale_graph;
> +
> + /* Only need to calibrate the adc values in the linear graph. */
> + graph->adc0 = sc27xx_adc_get_calib_data(calib_data, calib_graph->adc0);
> + graph->adc1 = sc27xx_adc_get_calib_data(calib_data >> 8,
> + calib_graph->adc1);
> +}
> +
> static int sc27xx_adc_get_ratio(int channel, int scale)
> {
> switch (channel) {
> @@ -209,7 +242,7 @@ static void sc27xx_adc_volt_ratio(struct sc27xx_adc_data
> *data,
> *div_denominator = ratio & SC27XX_RATIO_DENOMINATOR_MASK;
> }
>
> -static int sc27xx_adc_to_volt(const struct sc27xx_adc_linear_graph *graph,
> +static int sc27xx_adc_to_volt(struct sc27xx_adc_linear_graph *graph,
> int raw_adc)
> {
> int tmp;
> @@ -371,6 +404,7 @@ static int sc27xx_adc_write_raw(struct iio_dev *indio_dev,
>
> static int sc27xx_adc_enable(struct sc27xx_adc_data *data)
> {
> + u32 val;
> int ret;
>
> ret = regmap_update_bits(data->regmap, SC27XX_MODULE_EN,
> @@ -390,6 +424,18 @@ static int sc27xx_adc_enable(struct sc27xx_adc_data
> *data)
> if (ret)
> goto disable_clk;
>
> + /* ADC channel scales' calibration from nvmem device */
> + ret = nvmem_cell_read_u32(data->dev, "big_scale_calib", );
> + if (ret)
> + goto disable_clk;
> +
> + sc27xx_adc_scale_calibration(_scale_graph_calib, val, true);
> +
> + ret = nvmem_cell_read_u32(data->dev, "small_scale_calib", );
> + if (ret)
> + goto disable_clk;
> +
> + sc27xx_adc_scale_calibration(_scale_graph_calib, val, false);
> return 0;
>
> disable_clk:
Re: [PATCH 2/2] iio: adc: sc27xx: Add ADC scale calibration
On Fri, 24 Aug 2018 17:53:16 +0800
Baolin Wang wrote:
> This patch adds support to read calibration values from the eFuse
> controller to calibrate the ADC channel scales, which can make ADC
> sample data more accurate.
>
> Signed-off-by: Baolin Wang
This looks good to me. I'll leave it for now though given open questions
on patch 1 and to allow others time to comment on this if they wish -
particularly as it includes a binding addition.
Jonathan
> ---
> .../bindings/iio/adc/sprd,sc27xx-adc.txt |4 ++
> drivers/iio/adc/sc27xx_adc.c | 52
> ++--
> 2 files changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> b/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> index 8aad960..b4daa15 100644
> --- a/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt
> @@ -12,6 +12,8 @@ Required properties:
> - interrupts: The interrupt number for the ADC device.
> - #io-channel-cells: Number of cells in an IIO specifier.
> - hwlocks: Reference to a phandle of a hwlock provider node.
> +- nvmem-cells: A phandle to the calibration cells provided by eFuse device.
> +- nvmem-cell-names: Should be "big_scale_calib", "small_scale_calib".
>
> Example:
>
> @@ -32,5 +34,7 @@ Example:
> interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> #io-channel-cells = <1>;
> hwlocks = < 4>;
> + nvmem-cells = <_big_scale>, <_small_scale>;
> + nvmem-cell-names = "big_scale_calib",
> "small_scale_calib";
> };
> };
> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
> index 153c311..7ac78eda 100644
> --- a/drivers/iio/adc/sc27xx_adc.c
> +++ b/drivers/iio/adc/sc27xx_adc.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -87,16 +88,48 @@ struct sc27xx_adc_linear_graph {
> * should use the small-scale graph, and if more than 1.2v, we should use the
> * big-scale graph.
> */
> -static const struct sc27xx_adc_linear_graph big_scale_graph = {
> +static struct sc27xx_adc_linear_graph big_scale_graph = {
> 4200, 3310,
> 3600, 2832,
> };
>
> -static const struct sc27xx_adc_linear_graph small_scale_graph = {
> +static struct sc27xx_adc_linear_graph small_scale_graph = {
> 1000, 3413,
> 100, 341,
> };
>
> +static const struct sc27xx_adc_linear_graph big_scale_graph_calib = {
> + 4200, 856,
> + 3600, 733,
> +};
> +
> +static const struct sc27xx_adc_linear_graph small_scale_graph_calib = {
> + 1000, 833,
> + 100, 80,
> +};
> +
> +static int sc27xx_adc_get_calib_data(u32 calib_data, int calib_adc)
> +{
> + return ((calib_data & 0xff) + calib_adc - 128) * 4;
> +}
> +
> +static void
> +sc27xx_adc_scale_calibration(const struct sc27xx_adc_linear_graph
> *calib_graph,
> + u32 calib_data, bool big_scale)
> +{
> + struct sc27xx_adc_linear_graph *graph;
> +
> + if (big_scale)
> + graph = _scale_graph;
> + else
> + graph = _scale_graph;
> +
> + /* Only need to calibrate the adc values in the linear graph. */
> + graph->adc0 = sc27xx_adc_get_calib_data(calib_data, calib_graph->adc0);
> + graph->adc1 = sc27xx_adc_get_calib_data(calib_data >> 8,
> + calib_graph->adc1);
> +}
> +
> static int sc27xx_adc_get_ratio(int channel, int scale)
> {
> switch (channel) {
> @@ -209,7 +242,7 @@ static void sc27xx_adc_volt_ratio(struct sc27xx_adc_data
> *data,
> *div_denominator = ratio & SC27XX_RATIO_DENOMINATOR_MASK;
> }
>
> -static int sc27xx_adc_to_volt(const struct sc27xx_adc_linear_graph *graph,
> +static int sc27xx_adc_to_volt(struct sc27xx_adc_linear_graph *graph,
> int raw_adc)
> {
> int tmp;
> @@ -371,6 +404,7 @@ static int sc27xx_adc_write_raw(struct iio_dev *indio_dev,
>
> static int sc27xx_adc_enable(struct sc27xx_adc_data *data)
> {
> + u32 val;
> int ret;
>
> ret = regmap_update_bits(data->regmap, SC27XX_MODULE_EN,
> @@ -390,6 +424,18 @@ static int sc27xx_adc_enable(struct sc27xx_adc_data
> *data)
> if (ret)
> goto disable_clk;
>
> + /* ADC channel scales' calibration from nvmem device */
> + ret = nvmem_cell_read_u32(data->dev, "big_scale_calib", );
> + if (ret)
> + goto disable_clk;
> +
> + sc27xx_adc_scale_calibration(_scale_graph_calib, val, true);
> +
> + ret = nvmem_cell_read_u32(data->dev, "small_scale_calib", );
> + if (ret)
> + goto disable_clk;
> +
> + sc27xx_adc_scale_calibration(_scale_graph_calib, val, false);
> return 0;
>
> disable_clk:
I NEED A TRUSTWORTHY PARTNER.
-- Dear Friend, Greetings! I am confidence you are good with your family. Please may I request your urgent assistance in transferring the sum of ($10.7M) to your account? It is 100% risk free and you will receive 35% of the total sum for your kind assistance. On confirmation of your interest I will send more details. With Regards, Mr. Simon Kafando
I NEED A TRUSTWORTHY PARTNER.
-- Dear Friend, Greetings! I am confidence you are good with your family. Please may I request your urgent assistance in transferring the sum of ($10.7M) to your account? It is 100% risk free and you will receive 35% of the total sum for your kind assistance. On confirmation of your interest I will send more details. With Regards, Mr. Simon Kafando
Re: [PATCH 1/2] iio: adc: sc27xx: Add raw data support
On Fri, 24 Aug 2018 17:53:15 +0800
Baolin Wang wrote:
> The headset device will use channel 20 of ADC controller to detect events,
> but it needs the raw ADC data to do conversion according to its own formula.
>
> Thus we should configure the channel mask separately and configure channel
> 20 as IIO_CHAN_INFO_RAW, as well as adding raw data read support.
So is this a general thing, i.e. that channel is 'meant' to be used for the
headset, or just a one off for a particular board?
If it is a general thing, than I'm fine with this (unlikely we'll break any
other users), but if not we need to find a nicer way to do it.
I am a little unclear on how a channel would provide the voltage on it's pin
but that could be wrong when used for a different purpose?
If it's just a matter of unusual loading characteristics then perhaps that
is valid, but I'd like to understand this a little.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/iio/adc/sc27xx_adc.c | 80
> --
> 1 file changed, 45 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
> index 2b60efe..153c311 100644
> --- a/drivers/iio/adc/sc27xx_adc.c
> +++ b/drivers/iio/adc/sc27xx_adc.c
> @@ -273,6 +273,17 @@ static int sc27xx_adc_read_raw(struct iio_dev *indio_dev,
> int ret, tmp;
>
> switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + mutex_lock(_dev->mlock);
> + ret = sc27xx_adc_read(data, chan->channel, scale, );
> + mutex_unlock(_dev->mlock);
> +
> + if (ret)
> + return ret;
> +
> + *val = tmp;
> + return IIO_VAL_INT;
> +
> case IIO_CHAN_INFO_PROCESSED:
> mutex_lock(_dev->mlock);
> ret = sc27xx_adc_read_processed(data, chan->channel, scale,
> @@ -315,48 +326,47 @@ static int sc27xx_adc_write_raw(struct iio_dev
> *indio_dev,
> .write_raw = _adc_write_raw,
> };
>
> -#define SC27XX_ADC_CHANNEL(index) { \
> +#define SC27XX_ADC_CHANNEL(index, mask) {\
> .type = IIO_VOLTAGE,\
> .channel = index, \
> - .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |\
> - BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_separate = mask | BIT(IIO_CHAN_INFO_SCALE), \
> .datasheet_name = "CH##index", \
> .indexed = 1, \
> }
>
> static const struct iio_chan_spec sc27xx_channels[] = {
> - SC27XX_ADC_CHANNEL(0),
> - SC27XX_ADC_CHANNEL(1),
> - SC27XX_ADC_CHANNEL(2),
> - SC27XX_ADC_CHANNEL(3),
> - SC27XX_ADC_CHANNEL(4),
> - SC27XX_ADC_CHANNEL(5),
> - SC27XX_ADC_CHANNEL(6),
> - SC27XX_ADC_CHANNEL(7),
> - SC27XX_ADC_CHANNEL(8),
> - SC27XX_ADC_CHANNEL(9),
> - SC27XX_ADC_CHANNEL(10),
> - SC27XX_ADC_CHANNEL(11),
> - SC27XX_ADC_CHANNEL(12),
> - SC27XX_ADC_CHANNEL(13),
> - SC27XX_ADC_CHANNEL(14),
> - SC27XX_ADC_CHANNEL(15),
> - SC27XX_ADC_CHANNEL(16),
> - SC27XX_ADC_CHANNEL(17),
> - SC27XX_ADC_CHANNEL(18),
> - SC27XX_ADC_CHANNEL(19),
> - SC27XX_ADC_CHANNEL(20),
> - SC27XX_ADC_CHANNEL(21),
> - SC27XX_ADC_CHANNEL(22),
> - SC27XX_ADC_CHANNEL(23),
> - SC27XX_ADC_CHANNEL(24),
> - SC27XX_ADC_CHANNEL(25),
> - SC27XX_ADC_CHANNEL(26),
> - SC27XX_ADC_CHANNEL(27),
> - SC27XX_ADC_CHANNEL(28),
> - SC27XX_ADC_CHANNEL(29),
> - SC27XX_ADC_CHANNEL(30),
> - SC27XX_ADC_CHANNEL(31),
> + SC27XX_ADC_CHANNEL(0, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(1, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(2, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(3, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(4, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(5, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(6, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(7, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(8, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(9, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(10, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(11, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(12, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(13, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(14, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(15, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(16, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(17, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(18, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(19, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(20, BIT(IIO_CHAN_INFO_RAW)),
> + SC27XX_ADC_CHANNEL(21,
Re: [PATCH 1/2] iio: adc: sc27xx: Add raw data support
On Fri, 24 Aug 2018 17:53:15 +0800
Baolin Wang wrote:
> The headset device will use channel 20 of ADC controller to detect events,
> but it needs the raw ADC data to do conversion according to its own formula.
>
> Thus we should configure the channel mask separately and configure channel
> 20 as IIO_CHAN_INFO_RAW, as well as adding raw data read support.
So is this a general thing, i.e. that channel is 'meant' to be used for the
headset, or just a one off for a particular board?
If it is a general thing, than I'm fine with this (unlikely we'll break any
other users), but if not we need to find a nicer way to do it.
I am a little unclear on how a channel would provide the voltage on it's pin
but that could be wrong when used for a different purpose?
If it's just a matter of unusual loading characteristics then perhaps that
is valid, but I'd like to understand this a little.
>
> Signed-off-by: Baolin Wang
> ---
> drivers/iio/adc/sc27xx_adc.c | 80
> --
> 1 file changed, 45 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
> index 2b60efe..153c311 100644
> --- a/drivers/iio/adc/sc27xx_adc.c
> +++ b/drivers/iio/adc/sc27xx_adc.c
> @@ -273,6 +273,17 @@ static int sc27xx_adc_read_raw(struct iio_dev *indio_dev,
> int ret, tmp;
>
> switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + mutex_lock(_dev->mlock);
> + ret = sc27xx_adc_read(data, chan->channel, scale, );
> + mutex_unlock(_dev->mlock);
> +
> + if (ret)
> + return ret;
> +
> + *val = tmp;
> + return IIO_VAL_INT;
> +
> case IIO_CHAN_INFO_PROCESSED:
> mutex_lock(_dev->mlock);
> ret = sc27xx_adc_read_processed(data, chan->channel, scale,
> @@ -315,48 +326,47 @@ static int sc27xx_adc_write_raw(struct iio_dev
> *indio_dev,
> .write_raw = _adc_write_raw,
> };
>
> -#define SC27XX_ADC_CHANNEL(index) { \
> +#define SC27XX_ADC_CHANNEL(index, mask) {\
> .type = IIO_VOLTAGE,\
> .channel = index, \
> - .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |\
> - BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_separate = mask | BIT(IIO_CHAN_INFO_SCALE), \
> .datasheet_name = "CH##index", \
> .indexed = 1, \
> }
>
> static const struct iio_chan_spec sc27xx_channels[] = {
> - SC27XX_ADC_CHANNEL(0),
> - SC27XX_ADC_CHANNEL(1),
> - SC27XX_ADC_CHANNEL(2),
> - SC27XX_ADC_CHANNEL(3),
> - SC27XX_ADC_CHANNEL(4),
> - SC27XX_ADC_CHANNEL(5),
> - SC27XX_ADC_CHANNEL(6),
> - SC27XX_ADC_CHANNEL(7),
> - SC27XX_ADC_CHANNEL(8),
> - SC27XX_ADC_CHANNEL(9),
> - SC27XX_ADC_CHANNEL(10),
> - SC27XX_ADC_CHANNEL(11),
> - SC27XX_ADC_CHANNEL(12),
> - SC27XX_ADC_CHANNEL(13),
> - SC27XX_ADC_CHANNEL(14),
> - SC27XX_ADC_CHANNEL(15),
> - SC27XX_ADC_CHANNEL(16),
> - SC27XX_ADC_CHANNEL(17),
> - SC27XX_ADC_CHANNEL(18),
> - SC27XX_ADC_CHANNEL(19),
> - SC27XX_ADC_CHANNEL(20),
> - SC27XX_ADC_CHANNEL(21),
> - SC27XX_ADC_CHANNEL(22),
> - SC27XX_ADC_CHANNEL(23),
> - SC27XX_ADC_CHANNEL(24),
> - SC27XX_ADC_CHANNEL(25),
> - SC27XX_ADC_CHANNEL(26),
> - SC27XX_ADC_CHANNEL(27),
> - SC27XX_ADC_CHANNEL(28),
> - SC27XX_ADC_CHANNEL(29),
> - SC27XX_ADC_CHANNEL(30),
> - SC27XX_ADC_CHANNEL(31),
> + SC27XX_ADC_CHANNEL(0, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(1, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(2, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(3, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(4, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(5, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(6, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(7, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(8, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(9, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(10, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(11, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(12, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(13, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(14, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(15, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(16, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(17, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(18, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(19, BIT(IIO_CHAN_INFO_PROCESSED)),
> + SC27XX_ADC_CHANNEL(20, BIT(IIO_CHAN_INFO_RAW)),
> + SC27XX_ADC_CHANNEL(21,
[GIT PULL] UBIFS fix for 4.19-rc1
Linus, The following changes since commit 99a24e02ccf6604e3020cf9e2c7a042b6ebb655f: ubifs: Set default assert action to read-only (2018-08-15 00:25:22 +0200) are available in the Git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.19-rc1-fix for you to fetch changes up to 6e5461d774bf42aae622ad0f3ff53e41962f886b: ubifs: Remove empty file.h (2018-08-24 13:50:07 +0200) This pull request contains a single fix for UBIFS: - Remove an empty file from UBIFS source Richard Weinberger (1): ubifs: Remove empty file.h fs/ubifs/file.h | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 fs/ubifs/file.h
[GIT PULL] UBIFS fix for 4.19-rc1
Linus, The following changes since commit 99a24e02ccf6604e3020cf9e2c7a042b6ebb655f: ubifs: Set default assert action to read-only (2018-08-15 00:25:22 +0200) are available in the Git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.19-rc1-fix for you to fetch changes up to 6e5461d774bf42aae622ad0f3ff53e41962f886b: ubifs: Remove empty file.h (2018-08-24 13:50:07 +0200) This pull request contains a single fix for UBIFS: - Remove an empty file from UBIFS source Richard Weinberger (1): ubifs: Remove empty file.h fs/ubifs/file.h | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 fs/ubifs/file.h
Re: [PATCH] iio: light: isl29501: Simplify code to kill compiler warning
On Thu, 23 Aug 2018 23:24:35 +0200
Geert Uytterhoeven wrote:
> With gcc 4.1.2:
>
> drivers/iio/proximity/isl29501.c: In function ‘isl29501_register_write’:
> drivers/iio/proximity/isl29501.c:235: warning: ‘msb’ may be used
> uninitialized in this function
>
> While this is a false positive, it can easily be avoided by removing the
> "msb" intermediate variable.
> Remove the "lsb" intermediate variable for consistency.
>
> Signed-off-by: Geert Uytterhoeven
Looks sensible to me, but I'd obviously like to leave a little time for
Mathieu to comment as it's his driver.
Jonathan
> ---
> Compile-tested only.
> ---
> drivers/iio/proximity/isl29501.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/proximity/isl29501.c
> b/drivers/iio/proximity/isl29501.c
> index e5e94540f404dd2c..5ae549075b27c50d 100644
> --- a/drivers/iio/proximity/isl29501.c
> +++ b/drivers/iio/proximity/isl29501.c
> @@ -232,7 +232,6 @@ static u32 isl29501_register_write(struct
> isl29501_private *isl29501,
> u32 value)
> {
> const struct isl29501_register_desc *reg = _registers[name];
> - u8 msb, lsb;
> int ret;
>
> if (!reg->msb && value > U8_MAX)
> @@ -241,22 +240,15 @@ static u32 isl29501_register_write(struct
> isl29501_private *isl29501,
> if (value > U16_MAX)
> return -ERANGE;
>
> - if (!reg->msb) {
> - lsb = value & 0xFF;
> - } else {
> - msb = (value >> 8) & 0xFF;
> - lsb = value & 0xFF;
> - }
> -
> mutex_lock(>lock);
> if (reg->msb) {
> ret = i2c_smbus_write_byte_data(isl29501->client,
> - reg->msb, msb);
> + reg->msb, value >> 8);
> if (ret < 0)
> goto err;
> }
>
> - ret = i2c_smbus_write_byte_data(isl29501->client, reg->lsb, lsb);
> + ret = i2c_smbus_write_byte_data(isl29501->client, reg->lsb, value);
>
> err:
> mutex_unlock(>lock);
Re: [PATCH] iio: light: isl29501: Simplify code to kill compiler warning
On Thu, 23 Aug 2018 23:24:35 +0200
Geert Uytterhoeven wrote:
> With gcc 4.1.2:
>
> drivers/iio/proximity/isl29501.c: In function ‘isl29501_register_write’:
> drivers/iio/proximity/isl29501.c:235: warning: ‘msb’ may be used
> uninitialized in this function
>
> While this is a false positive, it can easily be avoided by removing the
> "msb" intermediate variable.
> Remove the "lsb" intermediate variable for consistency.
>
> Signed-off-by: Geert Uytterhoeven
Looks sensible to me, but I'd obviously like to leave a little time for
Mathieu to comment as it's his driver.
Jonathan
> ---
> Compile-tested only.
> ---
> drivers/iio/proximity/isl29501.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/proximity/isl29501.c
> b/drivers/iio/proximity/isl29501.c
> index e5e94540f404dd2c..5ae549075b27c50d 100644
> --- a/drivers/iio/proximity/isl29501.c
> +++ b/drivers/iio/proximity/isl29501.c
> @@ -232,7 +232,6 @@ static u32 isl29501_register_write(struct
> isl29501_private *isl29501,
> u32 value)
> {
> const struct isl29501_register_desc *reg = _registers[name];
> - u8 msb, lsb;
> int ret;
>
> if (!reg->msb && value > U8_MAX)
> @@ -241,22 +240,15 @@ static u32 isl29501_register_write(struct
> isl29501_private *isl29501,
> if (value > U16_MAX)
> return -ERANGE;
>
> - if (!reg->msb) {
> - lsb = value & 0xFF;
> - } else {
> - msb = (value >> 8) & 0xFF;
> - lsb = value & 0xFF;
> - }
> -
> mutex_lock(>lock);
> if (reg->msb) {
> ret = i2c_smbus_write_byte_data(isl29501->client,
> - reg->msb, msb);
> + reg->msb, value >> 8);
> if (ret < 0)
> goto err;
> }
>
> - ret = i2c_smbus_write_byte_data(isl29501->client, reg->lsb, lsb);
> + ret = i2c_smbus_write_byte_data(isl29501->client, reg->lsb, value);
>
> err:
> mutex_unlock(>lock);
Re: [PATCH v2 3/3] MAINTAINERS: add entry for ltc1660 DAC driver
On Tue, 21 Aug 2018 21:31:26 +0200 Marcus Folkesson wrote: > Add entry for ltc1660 DAC driver and add myself as > maintainer of this driver. > > Signed-off-by: Marcus Folkesson Applied. Thanks, Jonathan > --- > > Notes: > v2: > - rename enumerated files, ltc166x* -> ltc1660* > > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9276da915d9d..3db1edaf68bd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8363,6 +8363,13 @@ L: linux-s...@vger.kernel.org > S: Maintained > F: drivers/scsi/sym53c8xx_2/ > > +LTC1660 DAC DRIVER > +M: Marcus Folkesson > +L: linux-...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt > +F: drivers/iio/dac/ltc1660.c > + > LTC4261 HARDWARE MONITOR DRIVER > M: Guenter Roeck > L: linux-hw...@vger.kernel.org
Re: [PATCH v2 3/3] MAINTAINERS: add entry for ltc1660 DAC driver
On Tue, 21 Aug 2018 21:31:26 +0200 Marcus Folkesson wrote: > Add entry for ltc1660 DAC driver and add myself as > maintainer of this driver. > > Signed-off-by: Marcus Folkesson Applied. Thanks, Jonathan > --- > > Notes: > v2: > - rename enumerated files, ltc166x* -> ltc1660* > > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9276da915d9d..3db1edaf68bd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8363,6 +8363,13 @@ L: linux-s...@vger.kernel.org > S: Maintained > F: drivers/scsi/sym53c8xx_2/ > > +LTC1660 DAC DRIVER > +M: Marcus Folkesson > +L: linux-...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt > +F: drivers/iio/dac/ltc1660.c > + > LTC4261 HARDWARE MONITOR DRIVER > M: Guenter Roeck > L: linux-hw...@vger.kernel.org
Re: [PATCH v2 2/3] dt-bindings: iio: dac: add bindings for ltc1660
On Wed, 22 Aug 2018 21:25:18 +0200
Marcus Folkesson wrote:
> On Tue, Aug 21, 2018 at 09:31:25PM +0200, Marcus Folkesson wrote:
> > LTC1665/LTC1660 is a 8/10-bit Digital-to-Analog Converter (DAC)
> > with eight individual channels.
> >
> > Signed-off-by: Marcus Folkesson
>
> Rob, sorry I missed your tag.
>
> Reviewed-by: Rob Herring
Applied to the togreg branch of iio.git and pushed out as testing
to be largely ignored by the autobuilders.
Thanks,
Jonathan
>
> > ---
> >
> > Notes:
> > v2:
> > - rename file, ltc166x -> ltc1660
> >
> > .../devicetree/bindings/iio/dac/ltc1660.txt | 21
> > +
> > 1 file changed, 21 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > b/Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > new file mode 100644
> > index ..c5b5f22d6c64
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > @@ -0,0 +1,21 @@
> > +* Linear Technology Micropower octal 8-Bit and 10-Bit DACs
> > +
> > +Required properties:
> > + - compatible: Must be one of the following:
> > + "lltc,ltc1660"
> > + "lltc,ltc1665"
> > + - reg: SPI chip select number for the device
> > + - vref-supply: Phandle to the voltage reference supply
> > +
> > +Recommended properties:
> > + - spi-max-frequency: Definition as per
> > +Documentation/devicetree/bindings/spi/spi-bus.txt.
> > +Max frequency for this chip is 5 MHz.
> > +
> > +Example:
> > +dac@0 {
> > + compatible = "lltc,ltc1660";
> > + reg = <0>;
> > + spi-max-frequency = <500>;
> > + vref-supply = <_reg>;
> > +};
> > --
> > 2.11.0.rc2
> >
Re: [PATCH v2 2/3] dt-bindings: iio: dac: add bindings for ltc1660
On Wed, 22 Aug 2018 21:25:18 +0200
Marcus Folkesson wrote:
> On Tue, Aug 21, 2018 at 09:31:25PM +0200, Marcus Folkesson wrote:
> > LTC1665/LTC1660 is a 8/10-bit Digital-to-Analog Converter (DAC)
> > with eight individual channels.
> >
> > Signed-off-by: Marcus Folkesson
>
> Rob, sorry I missed your tag.
>
> Reviewed-by: Rob Herring
Applied to the togreg branch of iio.git and pushed out as testing
to be largely ignored by the autobuilders.
Thanks,
Jonathan
>
> > ---
> >
> > Notes:
> > v2:
> > - rename file, ltc166x -> ltc1660
> >
> > .../devicetree/bindings/iio/dac/ltc1660.txt | 21
> > +
> > 1 file changed, 21 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > b/Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > new file mode 100644
> > index ..c5b5f22d6c64
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > @@ -0,0 +1,21 @@
> > +* Linear Technology Micropower octal 8-Bit and 10-Bit DACs
> > +
> > +Required properties:
> > + - compatible: Must be one of the following:
> > + "lltc,ltc1660"
> > + "lltc,ltc1665"
> > + - reg: SPI chip select number for the device
> > + - vref-supply: Phandle to the voltage reference supply
> > +
> > +Recommended properties:
> > + - spi-max-frequency: Definition as per
> > +Documentation/devicetree/bindings/spi/spi-bus.txt.
> > +Max frequency for this chip is 5 MHz.
> > +
> > +Example:
> > +dac@0 {
> > + compatible = "lltc,ltc1660";
> > + reg = <0>;
> > + spi-max-frequency = <500>;
> > + vref-supply = <_reg>;
> > +};
> > --
> > 2.11.0.rc2
> >
Re: [PATCH v2 1/3] iio: dac: add support for ltc1660
On Tue, 21 Aug 2018 21:31:24 +0200
Marcus Folkesson wrote:
> LTC1665/LTC1660 is a 8/10-bit Digital-to-Analog Converter
> (DAC) with eight individual channels.
>
> Signed-off-by: Marcus Folkesson
Great.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
>
> Notes:
> v2:
> - rename all instances of ltc166x to ltc1660
> - read regulator value "in-place" instead of cache voltage
> - fix error handling in ltc1660_write_raw
>
> drivers/iio/dac/Kconfig | 10 ++
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/ltc1660.c | 250
> ++
> 3 files changed, 261 insertions(+)
> create mode 100644 drivers/iio/dac/ltc1660.c
>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 76db0768e454..cbee80bd111e 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -120,6 +120,16 @@ config AD5624R_SPI
> Say yes here to build support for Analog Devices AD5624R, AD5644R and
> AD5664R converters (DAC). This driver uses the common SPI interface.
>
> +config LTC1660
> + tristate "Linear Technology LTC1660/LTC1665 DAC SPI driver"
> + depends on SPI
> + help
> + Say yes here to build support for Linear Technology
> + LTC1660 and LTC1665 Digital to Analog Converters.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ltc1660.
> +
> config LTC2632
> tristate "Linear Technology LTC2632-12/10/8 DAC spi driver"
> depends on SPI
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 81e710ed7491..e446eeb09c85 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_CIO_DAC) += cio-dac.o
> obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
> obj-$(CONFIG_DS4424) += ds4424.o
> obj-$(CONFIG_LPC18XX_DAC) += lpc18xx_dac.o
> +obj-$(CONFIG_LTC1660) += ltc1660.o
> obj-$(CONFIG_LTC2632) += ltc2632.o
> obj-$(CONFIG_M62332) += m62332.o
> obj-$(CONFIG_MAX517) += max517.o
> diff --git a/drivers/iio/dac/ltc1660.c b/drivers/iio/dac/ltc1660.c
> new file mode 100644
> index ..10866838c72a
> --- /dev/null
> +++ b/drivers/iio/dac/ltc1660.c
> @@ -0,0 +1,250 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Linear Technology LTC1665/LTC1660, 8 channels DAC
> + *
> + * Copyright (C) 2018 Marcus Folkesson
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define LTC1660_REG_WAKE 0x0
> +#define LTC1660_REG_DAC_A0x1
> +#define LTC1660_REG_DAC_B0x2
> +#define LTC1660_REG_DAC_C0x3
> +#define LTC1660_REG_DAC_D0x4
> +#define LTC1660_REG_DAC_E0x5
> +#define LTC1660_REG_DAC_F0x6
> +#define LTC1660_REG_DAC_G0x7
> +#define LTC1660_REG_DAC_H0x8
> +#define LTC1660_REG_SLEEP0xe
> +
> +#define LTC1660_NUM_CHANNELS 8
> +
> +static const struct regmap_config ltc1660_regmap_config = {
> + .reg_bits = 4,
> + .val_bits = 12,
> +};
> +
> +enum ltc1660_supported_device_ids {
> + ID_LTC1660,
> + ID_LTC1665,
> +};
> +
> +struct ltc1660_priv {
> + struct spi_device *spi;
> + struct regmap *regmap;
> + struct regulator *vref_reg;
> + unsigned int value[LTC1660_NUM_CHANNELS];
> + unsigned int vref_mv;
> +};
> +
> +static int ltc1660_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val,
> + int *val2,
> + long mask)
> +{
> + struct ltc1660_priv *priv = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + *val = priv->value[chan->channel];
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = regulator_get_voltage(priv->vref_reg);
> + if (*val < 0) {
> + dev_err(>spi->dev, "failed to read vref
> regulator: %d\n",
> + *val);
> + return *val;
> + }
> +
> + /* Convert to mV */
> + *val /= 1000;
> + *val2 = chan->scan_type.realbits;
> + return IIO_VAL_FRACTIONAL_LOG2;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ltc1660_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val,
> + int val2,
> + long mask)
> +{
> + struct ltc1660_priv *priv = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val2 != 0)
> + return -EINVAL;
> +
> + if (val < 0 || val > GENMASK(chan->scan_type.realbits - 1, 0))
> + return -EINVAL;
> +
> + ret = regmap_write(priv->regmap, chan->channel,
> +
Re: [PATCH v2 1/3] iio: dac: add support for ltc1660
On Tue, 21 Aug 2018 21:31:24 +0200
Marcus Folkesson wrote:
> LTC1665/LTC1660 is a 8/10-bit Digital-to-Analog Converter
> (DAC) with eight individual channels.
>
> Signed-off-by: Marcus Folkesson
Great.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
>
> Notes:
> v2:
> - rename all instances of ltc166x to ltc1660
> - read regulator value "in-place" instead of cache voltage
> - fix error handling in ltc1660_write_raw
>
> drivers/iio/dac/Kconfig | 10 ++
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/ltc1660.c | 250
> ++
> 3 files changed, 261 insertions(+)
> create mode 100644 drivers/iio/dac/ltc1660.c
>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 76db0768e454..cbee80bd111e 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -120,6 +120,16 @@ config AD5624R_SPI
> Say yes here to build support for Analog Devices AD5624R, AD5644R and
> AD5664R converters (DAC). This driver uses the common SPI interface.
>
> +config LTC1660
> + tristate "Linear Technology LTC1660/LTC1665 DAC SPI driver"
> + depends on SPI
> + help
> + Say yes here to build support for Linear Technology
> + LTC1660 and LTC1665 Digital to Analog Converters.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ltc1660.
> +
> config LTC2632
> tristate "Linear Technology LTC2632-12/10/8 DAC spi driver"
> depends on SPI
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 81e710ed7491..e446eeb09c85 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_CIO_DAC) += cio-dac.o
> obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
> obj-$(CONFIG_DS4424) += ds4424.o
> obj-$(CONFIG_LPC18XX_DAC) += lpc18xx_dac.o
> +obj-$(CONFIG_LTC1660) += ltc1660.o
> obj-$(CONFIG_LTC2632) += ltc2632.o
> obj-$(CONFIG_M62332) += m62332.o
> obj-$(CONFIG_MAX517) += max517.o
> diff --git a/drivers/iio/dac/ltc1660.c b/drivers/iio/dac/ltc1660.c
> new file mode 100644
> index ..10866838c72a
> --- /dev/null
> +++ b/drivers/iio/dac/ltc1660.c
> @@ -0,0 +1,250 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Linear Technology LTC1665/LTC1660, 8 channels DAC
> + *
> + * Copyright (C) 2018 Marcus Folkesson
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define LTC1660_REG_WAKE 0x0
> +#define LTC1660_REG_DAC_A0x1
> +#define LTC1660_REG_DAC_B0x2
> +#define LTC1660_REG_DAC_C0x3
> +#define LTC1660_REG_DAC_D0x4
> +#define LTC1660_REG_DAC_E0x5
> +#define LTC1660_REG_DAC_F0x6
> +#define LTC1660_REG_DAC_G0x7
> +#define LTC1660_REG_DAC_H0x8
> +#define LTC1660_REG_SLEEP0xe
> +
> +#define LTC1660_NUM_CHANNELS 8
> +
> +static const struct regmap_config ltc1660_regmap_config = {
> + .reg_bits = 4,
> + .val_bits = 12,
> +};
> +
> +enum ltc1660_supported_device_ids {
> + ID_LTC1660,
> + ID_LTC1665,
> +};
> +
> +struct ltc1660_priv {
> + struct spi_device *spi;
> + struct regmap *regmap;
> + struct regulator *vref_reg;
> + unsigned int value[LTC1660_NUM_CHANNELS];
> + unsigned int vref_mv;
> +};
> +
> +static int ltc1660_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val,
> + int *val2,
> + long mask)
> +{
> + struct ltc1660_priv *priv = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + *val = priv->value[chan->channel];
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = regulator_get_voltage(priv->vref_reg);
> + if (*val < 0) {
> + dev_err(>spi->dev, "failed to read vref
> regulator: %d\n",
> + *val);
> + return *val;
> + }
> +
> + /* Convert to mV */
> + *val /= 1000;
> + *val2 = chan->scan_type.realbits;
> + return IIO_VAL_FRACTIONAL_LOG2;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ltc1660_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val,
> + int val2,
> + long mask)
> +{
> + struct ltc1660_priv *priv = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val2 != 0)
> + return -EINVAL;
> +
> + if (val < 0 || val > GENMASK(chan->scan_type.realbits - 1, 0))
> + return -EINVAL;
> +
> + ret = regmap_write(priv->regmap, chan->channel,
> +
Re: [PATCH 3/3] iio:adxl372: Add filter bandwidth support
On Mon, 20 Aug 2018 17:54:55 +0300
Stefan Popa wrote:
> This patch adds the option for the user to select the filter bandwidth. The
> user can also read the available bandwidths which are always adjusted to be
> at most half of the sampling frequency. Furthermore, the currently selected
> bandwidth can be read via the read_raw function, while the write_raw sets a
> new bandwidth value.
>
> Signed-off-by: Stefan Popa
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/accel/adxl372.c | 38 --
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index 6281e4a..fdaaa58 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -202,6 +202,10 @@ static const int adxl372_samp_freq_tbl[5] = {
> 400, 800, 1600, 3200, 6400,
> };
>
> +static const int adxl372_bw_freq_tbl[5] = {
> + 200, 400, 800, 1600, 3200,
> +};
> +
> struct adxl372_axis_lookup {
> unsigned int bits;
> enum adxl372_fifo_format fifo_format;
> @@ -224,7 +228,8 @@ static const struct adxl372_axis_lookup
> adxl372_axis_lookup_table[] = {
> .channel2 = IIO_MOD_##axis, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) | \
> - BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY), \
> .scan_index = index,\
> .scan_type = { \
> .sign = 's',\
> @@ -648,6 +653,9 @@ static int adxl372_read_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_SAMP_FREQ:
> *val = adxl372_samp_freq_tbl[st->odr];
> return IIO_VAL_INT;
> + case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
> + *val = adxl372_bw_freq_tbl[st->bw];
> + return IIO_VAL_INT;
> }
>
> return -EINVAL;
> @@ -658,7 +666,7 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
>int val, int val2, long info)
> {
> struct adxl372_state *st = iio_priv(indio_dev);
> - int odr_index, ret;
> + int odr_index, bw_index, ret;
>
> switch (info) {
> case IIO_CHAN_INFO_SAMP_FREQ:
> @@ -690,11 +698,34 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
> ret = adxl372_set_bandwidth(st, odr_index);
>
> return ret;
> + case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
> + bw_index = adxl372_find_closest_match(adxl372_bw_freq_tbl,
> + ARRAY_SIZE(adxl372_bw_freq_tbl),
> + val);
> + return adxl372_set_bandwidth(st, bw_index);
> default:
> return -EINVAL;
> }
> }
>
> +static ssize_t adxl372_show_filter_freq_avail(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct adxl372_state *st = iio_priv(indio_dev);
> + int i;
> + size_t len = 0;
> +
> + for (i = 0; i <= st->odr; i++)
> + len += scnprintf(buf + len, PAGE_SIZE - len,
> + "%d ", adxl372_bw_freq_tbl[i]);
> +
> + buf[len - 1] = '\n';
> +
> + return len;
> +}
> +
> static ssize_t adxl372_get_fifo_enabled(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -838,9 +869,12 @@ static const struct iio_trigger_ops adxl372_trigger_ops
> = {
> };
>
> static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
> +static IIO_DEVICE_ATTR(in_accel_filter_low_pass_3db_frequency_available,
> +0444, adxl372_show_filter_freq_avail, NULL, 0);
>
> static struct attribute *adxl372_attributes[] = {
> _const_attr_sampling_frequency_available.dev_attr.attr,
> +
> _dev_attr_in_accel_filter_low_pass_3db_frequency_available.dev_attr.attr,
> NULL,
> };
>
Re: [PATCH 3/3] iio:adxl372: Add filter bandwidth support
On Mon, 20 Aug 2018 17:54:55 +0300
Stefan Popa wrote:
> This patch adds the option for the user to select the filter bandwidth. The
> user can also read the available bandwidths which are always adjusted to be
> at most half of the sampling frequency. Furthermore, the currently selected
> bandwidth can be read via the read_raw function, while the write_raw sets a
> new bandwidth value.
>
> Signed-off-by: Stefan Popa
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/accel/adxl372.c | 38 --
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index 6281e4a..fdaaa58 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -202,6 +202,10 @@ static const int adxl372_samp_freq_tbl[5] = {
> 400, 800, 1600, 3200, 6400,
> };
>
> +static const int adxl372_bw_freq_tbl[5] = {
> + 200, 400, 800, 1600, 3200,
> +};
> +
> struct adxl372_axis_lookup {
> unsigned int bits;
> enum adxl372_fifo_format fifo_format;
> @@ -224,7 +228,8 @@ static const struct adxl372_axis_lookup
> adxl372_axis_lookup_table[] = {
> .channel2 = IIO_MOD_##axis, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) | \
> - BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY), \
> .scan_index = index,\
> .scan_type = { \
> .sign = 's',\
> @@ -648,6 +653,9 @@ static int adxl372_read_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_SAMP_FREQ:
> *val = adxl372_samp_freq_tbl[st->odr];
> return IIO_VAL_INT;
> + case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
> + *val = adxl372_bw_freq_tbl[st->bw];
> + return IIO_VAL_INT;
> }
>
> return -EINVAL;
> @@ -658,7 +666,7 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
>int val, int val2, long info)
> {
> struct adxl372_state *st = iio_priv(indio_dev);
> - int odr_index, ret;
> + int odr_index, bw_index, ret;
>
> switch (info) {
> case IIO_CHAN_INFO_SAMP_FREQ:
> @@ -690,11 +698,34 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
> ret = adxl372_set_bandwidth(st, odr_index);
>
> return ret;
> + case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
> + bw_index = adxl372_find_closest_match(adxl372_bw_freq_tbl,
> + ARRAY_SIZE(adxl372_bw_freq_tbl),
> + val);
> + return adxl372_set_bandwidth(st, bw_index);
> default:
> return -EINVAL;
> }
> }
>
> +static ssize_t adxl372_show_filter_freq_avail(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct adxl372_state *st = iio_priv(indio_dev);
> + int i;
> + size_t len = 0;
> +
> + for (i = 0; i <= st->odr; i++)
> + len += scnprintf(buf + len, PAGE_SIZE - len,
> + "%d ", adxl372_bw_freq_tbl[i]);
> +
> + buf[len - 1] = '\n';
> +
> + return len;
> +}
> +
> static ssize_t adxl372_get_fifo_enabled(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -838,9 +869,12 @@ static const struct iio_trigger_ops adxl372_trigger_ops
> = {
> };
>
> static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
> +static IIO_DEVICE_ATTR(in_accel_filter_low_pass_3db_frequency_available,
> +0444, adxl372_show_filter_freq_avail, NULL, 0);
>
> static struct attribute *adxl372_attributes[] = {
> _const_attr_sampling_frequency_available.dev_attr.attr,
> +
> _dev_attr_in_accel_filter_low_pass_3db_frequency_available.dev_attr.attr,
> NULL,
> };
>
