Here is the additional cleanup of the driver based on the fact of
the linux/spi/pxa2xx_spi.h being a local (to drivers/spi/) header.
This means it's based on top of "spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h"
([email protected]).
Andy Shevchenko (5):
spi: pxa2xx: Move number of CS pins validation out of condition
spi: pxa2xx: Drop struct pxa2xx_spi_chip
spi: pxa2xx: Remove DMA parameters from struct chip_data
spi: pxa2xx: Remove timeout field from struct chip_data
spi: pxa2xx: Don't provide struct chip_data for others
drivers/spi/spi-pxa2xx-dma.c | 27 +----------
drivers/spi/spi-pxa2xx.c | 92 +++++++++---------------------------
drivers/spi/spi-pxa2xx.h | 31 ------------
3 files changed, 25 insertions(+), 125 deletions(-)
--
2.43.0.rc1.1.gbec44491f096
Now the struct chip_data is local to spi-pxa2xx.c, move
its definition to the C file. This will slightly speed up
a build and also hide badly named data type (too generic).
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx.c | 8 ++++++++
drivers/spi/spi-pxa2xx.h | 8 --------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 030afb17e606..efe76d0c21bb 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -66,6 +66,14 @@ MODULE_ALIAS("platform:pxa2xx-spi");
| CE4100_SSCR1_RFT | CE4100_SSCR1_TFT | SSCR1_MWDS \
| SSCR1_SPH | SSCR1_SPO | SSCR1_LBM)
+struct chip_data {
+ u32 cr1;
+ u32 dds_rate;
+ u32 threshold;
+ u16 lpss_rx_threshold;
+ u16 lpss_tx_threshold;
+};
+
#define LPSS_GENERAL_REG_RXTO_HOLDOFF_DISABLE BIT(24)
#define LPSS_CS_CONTROL_SW_MODE BIT(0)
#define LPSS_CS_CONTROL_CS_HIGH BIT(1)
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 5f741bb30240..93e1e471e1c6 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -75,14 +75,6 @@ struct driver_data {
struct gpio_desc *gpiod_ready;
};
-struct chip_data {
- u32 cr1;
- u32 dds_rate;
- u32 threshold;
- u16 lpss_rx_threshold;
- u16 lpss_tx_threshold;
-};
-
static inline u32 pxa2xx_spi_read(const struct driver_data *drv_data, u32 reg)
{
return pxa_ssp_read_reg(drv_data->ssp, reg);
--
2.43.0.rc1.1.gbec44491f096
There is no need to allocate chip_data and then validate number of
CS pins as it will have the same effect. Hence move number of CS pins
validation out of condition in setup().
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 1348249f8178..cc0e54f8d2c3 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1200,6 +1200,13 @@ static int setup(struct spi_device *spi)
break;
}
+ if (drv_data->ssp_type == CE4100_SSP) {
+ if (spi_get_chipselect(spi, 0) > 4) {
+ dev_err(&spi->dev, "failed setup: cs number must not be > 4.\n");
+ return -EINVAL;
+ }
+ }
+
/* Only allocate on the first setup */
chip = spi_get_ctldata(spi);
if (!chip) {
@@ -1207,14 +1214,6 @@ static int setup(struct spi_device *spi)
if (!chip)
return -ENOMEM;
- if (drv_data->ssp_type == CE4100_SSP) {
- if (spi_get_chipselect(spi, 0) > 4) {
- dev_err(&spi->dev,
- "failed setup: cs number must not be > 4.\n");
- kfree(chip);
- return -EINVAL;
- }
- }
chip->enable_dma = drv_data->controller_info->enable_dma;
chip->timeout = TIMOUT_DFLT;
}
--
2.43.0.rc1.1.gbec44491f096
The timeout field is used only once and assigned to a predefined
constant. Replace all that by using the constant directly.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx.c | 4 +---
drivers/spi/spi-pxa2xx.h | 1 -
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 3ba0f5816f7f..030afb17e606 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1058,7 +1058,7 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
pxa_ssp_disable(drv_data->ssp);
if (!pxa25x_ssp_comp(drv_data))
- pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
+ pxa2xx_spi_write(drv_data, SSTO, TIMOUT_DFLT);
/* First set CR1 without interrupt and service enables */
pxa2xx_spi_update(drv_data, SSCR1, change_mask, cr1);
@@ -1200,8 +1200,6 @@ static int setup(struct spi_device *spi)
chip = kzalloc(sizeof(struct chip_data), GFP_KERNEL);
if (!chip)
return -ENOMEM;
-
- chip->timeout = TIMOUT_DFLT;
}
chip->cr1 = 0;
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 10294ef209d9..5f741bb30240 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -78,7 +78,6 @@ struct driver_data {
struct chip_data {
u32 cr1;
u32 dds_rate;
- u32 timeout;
u32 threshold;
u16 lpss_rx_threshold;
u16 lpss_tx_threshold;
--
2.43.0.rc1.1.gbec44491f096
On Wed, 03 Apr 2024 20:06:34 +0300, Andy Shevchenko wrote:
> Here is the additional cleanup of the driver based on the fact of
> the linux/spi/pxa2xx_spi.h being a local (to drivers/spi/) header.
> This means it's based on top of "spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h"
> ([email protected]).
>
> Andy Shevchenko (5):
> spi: pxa2xx: Move number of CS pins validation out of condition
> spi: pxa2xx: Drop struct pxa2xx_spi_chip
> spi: pxa2xx: Remove DMA parameters from struct chip_data
> spi: pxa2xx: Remove timeout field from struct chip_data
> spi: pxa2xx: Don't provide struct chip_data for others
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/5] spi: pxa2xx: Move number of CS pins validation out of condition
commit: df3431fd379dcc3b231bd109a55948c27474478d
[2/5] spi: pxa2xx: Drop struct pxa2xx_spi_chip
(no commit info)
[3/5] spi: pxa2xx: Remove DMA parameters from struct chip_data
(no commit info)
[4/5] spi: pxa2xx: Remove timeout field from struct chip_data
(no commit info)
[5/5] spi: pxa2xx: Don't provide struct chip_data for others
(no commit info)
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark