On Fri, Dec 02, 2016 at 11:05:13PM +0800, Icenowy Zheng wrote:
> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
> SDIO Wi-Fi chip by Allwinner (XR819).
>
> Add a device tree file for it.
>
> Signed-off-by: Icenowy Zheng
Applied, thanks!
Maxime
--
Maxime Ripard, Free
On 12/7/2016 7:19 AM, Matt Fleming wrote:
> On Wed, 09 Nov, at 06:36:31PM, Tom Lendacky wrote:
>> Boot data (such as EFI related data) is not encrypted when the system is
>> booted and needs to be accessed unencrypted. Add support to apply the
>> proper attributes to the EFI page tables and to the
On Fri, 9 Dec 2016 14:37:47 +0800
Cao jin wrote:
> I am little confused too, even not sure if we are talking the same
> *fatal error*, I am talking the fatal error defined in PCI Express spec,
> chapter 6.2.2.2.1:
Therein lies my original discomfort with the change; it didn't seem to
make sense
On Fri, 9 Dec 2016 14:44:25 +0800
Linas Vepstas wrote:
> On Fri, Dec 9, 2016 at 2:37 PM, Cao jin wrote:
> >
> >
> > On 12/09/2016 02:24 PM, Linas Vepstas wrote:
> >> I suppose I'm confused, but I recall that link resets are non-fatal.
> >> Fatal errors typically require that the the pci adapte
On Thu, 8 Dec 2016, Luis R. Rodriguez wrote:
> While looking for early possible module loading failures I was
> able to reproduce a memory leak possible with kmemleak. There
> are a few rare ways to trigger a failure:
>
> o we've run into a failure while processing kernel parameters
> (pars
- Put all the remaing bits of the old doc into suitable places in the
new sphinx world.
- Also document the poll support, we forgot to do that.
- Delete dma-buf-sharing.txt.
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet
Cc: Sumit Semwal
Signed-off-by: Daniel Vetter
---
Documentation/dma-
- Put the initial overview for dma-buf into dma-buf.rst.
- Put all the comments about detailed semantics into the right
kernel-doc comment for functions or ops structure member.
- To allow that detail, switch the reworked kerneldoc to inline style
for dma_buf_ops.
- Tie everything together into
- Again move the information relevant for driver writers next to the
callbacks.
- Put the overview and userspace interface documentation into a DOC:
section within the code.
- Remove the text that mmap needs to be coherent - since the
DMA_BUF_IOCTL_SYNC landed that's no longer the case. But k
This was missed when adding a dma_fence_get call. While at it also
remove the kerneldoc for the static inline helper - no point
documenting internals down to every detail.
Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating
sync_file")
Cc: Gustavo Padovan
Cc: Sean Paul
Just prep work to polish and consolidate all the dma-buf related
documenation.
Unfortunately I didn't discover a way to both integrate this new file
into the overall toc while keeping it at the current place. Work
around that by moving it into the overall driver-api/index.rst.
Cc: linux-doc@vger.
On Thu, 2016-12-08 at 11:49 -0800, Luis R. Rodriguez wrote:
>
> Although this does get us in the business of keeping alias maps in
> kernel, the the work to support and maintain this is trivial.
You've implemented a special treatment for request_module("fs-$X")in
finished_kmod_load(), but there a
On Fri, Dec 9, 2016 at 12:03 PM, Martin Wilck wrote:
> On Thu, 2016-12-08 at 11:49 -0800, Luis R. Rodriguez wrote:
>>
>> Although this does get us in the business of keeping alias maps in
>> kernel, the the work to support and maintain this is trivial.
>
> You've implemented a special treatment fo
On Fri, 9 Dec 2016 19:53:04 +0100
Daniel Vetter wrote:
> Not yet everything in this area, I still want to sprinkle nice docs around all
> the fence code. Especially some text to explain implicit vs. explicit fencing
> and how it's all supposed to work.
>
> But just cleanup in the dma-buf part w
- Put all the remaing bits of the old doc into suitable places in the
new sphinx world.
- Also document the poll support, we forgot to do that.
- Delete dma-buf-sharing.txt.
v2: Don't forget to update MAINTAINERS.
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet
Cc: Sumit Semwal
Signed-off-b
When trying to configure crashkernel greater than about 800 MB, the
kernel fails to allocate memory on x86 and x86_64. This is due to an
undocumented limit that the crashkernel and other low memory items must
be allocated below 896 MB unless the ",high" option is given. This
updates the documentati
On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
> When trying to configure crashkernel greater than about 800 MB, the
> kernel fails to allocate memory on x86 and x86_64. This is due to an
> undocumented limit that the crashkernel and other low memory items must
> be allocated below 896 MB unless the
On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote:
> On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
>> When trying to configure crashkernel greater than about 800 MB, the
>> kernel fails to allocate memory on x86 and x86_64. This is due to an
>> undocumented limit that the crashkernel and other low
17 matches
Mail list logo
