Re: linux-next: manual merge of the gpio tree with Linus' tree
Am 28.05.2014 15:38, schrieb Michael Welling:
> Looking at the Linux next version, I am fairly certian that the following is
> redundant checking:
> if (chips < 0) {
> dev_err(&spi->dev, "FATAL: invalid negative chip
> id\n");
> goto fail;
> }
>
> The chips variable should equal the number of bits in the spi_present_mask
> variable.
> Or am I missing something?
Can be left out. Was just a paranoid check, because with the missing
increment in the of path it became negative.
--
------------
Michael StickelTel. +49 4321 559 56-29
mycable GmbH Fax+49 4321 559 56-10
Gartenstrasse 10
24534 Neumuenster, Germany Email m...@mycable.de
mycable GmbH, Managing Director: Michael Carstens-Behrens
USt-IdNr: DE 214 231 199, Amtsgericht Kiel, HRB 1797 NM
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this e-mail in error,
please notify the sender and delete all copies from your system.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/8] OF: Introduce DT overlay support.
Hi Grant, Am 14.05.2014 12:08, schrieb Grant Likely: > More generally I am concerned about whether or not overlays > will introduce corner cases that can never be handled correctly, > particularly in how multiple overlays will get handled. I want to see > very clear rules on what happens when multiple overlays are applied, and > then removed again. Is it possible to remove overlays out of order? If > so, what are the conditions that would not be allowed? Yes, it is possible that an overlay depends on another. The problem is not, that an overlay is removed other overlays depend on, but that nodes of an overlay may depend on the to-be-removed overlay and the resulting devicetree can become inconsistent. I have an SPI Bus with two slaves. The second slave is used only on one of our boards. That is why we split the overlays the following way: _spi1.dts: Pinmux for SPI-Bus and activation of spi-controller. Pinmux for CS0 and definition of first slave. _spi1_cs1: Pinmux for CS1 and definition of second slave. When the overlay for the bus is removed, the overlays for the second slave does not make any sense anymore. It is even worse in a scenario we have with a test board. One of the slaves is an spi-io-controller with a few bitbanging i2c masters. In an extreme case, each component is defined in a separate overlay and only the overlay with the master is removed. I know, that this is completely sick. The devices are removed cleanly because of the device dependency. Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/7] OF: spi: Add overlay bus handler
Am 18.03.2014 22:56, schrieb Pantelis Antoniou:
> Add the bus handler registration needed for performing overlays
> containing spi devices.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/spi/spi.c | 345
> ++
> 1 file changed, 242 insertions(+), 103 deletions(-)
>
nc is not set in of_register_spi_device and causes an Oops.
Using nc = node works.
What is the purpose of nc?
> +of_register_spi_device(struct spi_master *master, struct device_node *node)
> +{
> + struct spi_device *spi;
> + struct device_node *nc;
> + int err;
> + u32 value;
> +
> + /* Alloc an spi_device */
> + spi = spi_alloc_device(master);
> + if (!spi) {
> + dev_err(&master->dev, "spi_device alloc error for %s\n",
> + nc->full_name);
> + err = -ENOMEM;
> + goto err_out;
> + }
> +
> + /* Select device driver */
> + err = of_modalias_node(nc, spi->modalias,
> + sizeof(spi->modalias));
> + if (err) {
> + dev_err(&master->dev, "cannot find modalias for %s\n",
> + nc->full_name);
> + goto err_out;
> + }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitrotting serial drivers
If we leave the driver for the au1x00 as it is it should not have the register_serial / unregister_serial functions and it should be renamed to something else, e.g. ttySAxxx like it is done for the internal serial port of the strongarm (sa1100). I have thought about the serial driver and came along this. I we take a look at the hardware, we have a chip, the 8250 and its successors and the chip is integrated into some kind of hardware. So the chip has an interface. It has some address lines for register access, it has data lines and some controll lines. It also has an interrupt pin, some (GP)IO-Pins, that are freely programmable and a clock input. The chip is integrated thru some interface as I mentioned before. It can be an ISA-IO card or a PCI card or a multiport card, where more than one chip is accessed thru the same io-range and the hip to access is selected thru a single register. The au1x00 serial driver is like an ISA card except that the chip is mapped to a memory region instead of an io-region and the fact, that we can calculate the baud_base using the pll configuration of the au1x00, if we assume a 12MHz oscilator, which is standard for the au1x00. We need some access methods to access the chip registers, some way to handle intterupts, some way to deal with the gpio-pins, and we need a way to get the clock input of the chip. What should the serial-chip driver know about and what should the card driver know about. It's like the streams concept, where the chip driver does not know how to access the chip or what resources it uses, but what to do with the chip. Regards, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
