[PATCH] mtd: denali: fix property name for Denali DT binding

[Masahiro Yamada]

Hi Rob,


2016-02-09 6:37 GMT+09:00 Rob Herring <robh at kernel.org>:
> On Mon, Feb 08, 2016 at 05:41:33PM +0900, Masahiro Yamada wrote:
>> Hi Arnd,
>>
>>
>> 2016-02-08 17:29 GMT+09:00 Arnd Bergmann <arnd at arndb.de>:
>> > On Monday 08 February 2016 16:31:42 Masahiro Yamada wrote:
>> >> diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> >> index b04d03a..785b825 100644
>> >> --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> >> +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> >> @@ -5,7 +5,7 @@ Required properties:
>> >>    - reg : should contain registers location and length for data and reg.
>> >>    - reg-names: Should contain the reg names "nand_data" and "denali_reg"
>> >>    - interrupts : The interrupt number.
>> >> -  - dm-mask : DMA bit mask
>> >> +  - dma-mask : DMA bit mask
>> >>
>> >>  The device tree may optionally contain sub-nodes describing partitions of the
>> >>  address space. See partition.txt for more detail.
>> >>
>> >
>> > It looks like this binding is wrong in multiple ways, and it doesn't seem to
>> > be used in any .dts files. Is this actually being shipped anywhere or
>> > could we try to fix the binding properly?
>> >
>>
>> Looks like it is locally used in Altera's Rocketboard tree now.
>>
>> See this:
>>
>> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-4.3/arch/arm/boot/dts/socfpga.dtsi
>>
>>
>> I hope Dinh can comment on the status.
>
> From the looks of it, this property should be dropped and the driver
> should be updated to not touch dev->dma_mask. The core sets it up
> correctly now.


I am still a newbie as for DMA.
Could you help me to understand what we should do and/or what we should not do
for the DMA mask.


Documentation/DMA-API-HOWTO.txt says as follows:

-------------------->8-----------------------
For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has.  It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
--------------------<8----------------------


>From your statement, low-level drivers should no longer touch dma-mask
(i.e., the quoted paragraph above no longer applies to the latest
driver implementation),
is this correct?



-- 
Best Regards
Masahiro Yamada