On Fri, Aug 4, 2017 at 2:49 AM, Michal Simek <michal.simek@xxxxxxxxxx> wrote:
> On 4.8.2017 00:32, Rob Herring wrote:
>> On Fri, Jul 28, 2017 at 03:17:26PM +0200, Michal Simek wrote:
>>> From: Nava kishore Manne <nava.manne@xxxxxxxxxx>
>>>
>>> This patch fixes the below warning
>>> --> Use #include <linux/io.h> instead of <asm/io.h>
>>> --> Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
>>> --> please, no space before tabs
>>> --> Block comments use a trailing */ on a separate line
>>> --> Possible unnecessary 'out of memory' message
>>> --> Block comments use * on subsequent lines
>>> --> Block comments use a trailing */ on a separate line
>>> --> braces {} are not necessary for any arm of this statement
>>> --> DT compatible string "xlnx,opb-hwicap-1.00.b"
>>> appears un-documented
>>> --> DT compatible string "xlnx,xps-hwicap-1.00.a"
>>> appears un-documented
>>>
>>> Signed-off-by: Nava kishore Manne <navam@xxxxxxxxxx>
>>> Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx>
>>> ---
>>>
>>> Documentation/devicetree/bindings/xilinx.txt | 2 ++
>>
>> It's preferred to split bindings to separate patches. No need unless you
>> respin:
>>
>> Acked-by: Rob Herring <robh@xxxxxxxxxx>
>
> thanks. Was there any outcome from that discussion to extract binding
> out of kernel source code?
Well, the reason to split the patches is so the history of the
filtered DT repository we generate from the kernel tree[1] looks
saner.
As far as actually moving things out, no there's not been any
movement. My biggest concern with moving things out would be the loss
of kernel subsystem maintainers' review. Once it's a separate tree and
not merged thru their tree, we'd loose their reviews and I don't have
confidence that we'd be gaining reviews from other places. Though some
subsystem maintainers merge bindings and don't look at them already.
Rob
[1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
