On Thu, 25 May 2017 11:03:20 +0300
Nikita Yushchenko wrote:
> >> "Crap origin" here is that in vast majority of cases, polarity is
> >> per-chip, not per-chip-use, knowledge. And proper location for per-chip
> >> knowledge is chip's driver. Moving this knowledge
On Thu, 25 May 2017 11:03:20 +0300
Nikita Yushchenko wrote:
> >> "Crap origin" here is that in vast majority of cases, polarity is
> >> per-chip, not per-chip-use, knowledge. And proper location for per-chip
> >> knowledge is chip's driver. Moving this knowledge to per-chip-use
> >> location in
On Thu, May 25, 2017 at 11:06:47AM +0300, Nikita Yushchenko wrote:
> >> + {
> >> + status = "okay";
> >> +};
> >> +
> >> + {
> >
> > Please keep these labelled nodes sort alphabetically.
>
> Ok
>
> >> + bus-num = <1>;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <_dspi2>;
> >> +
On Thu, May 25, 2017 at 11:06:47AM +0300, Nikita Yushchenko wrote:
> >> + {
> >> + status = "okay";
> >> +};
> >> +
> >> + {
> >
> > Please keep these labelled nodes sort alphabetically.
>
> Ok
>
> >> + bus-num = <1>;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <_dspi2>;
> >> +
>> + {
>> +status = "okay";
>> +};
>> +
>> + {
>
> Please keep these labelled nodes sort alphabetically.
Ok
>> +bus-num = <1>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_dspi2>;
>> +status = "okay";
>
> We usually have 'status' line at the bottom of property list.
Ok
>> + {
>> +status = "okay";
>> +};
>> +
>> + {
>
> Please keep these labelled nodes sort alphabetically.
Ok
>> +bus-num = <1>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_dspi2>;
>> +status = "okay";
>
> We usually have 'status' line at the bottom of property list.
Ok
>> "Crap origin" here is that in vast majority of cases, polarity is
>> per-chip, not per-chip-use, knowledge. And proper location for per-chip
>> knowledge is chip's driver. Moving this knowledge to per-chip-use
>> location in device trees only provides a source for errors, with little
>> gain.
>> "Crap origin" here is that in vast majority of cases, polarity is
>> per-chip, not per-chip-use, knowledge. And proper location for per-chip
>> knowledge is chip's driver. Moving this knowledge to per-chip-use
>> location in device trees only provides a source for errors, with little
>> gain.
On Tue, May 23, 2017 at 09:02:27AM +0300, Nikita Yushchenko wrote:
> >> However, hi8435 driver historically was coded using inverted values
> >> passed to gpiolib calls. And there are setups in the wild with device
> >> trees containing GPIO_ACTIVE_HIGH that I'd prefer not breaking.
> >>
> >> To
On Tue, May 23, 2017 at 09:02:27AM +0300, Nikita Yushchenko wrote:
> >> However, hi8435 driver historically was coded using inverted values
> >> passed to gpiolib calls. And there are setups in the wild with device
> >> trees containing GPIO_ACTIVE_HIGH that I'd prefer not breaking.
> >>
> >> To
On Mon, May 22, 2017 at 04:10:10PM +0300, Nikita Yushchenko wrote:
> ZII dev board rev B has a Holt Hi8435 connected to dspi2.
> Add it to device tree.
>
> ZII dev board rev C does not have that, so use rev-b dts file,
> not common dtsi file.
>
> Signed-off-by: Nikita Yushchenko
On Mon, May 22, 2017 at 04:10:10PM +0300, Nikita Yushchenko wrote:
> ZII dev board rev B has a Holt Hi8435 connected to dspi2.
> Add it to device tree.
>
> ZII dev board rev C does not have that, so use rev-b dts file,
> not common dtsi file.
>
> Signed-off-by: Nikita Yushchenko
> ---
>
>> However, hi8435 driver historically was coded using inverted values
>> passed to gpiolib calls. And there are setups in the wild with device
>> trees containing GPIO_ACTIVE_HIGH that I'd prefer not breaking.
>>
>> To solve, I submitted a patch on hi8435 driver that changes to _raw()
>> gpio
>> However, hi8435 driver historically was coded using inverted values
>> passed to gpiolib calls. And there are setups in the wild with device
>> trees containing GPIO_ACTIVE_HIGH that I'd prefer not breaking.
>>
>> To solve, I submitted a patch on hi8435 driver that changes to _raw()
>> gpio
On Mon, May 22, 2017 at 07:29:14PM +0300, Nikita Yushchenko wrote:
> >> + hi8435@1 {
> >> + compatible = "holt,hi8435";
> >> + reg = <1>;
> >> + spi-max-frequency = <2000>;
> >> + gpios = < 3 0>;
> >
> > Nit: GPIO_ACTIVE_HIGH instead of 0?
>
> Gray area
On Mon, May 22, 2017 at 07:29:14PM +0300, Nikita Yushchenko wrote:
> >> + hi8435@1 {
> >> + compatible = "holt,hi8435";
> >> + reg = <1>;
> >> + spi-max-frequency = <2000>;
> >> + gpios = < 3 0>;
> >
> > Nit: GPIO_ACTIVE_HIGH instead of 0?
>
> Gray area
>> +hi8435@1 {
>> +compatible = "holt,hi8435";
>> +reg = <1>;
>> +spi-max-frequency = <2000>;
>> +gpios = < 3 0>;
>
> Nit: GPIO_ACTIVE_HIGH instead of 0?
Gray area here.
Chip's reset input is active LOW.
However, hi8435 driver
>> +hi8435@1 {
>> +compatible = "holt,hi8435";
>> +reg = <1>;
>> +spi-max-frequency = <2000>;
>> +gpios = < 3 0>;
>
> Nit: GPIO_ACTIVE_HIGH instead of 0?
Gray area here.
Chip's reset input is active LOW.
However, hi8435 driver
On 2017-05-22 06:10, Nikita Yushchenko wrote:
> ZII dev board rev B has a Holt Hi8435 connected to dspi2.
> Add it to device tree.
>
> ZII dev board rev C does not have that, so use rev-b dts file,
> not common dtsi file.
>
> Signed-off-by: Nikita Yushchenko
>
On 2017-05-22 06:10, Nikita Yushchenko wrote:
> ZII dev board rev B has a Holt Hi8435 connected to dspi2.
> Add it to device tree.
>
> ZII dev board rev C does not have that, so use rev-b dts file,
> not common dtsi file.
>
> Signed-off-by: Nikita Yushchenko
> ---
>
20 matches
Mail list logo