| Message ID | 1531815558-20002-3-git-send-email-amit.pundir@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | Stable commits picked up from lede project | expand |
On Tue, Jul 17, 2018 at 01:49:15PM +0530, Amit Pundir wrote: > From: Jonas Gorski <jonas.gorski@gmail.com> > > commit 0135c03df914f0481c61f097c78d37cece84f330 upstream. > > The bcm63xx SPI controller does not allow manual control of the CS > lines and will toggle it automatically before and after sending data, > so we are limited to messages that fit in the FIFO buffer. Since the CS > lines aren't available as GPIOs either, we will need to make slave > drivers aware of this limitation so they can handle them accordingly. This seems a bit new featureish...
On Wed, Jul 18, 2018 at 11:47:18AM +0100, Mark Brown wrote: > On Tue, Jul 17, 2018 at 01:49:15PM +0530, Amit Pundir wrote: > > From: Jonas Gorski <jonas.gorski@gmail.com> > > > > commit 0135c03df914f0481c61f097c78d37cece84f330 upstream. > > > > The bcm63xx SPI controller does not allow manual control of the CS > > lines and will toggle it automatically before and after sending data, > > so we are limited to messages that fit in the FIFO buffer. Since the CS > > lines aren't available as GPIOs either, we will need to make slave > > drivers aware of this limitation so they can handle them accordingly. > > This seems a bit new featureish... It is? Reads like a bugfix to me to get crappy hardware to work properly :) Almost like a quirk addition. Anyway, it's a 9 line patch that the users of the hardware require to get it to work, is it a problem to add? thanks, greg k-h
On Wed, Jul 18, 2018 at 12:55:46PM +0200, Greg KH wrote: > On Wed, Jul 18, 2018 at 11:47:18AM +0100, Mark Brown wrote: > > On Tue, Jul 17, 2018 at 01:49:15PM +0530, Amit Pundir wrote: > > > The bcm63xx SPI controller does not allow manual control of the CS > > > lines and will toggle it automatically before and after sending data, > > > so we are limited to messages that fit in the FIFO buffer. Since the CS > > > lines aren't available as GPIOs either, we will need to make slave > > > drivers aware of this limitation so they can handle them accordingly. > > This seems a bit new featureish... > It is? Reads like a bugfix to me to get crappy hardware to work > properly :) > Almost like a quirk addition. Yes, it is a quirk addition. > Anyway, it's a 9 line patch that the users of the hardware require to > get it to work, is it a problem to add? It's one of these cases where if someone notices the change it's because it causes the consumer driver to exercise code paths that they weren't otherwise exercising (for a little used feature too). If it were just in the driver perhaps but the actual use of the change would be in other code which makes it more risky.
diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c index fee747030ee6..caa733ec405c 100644 --- a/drivers/spi/spi-bcm63xx.c +++ b/drivers/spi/spi-bcm63xx.c @@ -428,6 +428,13 @@ static irqreturn_t bcm63xx_spi_interrupt(int irq, void *dev_id) return IRQ_HANDLED; } +static size_t bcm63xx_spi_max_length(struct spi_device *dev) +{ + struct bcm63xx_spi *bs = spi_master_get_devdata(spi->master); + + return bs->fifo_size; +} + static const unsigned long bcm6348_spi_reg_offsets[] = { [SPI_CMD] = SPI_6348_CMD, [SPI_INT_STATUS] = SPI_6348_INT_STATUS, @@ -541,6 +548,8 @@ static int bcm63xx_spi_probe(struct platform_device *pdev) master->transfer_one_message = bcm63xx_spi_transfer_one; master->mode_bits = MODEBITS; master->bits_per_word_mask = SPI_BPW_MASK(8); + master->max_transfer_size = bcm63xx_spi_max_length; + master->max_message_size = bcm63xx_spi_max_length; master->auto_runtime_pm = true; bs->msg_type_shift = bs->reg_offsets[SPI_MSG_TYPE_SHIFT]; bs->msg_ctl_width = bs->reg_offsets[SPI_MSG_CTL_WIDTH];