On Mon, 14 Oct 2024 16:04:35 +0200 Angelo Dureghello <adureghello@xxxxxxxxxxxx> wrote: > Hi Rob, > > On 14.10.2024 08:38, Rob Herring wrote: > > On Mon, Oct 14, 2024 at 06:21:02AM -0500, Rob Herring (Arm) wrote: > > > > > > On Mon, 14 Oct 2024 12:08:08 +0200, Angelo Dureghello wrote: > > > > From: Angelo Dureghello <adureghello@xxxxxxxxxxxx> > > > > > > > > Add a new compatible and related bindigns for the fpga-based > > > > "ad3552r" AXI IP core, a variant of the generic AXI DAC IP. > > > > > > > > The AXI "ad3552r" IP is a very similar HDL (fpga) variant of the > > > > generic AXI "DAC" IP, intended to control ad3552r and similar chips, > > > > mainly to reach high speed transfer rates using a QSPI DDR > > > > (dobule-data-rate) interface. > > > > > > > > The ad3552r device is defined as a child of the AXI DAC, that in > > > > this case is acting as an SPI controller. > > > > > > > > Note, #io-backend is present because it is possible (in theory anyway) > > > > to use a separate controller for the control path than that used > > > > for the datapath. > > > > > > > > Signed-off-by: Angelo Dureghello <adureghello@xxxxxxxxxxxx> > > > > --- > > > > .../devicetree/bindings/iio/dac/adi,axi-dac.yaml | 56 ++++++++++++++++++++-- > > > > 1 file changed, 53 insertions(+), 3 deletions(-) > > > > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > > > yamllint warnings/errors: > > > > > > dtschema/dtc warnings/errors: > > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.example.dtb: dac@0: spi-max-frequency: 66000000 is greater than the maximum of 30000000 > > > from schema $id: http://devicetree.org/schemas/iio/dac/adi,ad3552r.yaml# > > > > This is at least the third time this issue has been reported. Don't send > > more versions until you fix it. > > > > as stated in the patch message, this patch applies to linux-iio testing, > where there are no errors, from my tests. > > Error is due to the spi-max-frequency fix already applied in iio testing, > but still not where your bot is testing, proably in mainline. Whilst it's a fix, given the fix broadens the accepted range and doesn't matter until this patch (which will behind it) I currently have no intention of sending that fix until next merge window. Cynic in me says just change the example to a value under the old limit and bot will be happy. Example is just that, so doesn't have to reflect the maximum possible or even what people commonly run. Or include that patch again in this series with a note to say it's just here to ensure the base is correct for the bots. Jonathan > > Regards, > angelo > > > Rob
