Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
On Mon, Dec 05, 2016 at 07:01:46PM +0800, Icenowy Zheng wrote:
>
>
> 05.12.2016, 17:40, "Maxime Ripard" :
> > On Mon, Dec 05, 2016 at 04:59:44PM +0800, Icenowy Zheng wrote:
> >> 2016年12月5日 16:52于 Maxime Ripard 写道：
> >> >
> >> > On Fri, Dec 02, 2016 at 10:22:30PM +0800, Icenowy Zheng wrote:
> >> > >
> >> > >
> >> > > 01.12.2016, 17:36, "Maxime Ripard" :
> >> > > > On Mon, Nov 28, 2016 at 12:29:07AM +, André Przywara wrote:
> >> > > >> > Something more interesting happened.
> >> > > >> >
> >> > > >> > Xunlong made a add-on board for Orange Pi Zero, which exposes
> >> the
> >> > > >> > two USB Controllers exported at expansion bus as USB Type-A
> >> > > >> > connectors.
> >> > > >> >
> >> > > >> > Also it exposes a analog A/V jack and a microphone.
> >> > > >> >
> >> > > >> > Should I enable {e,o}hci{2.3} in the device tree?
> >> > > >>
> >> > > >> Actually we should do this regardless of this extension board.
> >> The USB
> >> > > >> pins are not multiplexed and are exposed on user accessible pins
> >> (just
> >> > > >> not soldered, but that's a detail), so I think they qualify for DT
> >> > > >> enablement. And even if a user can't use them, it doesn't hurt to
> >> have
> >> > > >> them (since they are not multiplexed).
> >> > > >
> >> > > > My main concern about this is that we'll leave regulators enabled by
> >> > > > default, for a minority of users. And that minority will prevent to
> >> do
> >> > > > a proper power management when the times come since we'll have to
> >> keep
> >> > > > that behaviour forever.
> >> > >
> >> > > I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
> >> >
> >> > You can't ask that from the majority of users. These users will take
> >> > debian or fedora, install it, and expect everything to work
> >> > properly. I would make the opposite argument actually. If someone is
> >> > knowledgeable enough to solder the USB pins a connector, then (s)he'll
> >> > be able to make that u-boot call.
> >>
> >> Now (s)he do not need soldering.
> >>
> >> (S)he needs only paying $1.99 more to Xunlong to get the expansion
> >> board, and insert it on the OPi Zero.
> >
> > Which is going to require an overlay anyway, so we could have the USB
> > bits in there too.
>
> If so, I think the [PATCH -next v3 2/2] is ready to be merged ;-)
I meant enabling the USB in the overlay, you enabled it in the base DT.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: ILP32 for ARM64: testing with glibc testsuite
On Mon, Dec 05, 2016 at 06:24:11PM +0800, Zhangjian (Bamvor) wrote: > > > On 2016/12/5 18:07, Andreas Schwab wrote: > >On Dez 05 2016, "Zhangjian (Bamvor)" wrote: > > > >>Is there some progresses on it? We could collabrate to fix those issues. > > > >All the elf/nptl/rt fails should be fixed by the recent binutils fixes. > Cool. How about the conform and other failures? I think conform is only my local problem. I use pretty non-standard environment for build and testing - cross-compilation + qemu. Steve builds and runs tests natively, and he doesn't see that regressions. Yury -- 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: ILP32 for ARM64: testing with glibc testsuite
On Dez 05 2016, Steve Ellcey wrote: > FAIL: nptl/tst-cancel26 > FAIL: nptl/tst-cancel27 > FAIL: rt/tst-mqueue1 > FAIL: rt/tst-mqueue2 > FAIL: rt/tst-mqueue4 > FAIL: rt/tst-mqueue7 I don't see these failures. Maybe you need to rebuild libgcc? https://build.opensuse.org/package/live_build_log/devel:ARM:AArch64:ILP32/glibc-testsuite/standard/aarch64_ilp32 Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- 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 14/18] arm64: signal32: move ilp32 and aarch32 common code to separated file
On Mon, Dec 05, 2016 at 04:18:24PM +, Catalin Marinas wrote: > On Fri, Oct 21, 2016 at 11:33:13PM +0300, Yury Norov wrote: > > Signed-off-by: Yury Norov > > Please add some description, even if it means copying the subject. > > > --- > > arch/arm64/include/asm/signal32.h| 3 + > > arch/arm64/include/asm/signal32_common.h | 27 +++ > > arch/arm64/kernel/Makefile | 2 +- > > arch/arm64/kernel/signal32.c | 107 > > arch/arm64/kernel/signal32_common.c | 135 > > +++ > > 5 files changed, 166 insertions(+), 108 deletions(-) > > create mode 100644 arch/arm64/include/asm/signal32_common.h > > create mode 100644 arch/arm64/kernel/signal32_common.c > > I wonder whether you can make such patches more readable by setting > "diff.renames" to "copy" in your gitconfig (unless it's set already and > Git cannot detect partial file code moving/copying). I tried "git format-patch -C --find-copies-harder" - the same result. Yury -- 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 5/5] docs: 00-INDEX: document directories/files with no docs
Em Mon, 5 Dec 2016 14:25:40 -0700 Jonathan Corbet escreveu: > On Mon, 5 Dec 2016 09:41:45 -0200 > Mauro Carvalho Chehab wrote: > > > There are a number of files/directories that don't contain > > any documentation. They're related to ReST file conversion. > > > > As a matter of completeness, since Makefile is also documented > > there, add an entry for those files too. > > As promised, a couple of quibbles... > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > Documentation/00-INDEX | 19 +++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX > > index 272f5c4481f1..6d488509285d 100644 > > --- a/Documentation/00-INDEX > > +++ b/Documentation/00-INDEX > > @@ -14,6 +14,8 @@ Following translations are available on the WWW: > > - this file. > > ABI/ > > - info on kernel <-> userspace ABI and relative interface stability. > > +CodingStyle > > + - nothing here, just a pointer to process/coding-style.rst. > > DMA-API.txt > > - DMA API, pci_ API & extensions for non-consistent memory machines. > > DMA-API-HOWTO.txt > > @@ -39,6 +41,9 @@ Intel-IOMMU.txt > > Makefile > > - This file does nothing. Removing it breaks make htmldocs and > > make distclean. > > +Makefile.sphinx > > + - This file does nothing. Removing it breaks make htmldocs and > > + make distclean. > > To say that this file "does nothing" is clearly incorrect - it controls how > the sphinx build is done. Basically, I repeated the same text as the one for Makefile. I'll send a patch changing both texts ;) > > > PCI/ > > - info related to PCI drivers. > > RCU/ > > @@ -47,6 +52,8 @@ SAK.txt > > - info on Secure Attention Keys. > > SM501.txt > > - Silicon Motion SM501 multimedia companion chip > > +SubmittingPatches > > + - nothing here, just a pointer to process/coding-style.rst. > > accounting/ > > - documentation on accounting and taskstats. > > acpi/ > > @@ -93,6 +100,8 @@ clk.txt > > - info on the common clock framework > > cma/ > > - Continuous Memory Area (CMA) debugfs interface. > > +conf.py > > + - nothing here. Just a configuration file for Sphinx. > > Again, it's not "nothing"; we could say it's not of interest to people who > aren't doing things with the build system. Ok. > > > connector/ > > - docs on the netlink based userspace<->kernel space communication mod. > > console/ > > @@ -135,6 +144,8 @@ digsig.txt > > -info on the Digital Signature Verification API > > dma-buf-sharing.txt > > - the DMA Buffer Sharing API Guide > > +docutils.conf > > + - nothing here. Just a configuration file for docutils. > > dontdiff > > - file containing a list of files that should never be diff'ed. > > driver-api/ > > @@ -201,6 +212,8 @@ ide/ > > - Information regarding the Enhanced IDE drive. > > iio/ > > - info on industrial IIO configfs support. > > +index.rst > > + - main index for the documentation at ReST format. > > infiniband/ > > - directory with documents concerning Linux InfiniBand support. > > input/ > > @@ -307,6 +320,8 @@ nvdimm/ > > - info on non-volatile devices. > > nvmem/ > > - info on non volatile memory framework. > > +output/ > > + - default directory where html/LaTeX/pdf files will be written. > > padata.txt > > - An introduction to the "padata" parallel execution API > > parisc/ > > @@ -387,6 +402,10 @@ sound/ > > - directory with info on sound card support. > > spi/ > > - overview of Linux kernel Serial Peripheral Interface (SPI) support. > > +sphinx/ > > + - no doumentation here, just files required by Sphinx toolchain. > > Indeed there's no "doumentation" there :) No documentation either. Heh ;) I'll fix the typo. > > > +sphinx-static/ > > + - no doumentation here, just files required by Sphinx toolchain. > > static-keys.txt > > - info on how static keys allow debug code in hotpaths via patching > > svga.txt > > Thanks, > > jon Thanks, Mauro -- 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] Update Documentation/00-INDEX
Em Mon, 5 Dec 2016 14:23:01 -0700 Jonathan Corbet escreveu: > On Mon, 5 Dec 2016 09:41:40 -0200 > Mauro Carvalho Chehab wrote: > > > So, in order to check it, I wrote a small script that compares the files > > and directories at Documentation/ with the ones at 00-INDEX. > > > > Then, I synchronized the entries, making the script happy. > > > > We might think on integrating the script with checkpatch.pl, but, as > > we should get rid of 00-INDEX, it probably not worth the efforts. > > I would agree with that; I don't see the point of keeping those files > around in the longer term. > > I've applied the set. I do have a few quibbles with the final patch that > I'll send separately, but they're not something to hold this set up for. Jon, Did a patch fixing the quibbles. As it seems you didn't push yet the changeset upstream, feel free to just fold it with patch 5/5 if you prefer so, or to add as a separate patch at the end of the series. Patch enclosed. Thanks, Mauro [PATCH] docs: 00-INDEX: change text related to the building system Let be clearer on those files related to the build system. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 6d488509285d..5bd4b07c2f90 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -39,11 +39,9 @@ IRQ.txt Intel-IOMMU.txt - basic info on the Intel IOMMU virtualization support. Makefile - - This file does nothing. Removing it breaks make htmldocs and - make distclean. + - It's not of interest for those who aren't touching the build system. Makefile.sphinx - - This file does nothing. Removing it breaks make htmldocs and - make distclean. + - It's not of interest for those who aren't touching the build system. PCI/ - info related to PCI drivers. RCU/ @@ -101,7 +99,7 @@ clk.txt cma/ - Continuous Memory Area (CMA) debugfs interface. conf.py - - nothing here. Just a configuration file for Sphinx. + - It's not of interest for those who aren't touching the build system. connector/ - docs on the netlink based userspace<->kernel space communication mod. console/ @@ -403,9 +401,9 @@ sound/ spi/ - overview of Linux kernel Serial Peripheral Interface (SPI) support. sphinx/ - - no doumentation here, just files required by Sphinx toolchain. + - no documentation here, just files required by Sphinx toolchain. sphinx-static/ - - no doumentation here, just files required by Sphinx toolchain. + - no documentation here, just files required by Sphinx toolchain. static-keys.txt - info on how static keys allow debug code in hotpaths via patching svga.txt -- 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
[lwn:docs-next 78/85] htmldocs: include/linux/device.h:1: warning: no structured comments found
tree: git://git.lwn.net/linux-2.6 docs-next head: 9e22ff439fa2e1201b168c001683f275afd46258 commit: aad800403a8761073511abb93075738302983956 [78/85] Documentation/core-api/device_link: Add initial documentation reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. include/linux/init.h:1: warning: no structured comments found include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found >> include/linux/device.h:1: warning: no structured comments found >> drivers/base/core.c:1: warning: no structured comments found Error: Cannot open file drivers/dma-buf/dma-fence.c Error: Cannot open file drivers/dma-buf/dma-fence.c WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -export drivers/dma-buf/dma-fence.c' failed with return code 2 Error: Cannot open file include/linux/dma-fence.h Error: Cannot open file include/linux/dma-fence.h WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -internal include/linux/dma-fence.h' failed with return code 2 drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found Error: Cannot open file drivers/dma-buf/dma-fence-array.c Error: Cannot open file drivers/dma-buf/dma-fence-array.c WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -export drivers/dma-buf/dma-fence-array.c' failed with return code 2 Error: Cannot open file include/linux/dma-fence-array.h Error: Cannot open file include/linux/dma-fence-array.h WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -internal include/linux/dma-fence-array.h' failed with return code 2 include/uapi/linux/vtpm_proxy.h:1: warning: no structured comments found drivers/char/tpm/tpm_vtpm_proxy.c:71: warning: No description found for parameter 'filp' drivers/char/tpm/tpm_vtpm_proxy.c:71: warning: No description found for parameter 'buf' drivers/char/tpm/tpm_vtpm_proxy.c:71: warning: No description found for parameter 'count' drivers/char/tpm/tpm_vtpm_proxy.c:71: warning: No description found for parameter 'off' drivers/char/tpm/tpm_vtpm_proxy.c:121: warning: No description found for parameter 'filp' drivers/char/tpm/tpm_vtpm_proxy.c:121: warning: No description found for parameter 'buf' drivers/char/tpm/tpm_vtpm_proxy.c:121: warning: No description found for parameter 'count' drivers/char/tpm/tpm_vtpm_proxy.c:121: warning: No description found for parameter 'off' drivers/char/tpm/tpm_vtpm_proxy.c:201: warning: No description found for parameter 'proxy_dev' drivers/char/tpm/tpm_vtpm_proxy.c:1: warning: no structured comments found include/sound/compress_driver.h:162: warning: No description found for parameter 'id[64]' include/sound/compress_driver.h:162: warning: No description found for parameter 'proc_root' include/sound/compress_driver.h:162: warning: No description found for parameter 'proc_info_entry' Documentation/core-api/assoc_array.rst:13: WARNING: Enumerated list ends without a blank line; unexpected unindent. Documentation/doc-guide/sphinx.rst:110: ERROR: Unknown target name: "sphinx c domain". include/net/mac80211.h:3207: ERROR: Unexpected indentation. include/net/mac80211.h:3210: WARNING: Block quote ends without a blank line; unexpected unindent. include/net/mac80211.h:3212: ERROR: Unexpected indentation. include/net/mac80211.h:3213: WARNING: Block quote ends without a blank line; unexpected unindent. include/net/mac80211.h:1772: ERROR: Unexpected indentation. include/net/mac80211.h:1776: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/sched/fair.c:7259: WARNING: Inline emphasis start-string without end-string. kernel/time/timer.c:1240: ERROR: Unexpected indentation. kernel/time/timer.c:1242: ERROR: Unexpected indentation. kernel/time/timer.c:1243: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:121: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:124: ERROR: Unexpected indentation. include/linux/wait.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/time/hrtimer.c:1021: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/signal.c:317: WARNING: Inline literal start-string without end-string. drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. drivers/message/fusion/mptbase.c:5054: WARNING: Definition list ends without a blank line; unexpected unindent. drivers/tty/serial/serial_core.c:1893: WARNING: Definition list ends without a blank line; unexpected unindent. include/linux/spi/spi.h:369: ERROR: Unexpected indentation. drivers/usb/core/message.c:478: ERROR: Unexpected indentation. driv
Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings
On 2016-12-06 00:26, Rob Herring wrote:
> On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote:
>> Signed-off-by: Peter Rosin
>> ---
>> .../bindings/iio/multiplexer/iio-mux.txt | 40
>> ++
>> MAINTAINERS| 6
>> 2 files changed, 46 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>
> I'm still not convinced about this binding, but don't really have more
> comments ATM. Sending 6 versions in 2 weeks or so doesn't really help
> either.
Sorry about the noise, I'll try to be more careful going forward. On
the flip side, I haven't touched the code since v6.
I don't see how bindings that are as flexible as the current (and
original) phandle link between the mux consumer and the mux controller
would look, and at the same time be simpler to understand. You need
to be able to refer to a mux controller from several mux consumers, and
you need to support several mux controllers in one node (the ADG792A
case). And, AFAICT, the complex case wasn't really the problem, it was
that it is overly complex to describe the simple case of one mux
consumer and one mux controller. But in your comment for v2 [1] you
said that I was working around limitations with shared GPIO pins. But
solving that in the GPIO subsystem would not solve all that the
phandle approach is solving, since you would not have support for
ADG792A (or other non-GPIO controlled muxes). So, I think listing
the gpio pins inside the mux consumer node is a non-starter, the mux
controller has to live in its own node with its own compatible.
Would you be happier if I managed to marry the phandle approach with
the option of having the mux controller as a child node of the mux
consumer for the simple case?
I added an example at the end of this message (the same as the first
example in v4 [2], at least in principle) for easy comparison between
the phandle and the controller-in-child-node approaches. I can't say
that I personally find the difference all that significant, and do not
think it is worth it. As I see it, the "simple option" would just muddy
the waters...
[1] http://marc.info/?l=linux-kernel&m=147948334204795&w=2
[2] http://marc.info/?l=linux-kernel&m=148001364904240&w=2
>> diff --git a/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>> b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>> new file mode 100644
>> index ..8080cf790d82
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>> @@ -0,0 +1,40 @@
>> +IIO 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 : "iio-mux"
>
> This is a Linuxism. perhaps "adc-mux".
No, that's not general enough, it could just as well be used to mux a
temperature sensor. Or whatever. Hmmm, given that "iio-mux" is bad, perhaps
"io-channel-mux" is better? That matches the io-channels property used to
refer to the parent channel.
>> +- 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.
>> +
>> +The multiplexer state as described in ../misc/mux-controller.txt
>> +
>> +For each non-empty string in the channels property, an iio channel will
>> +be created. The number of this iio channel is the same as the index into
>> +the list of strings in the channels property, and also matches the mux
>> +controller state.
>> +
>> +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 = "iio-mux";
>> +io-channels = <&adc 0>;
>> +io-channel-names = "parent";
>> +
>> +mux-controls = <&mux>;
>> +
>> +channels = "sync", "in", system-regulator";
>> +};
Describing the same as above, but with the mux controller as a child
node.
adc-mux {
compatible = "iio-mux";
io-channels = <&adc 0>;
io-channel-names = "parent";
channels = "sync", "in", system-regulator";
mux-controller {
compatible = "mux-gpio";
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>;
};
};
Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.or
