On Fri, 16 Nov 2018 at 12:40, Simon Goldschmidt <simon.k.r.goldschm...@gmail.com> wrote: > > On 31.10.2018 07:42, Simon Goldschmidt wrote: > > On Wed, Oct 31, 2018 at 7:22 AM Jagan Teki <ja...@amarulasolutions.com> > > wrote: > >> On Wed, Oct 31, 2018 at 1:40 AM Simon Goldschmidt > >> <simon.k.r.goldschm...@gmail.com> wrote: > >>> When the device tree is missing a correct spi slave description below > >>> the bus (compatible "spi-flash" or spi-max-frequency are missing), > >>> the 'set_speed' callback can be called with 'speed' == 0 Hz. > >>> At least with cadence qspi, this leads to a division by zero. > >>> > >>> Prevent this by initializing speed to 100 kHz in this case (same > >>> fallback value as is done in 'dm_spi_claim_bus') and issue a warning > >>> to console. > >> Why can't driver plat->frequency in cadence driver initialize 100KH? > >> plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency", 100000) > > I'm not sure I understand. > > The cadence driver initializes its 'plat->max_hz' from > > "spi-max-frequency" property and defaults to 500 kHz. No problem > > there. > > > > However, the problem I want to solve is if someone puts a flash chip > > below there which has compatible != "spi-flash", they will get a hard > > fault which is hard to debug. This is because the node is not parsed > > because of the wrong compatible string (even if there is an > > "spi-max-frequency" property) and thus, "sf probe" tries to continue > > with 0 Hz. > > > > And this can happen easily when porting device trees from Linux as > > there, the boards have compatible "n25q00" etc. instead of > > "spi-flash", which is U-Boot specific (sadly). > > > > This patch is not required to make valid U-Boot devicetrees work, it > > is meant to get better error handling for devicetrees ported from > > Linux. > > > > An even better fix would be for U-Boot not to require the compatible = > > "spi-flash" string but just work correctly with Linux device trees, > > but that's not within my possibilities right now :-( > > Ping? This is a bug that should hit nearly everyone porting a board dts > working in Linux to U-Boot, can we please have some kind of fix for this? > Currently, using a dts with an spi flash chip that works in Linux may > abort in U-Boot...
Reviewed-by: Simon Glass <s...@chromium.org> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
