Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 05:14 PM, Dave Hansen wrote: On 01/04/2017 04:05 PM, Rob Gardner wrote: What if two different small pages have different tags and khugepaged comes along and tries to collapse them? Will the page be split if a user attempts to set two different tags inside two different small-page portions of a single THP? The MCD tags operate at a resolution of cache lines (64 bytes). Page sizes don't matter except that each virtual page must have a bit set in its TTE to allow MCD to be enabled on the page. Any page can have many different tags, one for each cache line. Is an "MCD tag" the same thing as a "ADI version tag"? The thing that confused me here is that we're taking an entire page of "ADI version tags" and stuffing them into a swap pte (in set_swp_pte_at()). Do we somehow have enough space in a swap pte on sparc to fit PAGE_SIZE/64 "ADI version tag"s in there? No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte. There is enough space for just one tag per page. DaveM had suggested doing this since the usual case is for a task to set one tag per page even though MMU does not require it. I have implemented this as first pass to start a discussion and get feedback on whether rest of the swapping implementation and other changes look right, hence the patch is "RFC". If this all looks good, I can expand swapping support in a subsequent patch or iteration of this patch to allocate space in mm_context_t possibly to store per cacheline tags. I am open to any other ideas on storing this larger number of version tags. Thanks, Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 04:05 PM, Rob Gardner wrote: >> What if two different small pages have different tags and khugepaged >> comes along and tries to collapse them? Will the page be split if a >> user attempts to set two different tags inside two different small-page >> portions of a single THP? > > The MCD tags operate at a resolution of cache lines (64 bytes). Page > sizes don't matter except that each virtual page must have a bit set in > its TTE to allow MCD to be enabled on the page. Any page can have many > different tags, one for each cache line. Is an "MCD tag" the same thing as a "ADI version tag"? The thing that confused me here is that we're taking an entire page of "ADI version tags" and stuffing them into a swap pte (in set_swp_pte_at()). Do we somehow have enough space in a swap pte on sparc to fit PAGE_SIZE/64 "ADI version tag"s in there? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 04:01 PM, Dave Hansen wrote: On 01/04/2017 03:58 PM, Khalid Aziz wrote: How does this all work with large pages? It works with large pages the same way as normal sized pages. The TTE for a large page also will have the mcd bit set in it and tags are set and referenced the same way. But does the user setting the tags need to know what the page size is? What if two different small pages have different tags and khugepaged comes along and tries to collapse them? Will the page be split if a user attempts to set two different tags inside two different small-page portions of a single THP? The MCD tags operate at a resolution of cache lines (64 bytes). Page sizes don't matter except that each virtual page must have a bit set in its TTE to allow MCD to be enabled on the page. Any page can have many different tags, one for each cache line. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 03:58 PM, Khalid Aziz wrote: >> How does this all work with large pages? > > It works with large pages the same way as normal sized pages. The TTE > for a large page also will have the mcd bit set in it and tags are set > and referenced the same way. But does the user setting the tags need to know what the page size is? What if two different small pages have different tags and khugepaged comes along and tries to collapse them? Will the page be split if a user attempts to set two different tags inside two different small-page portions of a single THP? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 04:49 PM, Dave Hansen wrote: On 01/04/2017 03:44 PM, Rob Gardner wrote: On 01/04/2017 03:40 PM, Dave Hansen wrote: On 01/04/2017 03:35 PM, Rob Gardner wrote: Tags are not cleared at all when memory is freed, but rather, lazily (and automatically) cleared when memory is allocated. What does "allocated" mean in this context? Physical or virtual? What does this do, for instance? The first time a virtual page is touched by a process after the malloc, the kernel does clear_user_page() or something similar, which zeroes the memory. At the same time, the memory tags are cleared. OK, so the tags can't survive a MADV_FREE. That's definitely something for apps to understand that use MADV_FREE as a substitute for memset(). It also means that tags can't be set for physically unallocated memory. Neither of those are deal killers, but it would be nice to document it. This can go into the adi.txt doc file. How does this all work with large pages? It works with large pages the same way as normal sized pages. The TTE for a large page also will have the mcd bit set in it and tags are set and referenced the same way. -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 03:49 PM, Dave Hansen wrote: On 01/04/2017 03:44 PM, Rob Gardner wrote: On 01/04/2017 03:40 PM, Dave Hansen wrote: On 01/04/2017 03:35 PM, Rob Gardner wrote: Tags are not cleared at all when memory is freed, but rather, lazily (and automatically) cleared when memory is allocated. What does "allocated" mean in this context? Physical or virtual? What does this do, for instance? The first time a virtual page is touched by a process after the malloc, the kernel does clear_user_page() or something similar, which zeroes the memory. At the same time, the memory tags are cleared. OK, so the tags can't survive a MADV_FREE. That's definitely something for apps to understand that use MADV_FREE as a substitute for memset(). It also means that tags can't be set for physically unallocated memory. Neither of those are deal killers, but it would be nice to document it. How does this all work with large pages? It all works completely with large pages. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 03:46 PM, Khalid Aziz wrote: >> It would also be really nice to see a high-level breakdown explaining >> what you had to modify, especially since this affects all of the system >> calls that take a PROT_* argument. The sample code is nice, but it's no >> substitute for writing it down. > > I will expand the explanation in Documentation/sparc/adi.txt. I think (partially) duplicating that in a cover letter would also be nice. The documentation is a bit buried in the 1,000 lines of code. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 03:44 PM, Rob Gardner wrote: > On 01/04/2017 03:40 PM, Dave Hansen wrote: >> On 01/04/2017 03:35 PM, Rob Gardner wrote: >>> Tags are not cleared at all when memory is freed, but rather, lazily >>> (and automatically) cleared when memory is allocated. >> What does "allocated" mean in this context? Physical or virtual? What >> does this do, for instance? > > The first time a virtual page is touched by a process after the malloc, > the kernel does clear_user_page() or something similar, which zeroes the > memory. At the same time, the memory tags are cleared. OK, so the tags can't survive a MADV_FREE. That's definitely something for apps to understand that use MADV_FREE as a substitute for memset(). It also means that tags can't be set for physically unallocated memory. Neither of those are deal killers, but it would be nice to document it. How does this all work with large pages? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 04:31 PM, Dave Hansen wrote: One other high-level comment: It would be nice to see the arch-independent and x86 portions broken out and explained in their own right, even if they're small patches. It's a bit cruel to make us scroll through a thousand lines of sparc code to see the bits interesting to us. Sure, that is very reasonable. I will do that. It would also be really nice to see a high-level breakdown explaining what you had to modify, especially since this affects all of the system calls that take a PROT_* argument. The sample code is nice, but it's no substitute for writing it down. I will expand the explanation in Documentation/sparc/adi.txt. Thanks! -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 04:27 PM, Dave Hansen wrote: On 01/04/2017 02:46 PM, Khalid Aziz wrote: This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable MCD (Memory Corruption Detection) on selected memory ranges, enable TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI version tags on page swap out/in. I'm a bit confused why we need all the mechanics with set_swp_pte_at(). For pkeys, for instance, all of the PTEs under a given VMA share a pkey. When swapping something in, we just get the pkey out of the VMA and populate the PTE. ADI doesn't seem to have a similar restriction. The feature is turned on or off at a VMA granularity, but we do not (or can enforce that all pages under a given VMA must share a tag. But this leads to an interesting question: is the tag associated with the (populated?) pte, or the virtual address? Can you have tags associated with non-present addresses? What's the mechanism that clears the tags at munmap() or MADV_FREE time? Hi Dave, Tag is associated with virtual address and all pages in a singular VMA do not share the same tag. When a page is swapped out, we need to save the tag that was set on it so we can restore it when we bring the page back in. When MMU translates a vitrtual address into physical address, it expects to see the same tag set on the physical page as is set in the VA before it will allow access. Tags are cleared on a page by NG4clear_page() and NG4clear_user_page() when a page is allocated to a task. Is the tag storage a precious resource? Can it be exhausted? There is a metadata area in RAM that stores the tags and it has enough space to cover all the tags for the RAM size. -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 03:40 PM, Dave Hansen wrote:
On 01/04/2017 03:35 PM, Rob Gardner wrote:
Tags are not cleared at all when memory is freed, but rather, lazily
(and automatically) cleared when memory is allocated.
What does "allocated" mean in this context? Physical or virtual? What
does this do, for instance?
The first time a virtual page is touched by a process after the malloc,
the kernel does clear_user_page() or something similar, which zeroes the
memory. At the same time, the memory tags are cleared.
Rob
ptr = malloc(PAGE_SIZE);
set_tag(ptr, 14);
madvise(ptr, PAGE_SIZE, MADV_FREE);
printf("tag: %d\n", get_tag(ptr));
free(ptr);
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 03:35 PM, Rob Gardner wrote:
> Tags are not cleared at all when memory is freed, but rather, lazily
> (and automatically) cleared when memory is allocated.
What does "allocated" mean in this context? Physical or virtual? What
does this do, for instance?
ptr = malloc(PAGE_SIZE);
set_tag(ptr, 14);
madvise(ptr, PAGE_SIZE, MADV_FREE);
printf("tag: %d\n", get_tag(ptr));
free(ptr);
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 03:27 PM, Dave Hansen wrote: On 01/04/2017 02:46 PM, Khalid Aziz wrote: This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable MCD (Memory Corruption Detection) on selected memory ranges, enable TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI version tags on page swap out/in. I'm a bit confused why we need all the mechanics with set_swp_pte_at(). For pkeys, for instance, all of the PTEs under a given VMA share a pkey. When swapping something in, we just get the pkey out of the VMA and populate the PTE. ADI doesn't seem to have a similar restriction. The feature is turned on or off at a VMA granularity, but we do not (or can enforce that all pages under a given VMA must share a tag. But this leads to an interesting question: is the tag associated with the (populated?) pte, or the virtual address? Can you have tags associated with non-present addresses? What's the mechanism that clears the tags at munmap() or MADV_FREE time? Is the tag storage a precious resource? Can it be exhausted? Tags are stored in physical memory, so there is no "tag storage" that can be exhausted. Tags are not cleared at all when memory is freed, but rather, lazily (and automatically) cleared when memory is allocated. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
One other high-level comment: It would be nice to see the arch-independent and x86 portions broken out and explained in their own right, even if they're small patches. It's a bit cruel to make us scroll through a thousand lines of sparc code to see the bits interesting to us. It would also be really nice to see a high-level breakdown explaining what you had to modify, especially since this affects all of the system calls that take a PROT_* argument. The sample code is nice, but it's no substitute for writing it down. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 02:46 PM, Khalid Aziz wrote: > This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable > MCD (Memory Corruption Detection) on selected memory ranges, enable > TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI > version tags on page swap out/in. I'm a bit confused why we need all the mechanics with set_swp_pte_at(). For pkeys, for instance, all of the PTEs under a given VMA share a pkey. When swapping something in, we just get the pkey out of the VMA and populate the PTE. ADI doesn't seem to have a similar restriction. The feature is turned on or off at a VMA granularity, but we do not (or can enforce that all pages under a given VMA must share a tag. But this leads to an interesting question: is the tag associated with the (populated?) pte, or the virtual address? Can you have tags associated with non-present addresses? What's the mechanism that clears the tags at munmap() or MADV_FREE time? Is the tag storage a precious resource? Can it be exhausted? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
ADI is a new feature supported on sparc M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data pages. Upper bits of the address contain the version tag. On M7 processors, upper four bits (bits 63-60) contain the version tag. If a rogue app attempts to access ADI enabled data pages, its access is blocked and processor generates an exception. This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable MCD (Memory Corruption Detection) on selected memory ranges, enable TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI version tags on page swap out/in. It also adds handlers for all traps related to MCD. ADI is not enabled by default for any task. A task must explicitly enable ADI on a memory range and set version tag for ADI to be effective for the task. Signed-off-by: Khalid Aziz Cc: Khalid Aziz --- v2: - Fixed a build error v3: - Removed CONFIG_SPARC_ADI - Replaced prctl commands with mprotect - Added auxiliary vectors for ADI parameters - Enabled ADI for swappable pages Documentation/sparc/adi.txt | 239 arch/sparc/include/asm/adi.h| 6 + arch/sparc/include/asm/adi_64.h | 46 ++ arch/sparc/include/asm/elf_64.h | 8 ++ arch/sparc/include/asm/hugetlb.h| 13 ++ arch/sparc/include/asm/hypervisor.h | 2 + arch/sparc/include/asm/mman.h | 40 +- arch/sparc/include/asm/mmu_64.h | 2 + arch/sparc/include/asm/mmu_context_64.h | 32 + arch/sparc/include/asm/pgtable_64.h | 97 - arch/sparc/include/asm/ttable.h | 10 ++ arch/sparc/include/asm/uaccess_64.h | 120 +++- arch/sparc/include/uapi/asm/asi.h | 5 + arch/sparc/include/uapi/asm/auxvec.h| 8 ++ arch/sparc/include/uapi/asm/mman.h | 2 + arch/sparc/include/uapi/asm/pstate.h| 10 ++ arch/sparc/kernel/Makefile | 1 + arch/sparc/kernel/adi_64.c | 93 + arch/sparc/kernel/entry.h | 3 + arch/sparc/kernel/head_64.S | 1 + arch/sparc/kernel/mdesc.c | 4 + arch/sparc/kernel/process_64.c | 21 +++ arch/sparc/kernel/sun4v_mcd.S | 16 +++ arch/sparc/kernel/traps_64.c| 142 ++- arch/sparc/kernel/ttable_64.S | 6 +- arch/sparc/mm/gup.c | 37 + arch/sparc/mm/tlb.c | 28 arch/x86/kernel/signal_compat.c | 2 +- include/asm-generic/pgtable.h | 5 + include/linux/mm.h | 2 + include/uapi/asm-generic/siginfo.h | 5 +- mm/memory.c | 2 +- mm/rmap.c | 4 +- 33 files changed, 993 insertions(+), 19 deletions(-) create mode 100644 Documentation/sparc/adi.txt create mode 100644 arch/sparc/include/asm/adi.h create mode 100644 arch/sparc/include/asm/adi_64.h create mode 100644 arch/sparc/kernel/adi_64.c create mode 100644 arch/sparc/kernel/sun4v_mcd.S diff --git a/Documentation/sparc/adi.txt b/Documentation/sparc/adi.txt new file mode 100644 index 000..18aa6d0 --- /dev/null +++ b/Documentation/sparc/adi.txt @@ -0,0 +1,239 @@ +Application Data Integrity (ADI) + + +Sparc M7 processor adds the Application Data Integrity (ADI) feature. +ADI allows a task to set version tags on any subset of its address +space. Once ADI is enabled and version tags are set for ranges of +address space of a task, the processor will compare the tag in pointers +to memory in these ranges to the version set by the application +previously. Access to memory is granted only if the tag in given +pointer matches the tag set by the application. In case of mismatch, +processor raises an exception. + +Following steps must be taken by a task to enable ADI fully: + +1. Set the user mode PSTATE.mcde bit + +2. Set TTE.mcd bit on any TLB entries that correspond to the range of +addresses ADI is being enabled on. + +3. Set the version tag for memory addresses. + +ADI is enabled on a set of pages using mprotect() with PROT_ADI flag. +When ADI is enabled on a set of pages by a task for the first time, +kernel sets the PSTATE.mcde bit fot the task. Version tags for memory +addresses are set with an stxa instruction on the addresses using +ASI_MCD_PRIMARY or ASI_MCD_ST_BLKINIT_PRIMARY. Version tags are +specified in bits 63-60 of address and are set on memory the size of ADI +block size. ADI block size is provided by the hypervisor to the kernel. +Kernel returns the value of ADI block size to userspace using auxiliary +vector along with other ADI info. Following auxiliary vectors are +provided by the kernel: + +
Re: [PATCH] Documentation: cpufreq: Update supported powernv processors
On Wed, Jan 4, 2017 at 11:20 PM, Jonathan Corbet wrote: > On Wed, 04 Jan 2017 23:11:30 +0100 > "Rafael J. Wysocki" wrote: > >> I'm assuming then, that you're going to handle cpufreq docs changes in the >> future. >> >> Some cpufreq patches update the docs too, though, so there may be changes in >> there coming from two sources. > > I saw it wasn't in linux-next yet, so figured I had to. :) Well, it actually is there in my linux-next branch and I was going to include it in the next pull request. Still, I can drop it easily enough. :-) > If you'd rather I stayed away from there, I'll happily do so, just say > the word (and preferably send a MAINTAINERS update :). I can handle cpufreq docs updates, but if you think it's better to route them via the docs tree, that would be fine by me too. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: cpufreq: Update supported powernv processors
On Wed, 04 Jan 2017 23:11:30 +0100 "Rafael J. Wysocki" wrote: > I'm assuming then, that you're going to handle cpufreq docs changes in the > future. > > Some cpufreq patches update the docs too, though, so there may be changes in > there coming from two sources. I saw it wasn't in linux-next yet, so figured I had to. :) If you'd rather I stayed away from there, I'll happily do so, just say the word (and preferably send a MAINTAINERS update :). Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: cpufreq: Update supported powernv processors
On Wednesday, January 04, 2017 02:35:27 PM Jonathan Corbet wrote: > On Mon, 2 Jan 2017 12:38:15 +0530 > Viresh Kumar wrote: > > > > +The following POWER processors are supported in powernv mode: > > > +POWER8 > > > +POWER9 > > I've applied this to the docs tree, thanks. OK I'm assuming then, that you're going to handle cpufreq docs changes in the future. Some cpufreq patches update the docs too, though, so there may be changes in there coming from two sources. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] kernel-doc tweaks and cleanup of rST vs. non-rST backends
On Mon, 2 Jan 2017 16:22:22 +0100 Paolo Bonzini wrote: > these patches are the result of my experiments with using kernel-doc > for QEMU's documentation. Patches 1 and 2 should be relatively > straightforward, as they are simple bugfixes. Patches 3 to 5, instead, > are making the docbook backend (and the others too) more consistent with > the input and output of the rST backend. > > I am not sure what is the state of the kernel-doc non-rST backends; > but there are still several books using the docbook workflow, so I'm > trying my luck and sending the patches anyway. :) I've played with them a bit, and they don't seem to break things, so I'll go ahead and apply them. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Doc: Correct PPS doc to reflect code location
On Sat, 24 Dec 2016 16:27:29 +0800 Sanjeev wrote: > timepps.h , as well as PPS sample test utilities, are > no longer in the kernel tree. Update documentation > to point to new locations. I've applied the set to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: fix spelling mistakes of "Celcius" -- > "Celsius"
On Wed, 28 Dec 2016 21:51:37 + Colin King wrote: > Documentation/hwmon/ds1621| 8 > Documentation/thermal/nouveau_thermal | 2 +- > 2 files changed, 5 insertions(+), 5 deletions(-) Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: cpufreq: Update supported powernv processors
On Mon, 2 Jan 2017 12:38:15 +0530 Viresh Kumar wrote: > > +The following POWER processors are supported in powernv mode: > > +POWER8 > > +POWER9 I've applied this to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] docs: IIO documentation sphinx conversion
On Sun, 1 Jan 2017 12:32:45 + Jonathan Cameron wrote: > This is a manual conversion of the existing DocBook documentation > for IIO. The intent is not to substantially change any of the > content in this patch, but to give a base to build upon. This looks good. Applied to the docs-tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: sphinx-extensions: make rstFlatTable work with docutils 0.13
On Sun, Dec 18, 2016 at 01:38:42PM -0700, Jonathan Corbet wrote: > > In docutils 0.13, the return type of get_column_widths method of the > > Table directive has changed [1], which breaks our flat-table directive > > and leads to a TypeError when trying to build the docs [2]. > > > > This patch adds support for the new return type, while keeping support > > for older docutils versions too. > > OK, I pulled in docutils 0.13 (virtualenv is great stuff) and was able to > verify both the problem and the fix. Applied to doc-next with a > cc: stable. I'll send it Linusward in the near future. Just a small update: the breaking change was reverted [1] in docutils yesterday, so in the next release (0.13.2) get_column_widths() should return a list again. (My patch should continue working fine.) [1]: https://sourceforge.net/p/docutils/code/8010/ -- Dmitry Shachnev signature.asc Description: PGP signature
Re: [PATCH 0/5] kernel-doc tweaks and cleanup of rST vs. non-rST backends
On Wed, 04 Jan 2017, Paolo Bonzini wrote: > On 03/01/2017 10:57, Jani Nikula wrote: >> On Mon, 02 Jan 2017, Paolo Bonzini wrote: >>> Hi, >>> >>> these patches are the result of my experiments with using kernel-doc >>> for QEMU's documentation. Patches 1 and 2 should be relatively >>> straightforward, as they are simple bugfixes. Patches 3 to 5, instead, >>> are making the docbook backend (and the others too) more consistent with >>> the input and output of the rST backend. >> >> I did not test the patches, and for sure I will not attempt reviewing >> perl, but at a high level the changes seem sensible. >> >> Acked-by: Jani Nikula > > Thanks---Perl's not that bad, come on! :) FWIW 99% of all the Perl I've ever written or read is in kernel-doc...! >>> I am not sure what is the state of the kernel-doc non-rST backends; >>> but there are still several books using the docbook workflow, so I'm >>> trying my luck and sending the patches anyway. :) >> >> Obviously reStructuredText is the main output now and has to work, and >> DocBook is still used as you say, but hopefully you sneaked in >> regressions for the other formats so we can gauge if anyone cares! ;) > > Couldn't expect any other deprecation plan from a graphics guy! Auch, don't hit me below the belt! :p > FWIW I tested building the Sphinx and DocBook books and eyeballed the > output for both of them. I also tested manually the list backend on toy > testcases, and of course it is used by docproc when building DocBook > manuals. I didn't test the other backends. BTW one thing I did a lot while making supposedly benign changes to kernel-doc was: $ make cleandocs $ make htmldocs $ mv Documentation/output Documentation/output.before $ # apply the change $ make htmldocs $ diff -r Documentation/output.before Documentation/output There's some noise from .doctrees that you can safely ignore, but otherwise it was a life saver. BR, Jani. > > Paolo -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] kernel-doc tweaks and cleanup of rST vs. non-rST backends
On 03/01/2017 10:57, Jani Nikula wrote: > On Mon, 02 Jan 2017, Paolo Bonzini wrote: >> Hi, >> >> these patches are the result of my experiments with using kernel-doc >> for QEMU's documentation. Patches 1 and 2 should be relatively >> straightforward, as they are simple bugfixes. Patches 3 to 5, instead, >> are making the docbook backend (and the others too) more consistent with >> the input and output of the rST backend. > > I did not test the patches, and for sure I will not attempt reviewing > perl, but at a high level the changes seem sensible. > > Acked-by: Jani Nikula Thanks---Perl's not that bad, come on! :) >> I am not sure what is the state of the kernel-doc non-rST backends; >> but there are still several books using the docbook workflow, so I'm >> trying my luck and sending the patches anyway. :) > > Obviously reStructuredText is the main output now and has to work, and > DocBook is still used as you say, but hopefully you sneaked in > regressions for the other formats so we can gauge if anyone cares! ;) Couldn't expect any other deprecation plan from a graphics guy! FWIW I tested building the Sphinx and DocBook books and eyeballed the output for both of them. I also tested manually the list backend on toy testcases, and of course it is used by docproc when building DocBook manuals. I didn't test the other backends. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 07/12] dt-bindings: iio: iio-mux: document iio-mux bindings
Signed-off-by: Peter Rosin
---
.../bindings/iio/multiplexer/io-channel-mux.txt| 39 ++
MAINTAINERS| 6
2 files changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
diff --git
a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
new file mode 100644
index ..c82794002595
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
@@ -0,0 +1,39 @@
+I/O channel multiplexer bindings
+
+If a multiplexer is used to select which hardware signal is fed to
+e.g. an ADC channel, these bindings describe that situation.
+
+Required properties:
+- compatible : "io-channel-mux"
+- io-channels : Channel node of the parent channel that has multiplexed
+ input.
+- io-channel-names : Should be "parent".
+- #address-cells = <1>;
+- #size-cells = <0>;
+- mux-controls : Mux controller node to use for operating the mux
+- channels : List of strings, labeling the mux controller states.
+
+For each non-empty string in the channels property, an io-channel will
+be created. The number of this io-channel is the same as the index into
+the list of strings in the channels property, and also matches the mux
+controller state. The mux controller state is described in
+../mux/mux-controller.txt
+
+Example:
+ mux: mux-controller {
+ compatible = "mux-gpio";
+ #mux-control-cells = <0>;
+
+ mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
+ <&pioA 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+
+ mux-controls = <&mux>;
+
+ channels = "sync", "in", "system-regulator";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ebe96f3e25a0..91775f2be209 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6274,6 +6274,12 @@ F:
Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
F: drivers/iio/adc/envelope-detector.c
+IIO MULTIPLEXER
+M: Peter Rosin
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
+
IIO SUBSYSTEM AND DRIVERS
M: Jonathan Cameron
R: Hartmut Knaack
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 06/12] iio: inkern: api for manipulating ext_info of iio channels
Extend the inkern api with functions for reading and writing ext_info
of iio channels.
Acked-by: Jonathan Cameron
Signed-off-by: Peter Rosin
---
drivers/iio/inkern.c | 60
include/linux/iio/consumer.h | 37 +++
2 files changed, 97 insertions(+)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index b0f4630a163f..4848b8129e6c 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -863,3 +863,63 @@ int iio_write_channel_raw(struct iio_channel *chan, int
val)
return ret;
}
EXPORT_SYMBOL_GPL(iio_write_channel_raw);
+
+unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
+{
+ const struct iio_chan_spec_ext_info *ext_info;
+ unsigned int i = 0;
+
+ if (!chan->channel->ext_info)
+ return i;
+
+ for (ext_info = chan->channel->ext_info; ext_info->name; ext_info++)
+ ++i;
+
+ return i;
+}
+EXPORT_SYMBOL_GPL(iio_get_channel_ext_info_count);
+
+static const struct iio_chan_spec_ext_info *iio_lookup_ext_info(
+ const struct iio_channel *chan,
+ const char *attr)
+{
+ const struct iio_chan_spec_ext_info *ext_info;
+
+ if (!chan->channel->ext_info)
+ return NULL;
+
+ for (ext_info = chan->channel->ext_info; ext_info->name; ++ext_info) {
+ if (!strcmp(attr, ext_info->name))
+ return ext_info;
+ }
+
+ return NULL;
+}
+
+ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
+ const char *attr, char *buf)
+{
+ const struct iio_chan_spec_ext_info *ext_info;
+
+ ext_info = iio_lookup_ext_info(chan, attr);
+ if (!ext_info)
+ return -EINVAL;
+
+ return ext_info->read(chan->indio_dev, ext_info->private,
+ chan->channel, buf);
+}
+EXPORT_SYMBOL_GPL(iio_read_channel_ext_info);
+
+ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
+ const char *buf, size_t len)
+{
+ const struct iio_chan_spec_ext_info *ext_info;
+
+ ext_info = iio_lookup_ext_info(chan, attr);
+ if (!ext_info)
+ return -EINVAL;
+
+ return ext_info->write(chan->indio_dev, ext_info->private,
+ chan->channel, buf, len);
+}
+EXPORT_SYMBOL_GPL(iio_write_channel_ext_info);
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 47eeec3218b5..5e347a9805fd 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -312,4 +312,41 @@ int iio_read_channel_scale(struct iio_channel *chan, int
*val,
int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
int *processed, unsigned int scale);
+/**
+ * iio_get_channel_ext_info_count() - get number of ext_info attributes
+ * connected to the channel.
+ * @chan: The channel being queried
+ *
+ * Returns the number of ext_info attributes
+ */
+unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan);
+
+/**
+ * iio_read_channel_ext_info() - read ext_info attribute from a given channel
+ * @chan: The channel being queried.
+ * @attr: The ext_info attribute to read.
+ * @buf: Where to store the attribute value. Assumed to hold
+ * at least PAGE_SIZE bytes.
+ *
+ * Returns the number of bytes written to buf (perhaps w/o zero termination;
+ * it need not even be a string), or an error code.
+ */
+ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
+ const char *attr, char *buf);
+
+/**
+ * iio_write_channel_ext_info() - write ext_info attribute from a given channel
+ * @chan: The channel being queried.
+ * @attr: The ext_info attribute to read.
+ * @buf: The new attribute value. Strings needs to be zero-
+ * terminated, but the terminator should not be included
+ * in the below len.
+ * @len: The size of the new attribute value.
+ *
+ * Returns the number of accepted bytes, which should be the same as len.
+ * An error code can also be returned.
+ */
+ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
+ const char *buf, size_t len);
+
#endif
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 00/12] mux controller abstraction and iio/i2c muxes
Hi!
v6 -> v7 changes
- move from drivers/misc/mux-* to drivers/mux/
[I will remove Cc:s to Arnd and Greg for v8, when/if that happens]
- add managed versions of mux_chip_alloc and mux_chip_register
- use the above in mux-gpio.c and mux-adg792a.c
- also use them to support a simplified binding of a gpio mux for the common
case where there is a single consumer (and no specific idle requirements)
- new binding for describing idle behaviour of mux-adg792a
- add bindings for the gpo-pins on the mux-adg792g
- use device_property_read_u32 instead of of_property_read_u32 in mux-gpio.c
- rename iio mux compatible to io-channel-mux (was iio-mux)
- remove linuxism in the bindings (it was mentioning a function name)
- add missing quote in the example in the io-channel-mux binding
- factor out preparatory cleanup of devres docs to its own patch
- add blank line in mux_chip_free
- use SIMPLE_{PARENT,MUX}_LOCKED instead of magic numbers {0,1} in
i2c-mux-simple.c
- add some acks and a reviewed-by from Jonathan
v5 -> v6 changes
- fix stupidity in mux_chip_priv, mux_gpio_remove and adg792a_remove.
- change the devicetree bindings for the iio-mux to use a list of strings
(channels property) instead of a list children.
v4 -> v5 changes
- remove support for fancier dt layouts and go back to the phandle
approach from v2 and before, killing the horrible non-working
refcounting crap from v4 and avoiding a bunch of life-time issues
in v3.
- introduce the concept of a mux-chip, that can hold one or more
mux-controllers (inspired by the pwm subsystem).
- add dt #mux-control-cells property needed to get to the desired
mux controller if a mux chip provides more than one.
- take away the option to build the mux-core as a module.
- if the mux controller has an idle state, make sure the mux controller
is set up in the idle state initially (when it should be idle).
- do not use a variable length array on the stack in mux_gpio_set to
temporarily store the gpio state, preallocate space instead.
- fix resource leak on one failure path in mux_gpio_probe.
- driver for Analog Devices ADG792A/G, literally the first mux chip
I found on the Internet with an i2c interface (that was not a
dedicated i2c multiplexer like PCA9547) which I used to verify
that the abstractions in the mux core are up to the task. Untested,
just proof of concept that at least looks pretty and compiles...
- various touch-ups.
v3 -> v4 changes
- rebased onto next-20161122 (depends on recent _available iio changes).
- added support for having the mux-controller in a child node of a
mux-consumer if it is a sole consumer, to hopefully even further satisfy
the complaint from Rob (and later Lars-Peter) about dt complexity.
- the above came at the cost of some rather horrible refcounting code,
please review and suggest how it should be done...
- changed to register a device class instead of a bus.
- pass in the parent device into mux_control_alloc and require less
work from mux-control drivers.
- changed device names from mux:control%d to mux%d
- move kernel-doc from mux-core.c to mux.h (and add some bits).
- give the gpio driver a chance to update all mux pins at once.
- factor out iio ext_info lookup into new helper function. /Lars-Peter
- use an unsigned type for the iio ext_info count. /Lars-Peter
- unified "brag strings" in the file headers.
v2 -> v3 changes
- have the mux-controller in the parent node of any mux-controller consumer,
to hopefully satisfy complaint from Rob about dt complexity.
- improve commit message of the mux subsystem commit, making it more
general, as requested by Jonathan.
- remove priv member from struct mux_control and calculate it on the
fly. /Jonathan
- make the function comments in mux-core.c kernel doc. /Jonathan
- add devm_mux_control_* to Documentation/driver.model/devres.txt. /Jonathan
- add common dt bindings for mux-controllers, refer to them from the
mux-gpio bindings. /Rob
- clarify how the gpio pins map to the mux state. /Rob
- separate CONFIG_ variables for the mux core and the mux gpio driver.
- improve Kconfig help texts.
- make CONFIG_MUX_GPIO depend on CONFIG_GPIOLIB.
- keep track of the number of mux states in the mux core.
- since the iio channel number is used as mux state, it was possible
to drop the state member from the mux_child struct.
- cleanup dt bindings for i2c-mux-simple, it had some of copy-paste
problems from ots origin (i2c-mux-gpio).
- select the mux control subsystem in config for the i2c-mux-simple driver.
- add entries to MAINTAINERS and my sign-off, I'm now satisfied and know
nothing in this to be ashamed of.
v1 -> v2 changes
- fixup export of mux_control_put reported by kbuild
- drop devicetree iio-ext-info property as noted by Lars-Peter,
and replace the functionality by exposing all ext_info
attributes of the parent channel for each of the muxed
channels. A cache on top of that and each muxed channel
gets its own view of the ext_info of the paren
[PATCH v7 05/12] mux: support simplified bindings for single-user gpio mux
Signed-off-by: Peter Rosin
---
drivers/mux/mux-core.c | 81 --
drivers/mux/mux-gpio.c | 56 ++
include/linux/mux.h| 7 +
3 files changed, 89 insertions(+), 55 deletions(-)
diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
index 21da15a264ad..d887ae1c0e55 100644
--- a/drivers/mux/mux-core.c
+++ b/drivers/mux/mux-core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -288,6 +289,63 @@ static struct mux_chip *of_find_mux_chip_by_node(struct
device_node *np)
return dev ? to_mux_chip(dev) : NULL;
}
+#ifdef CONFIG_MUX_GPIO
+
+static int mux_gpio_set(struct mux_control *mux, int state)
+{
+ struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
+ int i;
+
+ for (i = 0; i < mux_gpio->gpios->ndescs; i++)
+ mux_gpio->val[i] = (state >> i) & 1;
+
+ gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
+ mux_gpio->gpios->desc,
+ mux_gpio->val);
+
+ return 0;
+}
+
+static const struct mux_control_ops mux_gpio_ops = {
+ .set = mux_gpio_set,
+};
+
+struct mux_chip *mux_gpio_alloc(struct device *dev)
+{
+ struct mux_chip *mux_chip;
+ struct mux_gpio *mux_gpio;
+ int pins;
+ int ret;
+
+ pins = gpiod_count(dev, "mux");
+ if (pins < 0)
+ return ERR_PTR(pins);
+
+ mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
+ pins * sizeof(*mux_gpio->val));
+ if (!mux_chip)
+ return ERR_PTR(-ENOMEM);
+
+ mux_gpio = mux_chip_priv(mux_chip);
+ mux_gpio->val = (int *)(mux_gpio + 1);
+ mux_chip->ops = &mux_gpio_ops;
+
+ mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
+ if (IS_ERR(mux_gpio->gpios)) {
+ ret = PTR_ERR(mux_gpio->gpios);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "failed to get gpios\n");
+ return ERR_PTR(ret);
+ }
+ WARN_ON(pins != mux_gpio->gpios->ndescs);
+ mux_chip->mux->states = 1 << pins;
+
+ return mux_chip;
+}
+EXPORT_SYMBOL_GPL(mux_gpio_alloc);
+
+#endif /* CONFIG_MUX_GPIO */
+
struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
{
struct device_node *np = dev->of_node;
@@ -307,9 +365,28 @@ struct mux_control *mux_control_get(struct device *dev,
const char *mux_name)
ret = of_parse_phandle_with_args(np,
"mux-controls", "#mux-control-cells",
index, &args);
+
+#ifdef CONFIG_MUX_GPIO
+ if (ret == -ENOENT && !mux_name && gpiod_count(dev, "mux") > 0) {
+ mux_chip = mux_gpio_alloc(dev);
+ if (!IS_ERR(mux_chip)) {
+ ret = devm_mux_chip_register(dev, mux_chip);
+ if (ret < 0) {
+ dev_err(dev, "failed to register mux-chip\n");
+ return ERR_PTR(ret);
+ }
+ get_device(&mux_chip->dev);
+ return mux_chip->mux;
+ }
+
+ ret = PTR_ERR(mux_chip);
+ }
+#endif
+
if (ret) {
- dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
- np->full_name, mux_name ?: "", index);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
+ np->full_name, mux_name ?: "", index);
return ERR_PTR(ret);
}
diff --git a/drivers/mux/mux-gpio.c b/drivers/mux/mux-gpio.c
index 76b52bc63470..8a7bfbc0c4bb 100644
--- a/drivers/mux/mux-gpio.c
+++ b/drivers/mux/mux-gpio.c
@@ -11,37 +11,12 @@
*/
#include
-#include
#include
#include
#include
#include
#include
-struct mux_gpio {
- struct gpio_descs *gpios;
- int *val;
-};
-
-static int mux_gpio_set(struct mux_control *mux, int state)
-{
- struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
- int i;
-
- for (i = 0; i < mux_gpio->gpios->ndescs; i++)
- mux_gpio->val[i] = (state >> i) & 1;
-
- gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
- mux_gpio->gpios->desc,
- mux_gpio->val);
-
- return 0;
-}
-
-static const struct mux_control_ops mux_gpio_ops = {
- .set = mux_gpio_set,
-};
-
static const struct of_device_id mux_gpio_dt_ids[] = {
{ .compatible = "mux-gpio", },
{ /* sentinel */ }
@@ -51,38 +26,13 @@ MODULE_DEVICE_TABLE(of, mux_gpio_dt_ids);
static int mux_gpio_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct device_node *np = dev->of_no
[PATCH v7 09/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/i2c/i2c-mux-simple.txt | 81 ++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
new file mode 100644
index ..253d5027843b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
@@ -0,0 +1,81 @@
+Simple I2C Bus Mux
+
+This binding describes an I2C bus multiplexer that uses a mux controller
+from the mux subsystem to route the I2C signals.
+
+ .-. .-.
+ | dev | | dev |
+..'-' '-'
+| SoC| ||
+|| .+'
+| .--. | .--+child bus A, on MUX value set to 0
+| | I2C |-|--| Mux |
+| '--' | '--+---+child bus B, on MUX value set to 1
+| .--. | |'--++.
+| | MUX- | | | |||
+| | Ctrl |-|-+.-. .-. .-.
+| '--' | | dev | | dev | | dev |
+'' '-' '-' '-'
+
+Required properties:
+- compatible: i2c-mux-simple,mux-locked or i2c-mux-simple,parent-locked
+- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
+ port is connected to.
+- mux-controls: The phandle of the mux controller to use for operating the
+ mux.
+* Standard I2C mux properties. See i2c-mux.txt in this directory.
+* I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number
+ is also the mux-controller state described in ../mux/mux-controller.txt
+
+For each i2c child node, an I2C child bus will be created. They will
+be numbered based on their order in the device tree.
+
+Whenever an access is made to a device on a child bus, the value set
+in the relevant node's reg property will be set as the state in the
+mux controller.
+
+Example:
+ mux: mux-controller {
+ compatible = "mux-gpio";
+ #mux-control-cells = <0>;
+
+ mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
+ <&pioA 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ i2c-mux {
+ compatible = "i2c-mux-simple,mux-locked";
+ i2c-parent = <&i2c1>;
+
+ mux-controls = <&mux>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ssd1307: oled@3c {
+ compatible = "solomon,ssd1307fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ reset-gpios = <&gpio2 7 1>;
+ reset-active-low;
+ };
+ };
+
+ i2c@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pca9555: pca9555@20 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ };
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 10/12] i2c: i2c-mux-simple: new driver
This is a generic simple i2c mux that uses the generic multiplexer
subsystem to do the muxing.
The user can select if the mux is to be mux-locked and parent-locked
as described in Documentation/i2c/i2c-topology.
Acked-by: Jonathan Cameron
Signed-off-by: Peter Rosin
---
drivers/i2c/muxes/Kconfig | 13 +++
drivers/i2c/muxes/Makefile | 1 +
drivers/i2c/muxes/i2c-mux-simple.c | 182 +
3 files changed, 196 insertions(+)
create mode 100644 drivers/i2c/muxes/i2c-mux-simple.c
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17ae3ea..565921e09a96 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -73,6 +73,19 @@ config I2C_MUX_REG
This driver can also be built as a module. If so, the module
will be called i2c-mux-reg.
+config I2C_MUX_SIMPLE
+ tristate "Simple I2C multiplexer"
+ select MULTIPLEXER
+ depends on OF
+ help
+ If you say yes to this option, support will be included for a
+ simple generic I2C multiplexer. This driver provides access to
+ I2C busses connected through a MUX, which is controlled
+ by a generic MUX controller.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mux-simple.
+
config I2C_DEMUX_PINCTRL
tristate "pinctrl-based I2C demultiplexer"
depends on PINCTRL && OF
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa45037f..6821d95c92a3 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
obj-$(CONFIG_I2C_MUX_PINCTRL) += i2c-mux-pinctrl.o
obj-$(CONFIG_I2C_MUX_REG) += i2c-mux-reg.o
+obj-$(CONFIG_I2C_MUX_SIMPLE) += i2c-mux-simple.o
ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/muxes/i2c-mux-simple.c
b/drivers/i2c/muxes/i2c-mux-simple.c
new file mode 100644
index ..0d1421767c4c
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-simple.c
@@ -0,0 +1,182 @@
+/*
+ * Generic simple I2C multiplexer
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SIMPLE_PARENT_LOCKED (0)
+#define SIMPLE_MUX_LOCKED(1)
+
+struct mux {
+ struct mux_control *control;
+
+ bool do_not_deselect;
+};
+
+static int i2c_mux_select(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct mux *mux = i2c_mux_priv(muxc);
+ int ret;
+
+ ret = mux_control_select(mux->control, chan);
+ mux->do_not_deselect = ret < 0;
+
+ return ret;
+}
+
+static int i2c_mux_deselect(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct mux *mux = i2c_mux_priv(muxc);
+
+ if (mux->do_not_deselect)
+ return 0;
+
+ return mux_control_deselect(mux->control);
+}
+
+static struct i2c_adapter *mux_parent_adapter(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *parent_np;
+ struct i2c_adapter *parent;
+
+ parent_np = of_parse_phandle(np, "i2c-parent", 0);
+ if (!parent_np) {
+ dev_err(dev, "Cannot parse i2c-parent\n");
+ return ERR_PTR(-ENODEV);
+ }
+ parent = of_find_i2c_adapter_by_node(parent_np);
+ of_node_put(parent_np);
+ if (!parent)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return parent;
+}
+
+static const struct of_device_id i2c_mux_of_match[] = {
+ { .compatible = "i2c-mux-simple,parent-locked",
+ .data = (void *)SIMPLE_PARENT_LOCKED, },
+ { .compatible = "i2c-mux-simple,mux-locked",
+ .data = (void *)SIMPLE_MUX_LOCKED, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, i2c_mux_of_match);
+
+static int i2c_mux_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *child;
+ const struct of_device_id *match;
+ struct i2c_mux_core *muxc;
+ struct mux *mux;
+ struct i2c_adapter *parent;
+ int children;
+ int ret;
+
+ if (!np)
+ return -ENODEV;
+
+ mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
+ if (!mux)
+ return -ENOMEM;
+
+ mux->control = devm_mux_control_get(dev, NULL);
+ if (IS_ERR(mux->control)) {
+ if (PTR_ERR(mux->control) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get control-mux\n");
+ return PTR_ERR(mux->control);
+ }
+
+ parent = mux_parent_adapter(dev);
+ if (IS_ERR(parent)) {
+
[PATCH v7 11/12] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux
Analog Devices ADG792A/G is a triple 4:1 mux.
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/mux/mux-adg792a.txt| 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mux/mux-adg792a.txt
diff --git a/Documentation/devicetree/bindings/mux/mux-adg792a.txt
b/Documentation/devicetree/bindings/mux/mux-adg792a.txt
new file mode 100644
index ..0b26dd11f070
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/mux-adg792a.txt
@@ -0,0 +1,79 @@
+Bindings for Analog Devices ADG792A/G Triple 4:1 Multiplexers
+
+Required properties:
+- compatible : "adi,adg792a" or "adi,adg792g"
+- #mux-control-cells : <0> if parallel, or <1> if not.
+* Standard mux-controller bindings as decribed in mux-controller.txt
+
+Optional properties for ADG792G:
+- gpio-controller : if present, #gpio-cells below is required.
+- #gpio-cells : should be <2>
+ - First cell is the GPO line number, i.e. 0 or 1
+ - Second cell is used to specify active high (0)
+ or active low (1)
+
+Optional properties:
+- adi,parallel : if present, the three muxes are bound together with a single
+ mux controller, controlling all three muxes in parallel.
+- adi,idle-state : if present, array of 2-tuples with mux controller number
+ and state that mux controllers will have when idle. States 0 through 3
+ correspond to signals A through D in the datasheet.
+- adi,idle-high-impedance : if present, array of mux controller numbers that
+ should be in the disconnected high-impedance state when idle.
+
+Mux controller states 0 through 3 correspond to signals A through D in the
+datasheet. If a mux controller is mentioned in neither adi,idle-state nor
+adi,idle-high-impedance it is left in its previously selected state when idle.
+
+Example:
+
+ /*
+* Three independent mux controllers (of which one is used).
+* Mux 0 is disconnected when idle, mux 1 idles with signal C
+* and mux 2 idles with signal A.
+*/
+ &i2c0 {
+ mux: adg792a@50 {
+ compatible = "adi,adg792a";
+ reg = <0x50>;
+ #mux-control-cells = <1>;
+
+ adi,idle-high-impedance = <0>;
+ adi,idle-state = <1 2>, <2 0>;
+ };
+ };
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+
+ mux-controls = <&mux 1>;
+
+ channels = "sync-1", "", "out";
+ };
+
+
+ /*
+* Three parallel muxes with one mux controller, useful e.g. if
+* the adc is differential, thus needing two signals to be muxed
+* simultaneously for correct operation.
+*/
+ &i2c0 {
+ pmux: adg792a@50 {
+ compatible = "adi,adg792a";
+ reg = <0x50>;
+ #mux-control-cells = <0>;
+ adi,parallel;
+ };
+ };
+
+ diff-adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+
+ mux-controls = <&pmux>;
+
+ channels = "sync-1", "", "out";
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 12/12] mux: adg792a: add mux controller driver for ADG792A/G
Analog Devices ADG792A/G is a triple 4:1 mux.
Signed-off-by: Peter Rosin
---
drivers/mux/Kconfig | 12
drivers/mux/Makefile | 1 +
drivers/mux/mux-adg792a.c | 169 ++
3 files changed, 182 insertions(+)
create mode 100644 drivers/mux/mux-adg792a.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index de5a35ffe7af..39b06e19aa96 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -16,6 +16,18 @@ menuconfig MULTIPLEXER
if MULTIPLEXER
+config MUX_ADG792A
+ tristate "Analog Devices ADG792A/ADG792G Multiplexers"
+ depends on I2C
+ help
+ ADG792A and ADG792G Wide Bandwidth Triple 4:1 Multiplexers
+
+ The driver supports both operating the three multiplexers in
+ parallel and operating them independently.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-adg792a.
+
config MUX_GPIO
tristate "GPIO-controlled Multiplexer"
depends on OF && GPIOLIB
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index facc43da3648..fddbb073fc77 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -3,4 +3,5 @@
#
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
+obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
diff --git a/drivers/mux/mux-adg792a.c b/drivers/mux/mux-adg792a.c
new file mode 100644
index ..c6d5c4571e7c
--- /dev/null
+++ b/drivers/mux/mux-adg792a.c
@@ -0,0 +1,169 @@
+/*
+ * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#define ADG792A_LDSW BIT(0)
+#define ADG792A_RESET BIT(1)
+#define ADG792A_DISABLE(mux) (0x50 | (mux))
+#define ADG792A_DISABLE_ALL(0x5f)
+#define ADG792A_MUX(mux, state)(0xc0 | (((mux) + 1) << 2) | (state))
+#define ADG792A_MUX_ALL(state) (0xc0 | (state))
+
+#define ADG792A_DISABLE_STATE (4)
+
+static int adg792a_set(struct mux_control *mux, int state)
+{
+ struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
+ u8 cmd;
+
+ if (mux->chip->controllers == 1) {
+ /* parallel mux controller operation */
+ if (state == ADG792A_DISABLE_STATE)
+ cmd = ADG792A_DISABLE_ALL;
+ else
+ cmd = ADG792A_MUX_ALL(state);
+ } else {
+ unsigned int controller = mux_control_get_index(mux);
+
+ if (state == ADG792A_DISABLE_STATE)
+ cmd = ADG792A_DISABLE(controller);
+ else
+ cmd = ADG792A_MUX(controller, state);
+ }
+
+ return i2c_smbus_write_byte_data(i2c, cmd, ADG792A_LDSW);
+}
+
+static const struct mux_control_ops adg792a_ops = {
+ .set = adg792a_set,
+};
+
+static int adg792a_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+{
+ struct device *dev = &i2c->dev;
+ struct mux_chip *mux_chip;
+ bool parallel;
+ int count;
+ int ret;
+ int i;
+
+ parallel = of_property_read_bool(i2c->dev.of_node, "adi,parallel");
+
+ mux_chip = devm_mux_chip_alloc(dev, parallel ? 1 : 3, 0);
+ if (!mux_chip)
+ return -ENOMEM;
+
+ mux_chip->ops = &adg792a_ops;
+
+ ret = i2c_smbus_write_byte_data(i2c, ADG792A_DISABLE_ALL,
+ ADG792A_RESET | ADG792A_LDSW);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < mux_chip->controllers; ++i) {
+ struct mux_control *mux = &mux_chip->mux[i];
+
+ mux->states = 4;
+ }
+
+ count = of_property_count_u32_elems(dev->of_node, "adi,idle-state");
+ for (i = 0; i < count; i += 2) {
+ u32 index;
+ u32 idle_state;
+
+ ret = of_property_read_u32_index(dev->of_node,
+"adi,idle-state", i,
+&index);
+ if (ret < 0)
+ return ret;
+ if (index >= mux_chip->controllers) {
+ dev_err(dev, "invalid mux %u\n", index);
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32_index(dev->of_node,
+"adi,idle-state", i + 1,
+&idle_state);
+ if (ret < 0)
+ return ret;
+ if (idle_state >= ADG792A_DISABLE_STATE) {
+ dev_err(dev, "invali
[PATCH v7 02/12] dt-bindings: document devicetree bindings for mux-controllers and mux-gpio
Acked-by: Jonathan Cameron
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/mux/mux-controller.txt | 127 +
Documentation/devicetree/bindings/mux/mux-gpio.txt | 68 +++
MAINTAINERS| 5 +
3 files changed, 200 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt
create mode 100644 Documentation/devicetree/bindings/mux/mux-gpio.txt
diff --git a/Documentation/devicetree/bindings/mux/mux-controller.txt
b/Documentation/devicetree/bindings/mux/mux-controller.txt
new file mode 100644
index ..42b2177e5ae1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/mux-controller.txt
@@ -0,0 +1,127 @@
+Common multiplexer controller bindings
+==
+
+A multiplexer (or mux) controller will have one, or several, consumer devices
+that uses the mux controller. Thus, a mux controller can possibly control
+several parallel multiplexers. Presumably there will be at least one
+multiplexer needed by each consumer, but a single mux controller can of course
+control several multiplexers for a single consumer.
+
+A mux controller provides a number of states to its consumers, and the state
+space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer,
+0-7 for an 8-way multiplexer, etc.
+
+
+Consumers
+-
+
+Mux controller consumers should specify a list of mux controllers that they
+want to use with a property containing a 'mux-ctrl-list':
+
+ mux-ctrl-list ::= [mux-ctrl-list]
+ single-mux-ctrl ::= [mux-ctrl-specifier]
+ mux-ctrl-phandle : phandle to mux controller node
+ mux-ctrl-specifier : array of #mux-control-cells specifying the
+given mux controller (controller specific)
+
+Mux controller properties should be named "mux-controls". The exact meaning of
+each mux controller property must be documented in the device tree binding for
+each consumer. An optional property "mux-control-names" may contain a list of
+strings to label each of the mux controllers listed in the "mux-controls"
+property.
+
+Drivers for devices that use more than a single mux controller can use the
+"mux-control-names" property to map the name of the requested mux controller
+to an index into the list given by the "mux-controls" property.
+
+mux-ctrl-specifier typically encodes the chip-relative mux controller number.
+If the mux controller chip only provides a single mux controller, the
+mux-ctrl-specifier can typically be left out.
+
+Example:
+
+ /* One consumer of a 2-way mux controller (one GPIO-line) */
+ mux: mux-controller {
+ compatible = "mux-gpio";
+ #mux-control-cells = <0>;
+
+ mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+ mux-controls = <&mux>;
+ mux-control-names = "adc";
+
+ channels = "sync", "in";
+ };
+
+Note that in the example above, specifying the "mux-control-names" is redundant
+because there is only one mux controller in the list.
+
+ /*
+* Two consumers (one for an ADC line and one for an i2c bus) of
+* parallel 4-way multiplexers controlled by the same two GPIO-lines.
+*/
+ mux: mux-controller {
+ compatible = "mux-gpio";
+ #mux-control-cells = <0>;
+
+ mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
+ <&pioA 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+ mux-controls = <&mux>;
+
+ channels = "sync-1", "in", "out", "sync-2";
+ };
+
+ i2c-mux {
+ compatible = "i2c-mux-simple,mux-locked";
+ i2c-parent = <&i2c1>;
+ mux-controls = <&mux>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ssd1307: oled@3c {
+ /* ... */
+ };
+ };
+
+ i2c@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pca9555: pca9555@20 {
+ /* ... */
+ };
+ };
+ };
+
+
+Mux controller nodes
+
+
+Mux controller nodes must specify the number of cells used for the
+specifier using the '#mux-control-cells' property.
+
+An example mux controller might look like this:
+
+ mux: adg792a@50
[PATCH v7 01/12] devres: trivial whitespace fix
Signed-off-by: Peter Rosin --- Documentation/driver-model/devres.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index ca9d1eb46bc0..dc51fb024190 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -330,7 +330,7 @@ MEM devm_kzalloc() MFD - devm_mfd_add_devices() + devm_mfd_add_devices() PER-CPU MEM devm_alloc_percpu() -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 03/12] mux: minimal mux subsystem and gpio-based mux controller
Add a new minimalistic subsystem that handles multiplexer controllers. When multiplexers are used in various places in the kernel, and the same multiplexer controller can be used for several independent things, there should be one place to implement support for said multiplexer controller. A single multiplexer controller can also be used to control several parallel multiplexers, that are in turn used by different subsystems in the kernel, leading to a need to coordinate multiplexer accesses. The multiplexer subsystem handles this coordination. This new mux controller subsystem initially comes with a single backend driver that controls gpio based multiplexers. Even though not needed by this initial driver, the mux controller subsystem is prepared to handle chips with multiple (independent) mux controllers. Signed-off-by: Peter Rosin --- Documentation/driver-model/devres.txt | 8 + MAINTAINERS | 2 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/mux/Kconfig | 33 +++ drivers/mux/Makefile | 6 + drivers/mux/mux-core.c| 398 ++ drivers/mux/mux-gpio.c| 120 ++ include/linux/mux.h | 244 + 9 files changed, 814 insertions(+) create mode 100644 drivers/mux/Kconfig create mode 100644 drivers/mux/Makefile create mode 100644 drivers/mux/mux-core.c create mode 100644 drivers/mux/mux-gpio.c create mode 100644 include/linux/mux.h diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index dc51fb024190..1e9ae701a587 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -332,6 +332,14 @@ MEM MFD devm_mfd_add_devices() +MUX + devm_mux_chip_alloc() + devm_mux_chip_free() + devm_mux_chip_register() + devm_mux_chip_unregister() + devm_mux_control_get() + devm_mux_control_put() + PER-CPU MEM devm_alloc_percpu() devm_free_percpu() diff --git a/MAINTAINERS b/MAINTAINERS index 32abef2b6d05..ebe96f3e25a0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8442,6 +8442,8 @@ MULTIPLEXER SUBSYSTEM M: Peter Rosin S: Maintained F: Documentation/devicetree/bindings/mux/ +F: include/linux/mux.h +F: drivers/mux/ MULTISOUND SOUND DRIVER M: Andrew Veliath diff --git a/drivers/Kconfig b/drivers/Kconfig index e1e2066cecdb..993aeb65affa 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -76,6 +76,8 @@ source "drivers/hwmon/Kconfig" source "drivers/thermal/Kconfig" +source "drivers/mux/Kconfig" + source "drivers/watchdog/Kconfig" source "drivers/ssb/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index 060026a02f59..d089baa57965 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -112,6 +112,7 @@ obj-$(CONFIG_W1)+= w1/ obj-y += power/ obj-$(CONFIG_HWMON)+= hwmon/ obj-$(CONFIG_THERMAL) += thermal/ +obj-$(CONFIG_MULTIPLEXER) += mux/ obj-$(CONFIG_WATCHDOG) += watchdog/ obj-$(CONFIG_MD) += md/ obj-$(CONFIG_BT) += bluetooth/ diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig new file mode 100644 index ..de5a35ffe7af --- /dev/null +++ b/drivers/mux/Kconfig @@ -0,0 +1,33 @@ +# +# Multiplexer devices +# + +menuconfig MULTIPLEXER + bool "Multiplexer subsystem" + help + Multiplexer controller subsystem. Multiplexers are used in a + variety of settings, and this subsystem abstracts their use + so that the rest of the kernel sees a common interface. When + multiple parallel multiplexers are controlled by one single + multiplexer controller, this subsystem also coordinates the + multiplexer accesses. + + If unsure, say no. + +if MULTIPLEXER + +config MUX_GPIO + tristate "GPIO-controlled Multiplexer" + depends on OF && GPIOLIB + help + GPIO-controlled Multiplexer controller. + + The driver builds a single multiplexer controller using a number + of gpio pins. For N pins, there will be 2^N possible multiplexer + states. The GPIO pins can be connected (by the hardware) to several + multiplexers, which in that case will be operated in parallel. + + To compile this driver as a module, choose M here: the module will + be called mux-gpio. + +endif diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile new file mode 100644 index ..facc43da3648 --- /dev/null +++ b/drivers/mux/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for multiplexer devices. +# + +obj-$(CONFIG_MULTIPLEXER) += mux-core.o +obj-$(CONFIG_MUX_GPIO) += mux-gpio.o diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c new file mode 100644 index ..21da15a264ad --- /dev/null +++ b/drivers/mux/mux-core.c @@ -0
[PATCH v7 08/12] iio: multiplexer: new iio category and iio-mux driver
When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
to create one virtual iio channel for each multiplexer state.
Depends on the generic multiplexer subsystem.
Cache any ext_info values from the parent iio channel, creating a private
copy of the ext_info attributes for each multiplexer state/channel.
Reviewed-by: Jonathan Cameron
Signed-off-by: Peter Rosin
---
MAINTAINERS | 1 +
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/multiplexer/Kconfig | 18 ++
drivers/iio/multiplexer/Makefile | 6 +
drivers/iio/multiplexer/iio-mux.c | 456 ++
6 files changed, 483 insertions(+)
create mode 100644 drivers/iio/multiplexer/Kconfig
create mode 100644 drivers/iio/multiplexer/Makefile
create mode 100644 drivers/iio/multiplexer/iio-mux.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 91775f2be209..ff28ae01ebd1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6279,6 +6279,7 @@ M:Peter Rosin
L: linux-...@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
+F: drivers/iio/multiplexer/iio-mux.c
IIO SUBSYSTEM AND DRIVERS
M: Jonathan Cameron
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index a918270d6f54..b3c8c6ef0dff 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -83,6 +83,7 @@ source "drivers/iio/humidity/Kconfig"
source "drivers/iio/imu/Kconfig"
source "drivers/iio/light/Kconfig"
source "drivers/iio/magnetometer/Kconfig"
+source "drivers/iio/multiplexer/Kconfig"
source "drivers/iio/orientation/Kconfig"
if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 33fa4026f92c..93c769cd99bf 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -28,6 +28,7 @@ obj-y += humidity/
obj-y += imu/
obj-y += light/
obj-y += magnetometer/
+obj-y += multiplexer/
obj-y += orientation/
obj-y += potentiometer/
obj-y += potentiostat/
diff --git a/drivers/iio/multiplexer/Kconfig b/drivers/iio/multiplexer/Kconfig
new file mode 100644
index ..70a044510686
--- /dev/null
+++ b/drivers/iio/multiplexer/Kconfig
@@ -0,0 +1,18 @@
+#
+# Multiplexer drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Multiplexers"
+
+config IIO_MUX
+ tristate "IIO multiplexer driver"
+ select MULTIPLEXER
+ depends on OF
+ help
+ Say yes here to build support for the IIO multiplexer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-mux.
+
+endmenu
diff --git a/drivers/iio/multiplexer/Makefile b/drivers/iio/multiplexer/Makefile
new file mode 100644
index ..68be3c4abd07
--- /dev/null
+++ b/drivers/iio/multiplexer/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for industrial I/O multiplexer drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_MUX) += iio-mux.o
diff --git a/drivers/iio/multiplexer/iio-mux.c
b/drivers/iio/multiplexer/iio-mux.c
new file mode 100644
index ..60054be8962a
--- /dev/null
+++ b/drivers/iio/multiplexer/iio-mux.c
@@ -0,0 +1,456 @@
+/*
+ * IIO multiplexer driver
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct mux_ext_info_cache {
+ char *data;
+ size_t size;
+};
+
+struct mux_child {
+ struct mux_ext_info_cache *ext_info_cache;
+};
+
+struct mux {
+ int cached_state;
+ struct mux_control *control;
+ struct iio_channel *parent;
+ struct iio_dev *indio_dev;
+ struct iio_chan_spec *chan;
+ struct iio_chan_spec_ext_info *ext_info;
+ struct mux_child *child;
+};
+
+static int iio_mux_select(struct mux *mux, int idx)
+{
+ struct mux_child *child = &mux->child[idx];
+ struct iio_chan_spec const *chan = &mux->chan[idx];
+ int ret;
+ int i;
+
+ ret = mux_control_select(mux->control, chan->channel);
+ if (ret < 0) {
+ mux->cached_state = -1;
+ return ret;
+ }
+
+ if (mux->cached_state == chan->channel)
+ return 0;
+
+ if (chan->ext_info) {
+ for (i = 0; chan->ext_info[i].name; ++i) {
+ const char *attr = chan->ext_info[i].name;
+ struct mux_ext_info_cache *cache;
+
+ cache = &child->ext_info_cache[i];
+
+ if (cache->size < 0)
+ continue;
+
+ ret = iio_write_channel_ext_
[PATCH v7 04/12] dt-bindings: simplified bindings for single-user gpio mux
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/mux/mux-controller.txt | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/mux/mux-controller.txt
b/Documentation/devicetree/bindings/mux/mux-controller.txt
index 42b2177e5ae1..4e89df8b2392 100644
--- a/Documentation/devicetree/bindings/mux/mux-controller.txt
+++ b/Documentation/devicetree/bindings/mux/mux-controller.txt
@@ -125,3 +125,29 @@ An example mux controller might look like this:
reg = <0x50>;
#mux-control-cells = <1>;
};
+
+
+Combinded controller and consumer of a GPIO mux
+---
+
+For the common case of a single consumer of a GPIO controlled mux, there is
+a simplified binding which will instantiate an implicit mux controller. Just
+specify a mux-gpios property with the same interpretation as in mux-gpio.txt.
+Note that other properties described in mux-gpio.txt are not available in
+this simplified form and that the mux controller is unnamed. If you need
+more than one mux controller, a shared mux controller or if you need a
+specific idle-state, use the more flexible binding with the mux controller
+in its own node.
+
+Example:
+
+ adc-mux {
+ compatible = "io-channel-mux";
+ io-channels = <&adc 0>;
+ io-channel-names = "parent";
+
+ mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
+ <&pioA 1 GPIO_ACTIVE_HIGH>;
+
+ channels = "sync-1", "in", "out", "sync-2";
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: Update CPU hotplug and move it to core-api
On Wed, 04 Jan 2017, Sebastian Andrzej Siewior wrote: > On 2016-12-23 10:03:09 [+0200], Jani Nikula wrote: >> > --- /dev/null >> > +++ b/Documentation/core-api/cpu_hotplug.rst >> > @@ -0,0 +1,372 @@ >> > += >> > +CPU hotplug in the Kernel >> > += >> > + >> > +:Date: December, 2016 >> > +:Author: Sebastian Andrzej Siewior , >> > + Rusty Russell , >> > + Srivatsa Vaddagiri , >> > + Ashok Raj , >> > + Joel Schopp >> >> Just a drive-by comment, does that do what you want? You might want to >> see if adding one :Author: line per author produces better results. > > I see an Author: line for each author, I like better the way it is. > >> That said, I think git will do a better job of maintaining both the date >> and the authorship. > > If you see the generated html output in your browser you don't have git > around to check the date or the Author. The date should help you to keep > track of the latest version. As for the Author, git would only show me > as the author but I did not write everything myself. Some parts are > still from old documentation. Just to be clear, I don't really care about this file specifically one way or the other. Do as you wish, and please don't let my comments block you. --- In general, I don't think maintaining either the date or the authors manually is a good idea. This applies for both documentation and source code. The obvious downside is that updating them will be overlooked and forgotten. Arguably not having them at all is better than having incorrect or stale information (when the accurate information can be retrieved from git). Perhaps we could add more automatically updated metadata to the generated documentation. We could even add the date from git if we really wanted to. But do we? The generated documentation already includes the kernel version, is that not enough? Even when people do remember to update the fields, they're faced with a dilemma: Do their changes warrant an update in date or adding themselves as author? Are the changes significant enough? This is completely subjective. What if there have been bigger changes by others without updates to authors? Should you remove authors when their contributions have been long since been removed or rewritten, and forgotten, and don't have any relevance to the current text? I think listing authors in files, whether they're text or source code, in collaborative projects, is counter-productive. The best possible end result, not the promotion of individuals, should be the shared goal. No contributor should feel that their contribution promotes the people in authors rather than improves the end result. No contributor should shy away from updating a file because it seems to be "owned" by someone. Of course, credit to whom credit is due, but in an objective and fair manner. I argue that git log and blame are objective, and the history is all there for anyone that cares to look. It's not without flaws, as you point out, but I think it's superior to maintaining authors manually. (Copyright notices may need to be updated in the files, but they could be in reStructuredText comments, not unlike in source code.) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
On Thu, Dec 29, 2016 at 05:43:32PM -0500, Christopher Covington wrote: > From: Shanker Donthineni > > On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may > allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being > updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields > separately using a reserved ASID will ensure that there are no TLB entries > with incorrect ASID after changing the the ASID. When we restore guest state in KVM, we completely save and restore TTBRx_EL1 from EL2. Would that be affected by this erratum? Thanks, -Christoffer -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drm: Document drm_cache interface
On Wed, Jan 04, 2017 at 09:39:48AM +, Chris Wilson wrote: > On Wed, Jan 04, 2017 at 10:01:37AM +0100, Daniel Vetter wrote: > > On Mon, Jan 02, 2017 at 03:17:05PM -0200, Gabriel Krisman Bertazi wrote: > > > Signed-off-by: Gabriel Krisman Bertazi > > > --- > > > drivers/gpu/drm/drm_cache.c | 23 +++ > > > > When adding docs, please also add a kernel-doc stanza (good place would be > > a new chapter in Documentation/gpu/drm-mm.rst I think) to pull it all in. > > Otherwise it's not built, which means not checked by 0day, which means > > will get out of data. Also, you can't find it when browsing the html docs > > ;-) > > How close are we to having the spine of the kernelbook described in > Documentation/ and the indiviual chapter.rst next to the source in > drivers/gpu/drm/ etc? Something like: > Documentation/gpu/drm.rst: include drivers/gpu/drm/*.rst ? Hm, not sure we ever discussed this ... Adding linux-doc. But pre-coffee, sounds like an intriguing idea at least. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: Update CPU hotplug and move it to core-api
On 2016-12-23 10:03:09 [+0200], Jani Nikula wrote: > > --- /dev/null > > +++ b/Documentation/core-api/cpu_hotplug.rst > > @@ -0,0 +1,372 @@ > > += > > +CPU hotplug in the Kernel > > += > > + > > +:Date: December, 2016 > > +:Author: Sebastian Andrzej Siewior , > > + Rusty Russell , > > + Srivatsa Vaddagiri , > > + Ashok Raj , > > + Joel Schopp > > Just a drive-by comment, does that do what you want? You might want to > see if adding one :Author: line per author produces better results. I see an Author: line for each author, I like better the way it is. > That said, I think git will do a better job of maintaining both the date > and the authorship. If you see the generated html output in your browser you don't have git around to check the date or the Author. The date should help you to keep track of the latest version. As for the Author, git would only show me as the author but I did not write everything myself. Some parts are still from old documentation. > BR, > Jani. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
