On 26 June 2016 at 03:15, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Thu, Jun 23, 2016 at 05:41:20PM -0000, Michal Suchanek wrote: >> SPI slave devices are not created when looking up driver for the slave >> fails. Create a device anyway so it can be manually bound to a driver. > >> @@ -1543,11 +1542,10 @@ of_register_spi_device(struct spi_master *master, struct device_node *nc) >> /* Device speed */ >> rc = of_property_read_u32(nc, "spi-max-frequency", &value); >> if (rc) { >> - dev_err(&master->dev, "%s has no valid 'spi-max-frequency' property (%d)\n", >> + dev_warn(&master->dev, "%s has no valid 'spi-max-frequency' property (%d)\n", >> nc->full_name, rc); >> - goto err_out; >> - } >> - spi->max_speed_hz = value; >> + } else >> + spi->max_speed_hz = value; >> > > I can't relate this hunk to the changelog and there's a coding style > problem, if there's { } on one side of an if statement it should be on > both sides. Why are we making this change? The intention is that you can specify that your SPI master controller has a CS available without setting up the slave &spi2 { pinctrl-names = "default"; pinctrl-0 = <&spi2_pins_a>, <&spi2_cs0_pins_a>; status = "okay"; uext_spi: spi@uext { reg = <0>; }; }; Then you can amend the slave node with an overlay or bind a driver that can deal with the node having no configuration. The check here isn't very effective anyway since slaves with zero speed somehow creep into the kernel. I have seen people reporting division by zero in SPI master driver as a result. The proper way to fix this is to specify the master minimum and maximum speed limit so the SPI core can reject transfers with speed outside of the allowed range. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html