Hi Kukjin, On 19 August 2013 00:10, Kukjin Kim <kgene.kim@xxxxxxxxxxx> wrote: > On 08/15/13 17:59, Tomasz Figa wrote: >> >> Hi Tushar, >> > [...] > > >>>> + status = "okay"; >>>> >>>> }; >>> >>> >>> Sometime back we had a discussion on this, the decision was to enable >>> it in respective boards. >> >> >> This is not entirely true. >> >> According to ePAPR, chapter 2.3.4, the status property has a well defined >> meaning and it should be set to "disabled" when "the device is not >> presently operational, but it might become operational in the future (for >> example, something is not plugged in, or switched off)". >> > So in my understanding, you mean using "okay" is wrong and only "disabled" > is used? and in board dt file? Already there are too many "okay"... > > >> This means that unless setup of the device is missing something (e.g. >> board-specific properties, like regulators or pin config) or there is a >> valid technical reason for disabling the device by default (e.g. it needs >> certain SoC pins to be properly connected to something), then such device >> should be "okay", because it is operational. >> >>> Also if we are going ahead with this, we would need to remove the >>> corresponding status statements from board files. >> >> >> Yes, this is true. >> > According to above, probably we should add "disabled" in board dt file? > what Tushar meant was, since we made the status as "okay" in exynos5250.dtsi itself, its better to remove the "okay" from the board DTS files of exynos5250 ( exynos5250-snow.dts and exynos5250-arndale.dts). Am I right Tushar? > If I'm wrong, correct me. > > (+ dt ml) > > Anyway, I'm not sure how to use 'okay' and 'disabled' for status... > > I think, every hardware information should be defined in SoC dt file and > maybe some of them could be set disabled or okay in each board dt file... > > Any suggestions? > > Thanks, > Kukjin -- Thanks and Regards Vikas Sajjan -- 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
