As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
its content is being used solely internally to SPI subsystem
(PXA2xx drivers). Hence this refactoring series with the additional
win of getting rid of legacy documentation.
Changelog v2:
- dropped applied patches
- added patch to amend dependencies (Mark)
- amended the second patch accordingly (Mark)
- elaborated purpose of the patch 6 in the commit message (Mark)
Cc: Arnd Bergmann <[email protected]>
Andy Shevchenko (9):
spi: pxa2xx: Narrow the Kconfig option visibility
spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper
spi: pxa2xx: Skip SSP initialization if it's done elsewhere
spi: pxa2xx: Allow number of chip select pins to be read from property
spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
spi: pxa2xx: Move contents of linux/spi/pxa2xx_spi.h to a local one
spi: pxa2xx: Remove outdated documentation
spi: pxa2xx: Don't use "proxy" headers
Documentation/spi/pxa2xx.rst | 208 ---------------------------------
arch/arm/mach-pxa/spitz.c | 25 ++--
drivers/spi/Kconfig | 5 +-
drivers/spi/spi-pxa2xx-dma.c | 11 +-
drivers/spi/spi-pxa2xx-pci.c | 10 +-
drivers/spi/spi-pxa2xx.c | 99 ++++++++++------
drivers/spi/spi-pxa2xx.h | 39 ++++++-
include/linux/spi/pxa2xx_spi.h | 48 --------
8 files changed, 133 insertions(+), 312 deletions(-)
delete mode 100644 Documentation/spi/pxa2xx.rst
delete mode 100644 include/linux/spi/pxa2xx_spi.h
--
2.43.0.rc1.1.gbec44491f096
The documentation is referring to the legacy enumeration of the SPI
host controllers and target devices. It has nothing to do with the
modern way, which is the only supported in kernel right now. Hence,
remove outdated documentation file.
Signed-off-by: Andy Shevchenko <[email protected]>
---
Documentation/spi/pxa2xx.rst | 208 -----------------------------------
drivers/spi/Kconfig | 3 +-
2 files changed, 1 insertion(+), 210 deletions(-)
delete mode 100644 Documentation/spi/pxa2xx.rst
diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst
deleted file mode 100644
index 33d2ad95901e..000000000000
--- a/Documentation/spi/pxa2xx.rst
+++ /dev/null
@@ -1,208 +0,0 @@
-==============================
-PXA2xx SPI on SSP driver HOWTO
-==============================
-
-This a mini HOWTO on the pxa2xx_spi driver. The driver turns a PXA2xx
-synchronous serial port into an SPI host controller
-(see Documentation/spi/spi-summary.rst). The driver has the following features
-
-- Support for any PXA2xx and compatible SSP.
-- SSP PIO and SSP DMA data transfers.
-- External and Internal (SSPFRM) chip selects.
-- Per peripheral device (chip) configuration.
-- Full suspend, freeze, resume support.
-
-The driver is built around a &struct spi_message FIFO serviced by kernel
-thread. The kernel thread, spi_pump_messages(), drives message FIFO and
-is responsible for queuing SPI transactions and setting up and launching
-the DMA or interrupt driven transfers.
-
-Declaring PXA2xx host controllers
----------------------------------
-Typically, for a legacy platform, an SPI host controller is defined in the
-arch/.../mach-*/board-*.c as a "platform device". The host controller configuration
-is passed to the driver via a table found in include/linux/spi/pxa2xx_spi.h::
-
- struct pxa2xx_spi_controller {
- u8 num_chipselect;
- u8 enable_dma;
- ...
- };
-
-The "pxa2xx_spi_controller.num_chipselect" field is used to determine the number of
-peripheral devices (chips) attached to this SPI host controller.
-
-The "pxa2xx_spi_controller.enable_dma" field informs the driver that SSP DMA should
-be used. This caused the driver to acquire two DMA channels: Rx channel and
-Tx channel. The Rx channel has a higher DMA service priority than the Tx channel.
-See the "PXA2xx Developer Manual" section "DMA Controller".
-
-For the new platforms the description of the controller and peripheral devices
-comes from Device Tree or ACPI.
-
-NSSP HOST SAMPLE
-----------------
-Below is a sample configuration using the PXA255 NSSP for a legacy platform::
-
- static struct resource pxa_spi_nssp_resources[] = {
- [0] = {
- .start = __PREG(SSCR0_P(2)), /* Start address of NSSP */
- .end = __PREG(SSCR0_P(2)) + 0x2c, /* Range of registers */
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_NSSP, /* NSSP IRQ */
- .end = IRQ_NSSP,
- .flags = IORESOURCE_IRQ,
- },
- };
-
- static struct pxa2xx_spi_controller pxa_nssp_controller_info = {
- .num_chipselect = 1, /* Matches the number of chips attached to NSSP */
- .enable_dma = 1, /* Enables NSSP DMA */
- };
-
- static struct platform_device pxa_spi_nssp = {
- .name = "pxa2xx-spi", /* MUST BE THIS VALUE, so device match driver */
- .id = 2, /* Bus number, MUST MATCH SSP number 1..n */
- .resource = pxa_spi_nssp_resources,
- .num_resources = ARRAY_SIZE(pxa_spi_nssp_resources),
- .dev = {
- .platform_data = &pxa_nssp_controller_info, /* Passed to driver */
- },
- };
-
- static struct platform_device *devices[] __initdata = {
- &pxa_spi_nssp,
- };
-
- static void __init board_init(void)
- {
- (void)platform_add_device(devices, ARRAY_SIZE(devices));
- }
-
-Declaring peripheral devices
-----------------------------
-Typically, for a legacy platform, each SPI peripheral device (chip) is defined in the
-arch/.../mach-*/board-*.c using the "spi_board_info" structure found in
-"linux/spi/spi.h". See "Documentation/spi/spi-summary.rst" for additional
-information.
-
-Each peripheral device (chip) attached to the PXA2xx must provide specific chip configuration
-information via the structure "pxa2xx_spi_chip" found in
-"include/linux/spi/pxa2xx_spi.h". The PXA2xx host controller driver will use
-the configuration whenever the driver communicates with the peripheral
-device. All fields are optional.
-
-::
-
- struct pxa2xx_spi_chip {
- u8 tx_threshold;
- u8 rx_threshold;
- u8 dma_burst_size;
- u32 timeout;
- };
-
-The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are
-used to configure the SSP hardware FIFO. These fields are critical to the
-performance of pxa2xx_spi driver and misconfiguration will result in rx
-FIFO overruns (especially in PIO mode transfers). Good default values are::
-
- .tx_threshold = 8,
- .rx_threshold = 8,
-
-The range is 1 to 16 where zero indicates "use default".
-
-The "pxa2xx_spi_chip.dma_burst_size" field is used to configure PXA2xx DMA
-engine and is related the "spi_device.bits_per_word" field. Read and understand
-the PXA2xx "Developer Manual" sections on the DMA controller and SSP Controllers
-to determine the correct value. An SSP configured for byte-wide transfers would
-use a value of 8. The driver will determine a reasonable default if
-dma_burst_size == 0.
-
-The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle
-trailing bytes in the SSP receiver FIFO. The correct value for this field is
-dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific
-peripheral device. Please note that the PXA2xx SSP 1 does not support trailing byte
-timeouts and must busy-wait any trailing bytes.
-
-NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the
-chipselect is dropped after each spi_transfer. Most devices need chip select
-asserted around the complete message. Use SSPFRM as a GPIO (through a descriptor)
-to accommodate these chips.
-
-
-NSSP PERIPHERAL SAMPLE
-----------------------
-For a legacy platform or in some other cases, the pxa2xx_spi_chip structure
-is passed to the pxa2xx_spi driver in the "spi_board_info.controller_data"
-field. Below is a sample configuration using the PXA255 NSSP.
-
-::
-
- static struct pxa2xx_spi_chip cs8415a_chip_info = {
- .tx_threshold = 8, /* SSP hardware FIFO threshold */
- .rx_threshold = 8, /* SSP hardware FIFO threshold */
- .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */
- .timeout = 235, /* See Intel documentation */
- };
-
- static struct pxa2xx_spi_chip cs8405a_chip_info = {
- .tx_threshold = 8, /* SSP hardware FIFO threshold */
- .rx_threshold = 8, /* SSP hardware FIFO threshold */
- .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */
- .timeout = 235, /* See Intel documentation */
- };
-
- static struct spi_board_info streetracer_spi_board_info[] __initdata = {
- {
- .modalias = "cs8415a", /* Name of spi_driver for this device */
- .max_speed_hz = 3686400, /* Run SSP as fast a possible */
- .bus_num = 2, /* Framework bus number */
- .chip_select = 0, /* Framework chip select */
- .platform_data = NULL; /* No spi_driver specific config */
- .controller_data = &cs8415a_chip_info, /* Host controller config */
- .irq = STREETRACER_APCI_IRQ, /* Peripheral device interrupt */
- },
- {
- .modalias = "cs8405a", /* Name of spi_driver for this device */
- .max_speed_hz = 3686400, /* Run SSP as fast a possible */
- .bus_num = 2, /* Framework bus number */
- .chip_select = 1, /* Framework chip select */
- .controller_data = &cs8405a_chip_info, /* Host controller config */
- .irq = STREETRACER_APCI_IRQ, /* Peripheral device interrupt */
- },
- };
-
- static void __init streetracer_init(void)
- {
- spi_register_board_info(streetracer_spi_board_info,
- ARRAY_SIZE(streetracer_spi_board_info));
- }
-
-
-DMA and PIO I/O Support
------------------------
-The pxa2xx_spi driver supports both DMA and interrupt driven PIO message
-transfers. The driver defaults to PIO mode and DMA transfers must be enabled
-by setting the "enable_dma" flag in the "pxa2xx_spi_controller" structure.
-For the newer platforms, that are known to support DMA, the driver will enable
-it automatically and try it first with a possible fallback to PIO. The DMA
-mode supports both coherent and stream based DMA mappings.
-
-The following logic is used to determine the type of I/O to be used on
-a per "spi_transfer" basis::
-
- if spi_message.len > 65536 then
- print "rate limited" warning
- use PIO transfers
-
- if enable_dma and the size is in the range [DMA burst size..65536] then
- use streaming DMA mode
-
- otherwise
- use PIO transfer
-
-THANKS TO
----------
-David Brownell and others for mentoring the development of this driver.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index c1bb1895009c..11d7ac8aed4a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -821,8 +821,7 @@ config SPI_PXA2XX
select PXA_SSP if ARCH_PXA || ARCH_MMP
help
This enables using a PXA2xx or Sodaville SSP port as a SPI master
- controller. The driver can be configured to use any SSP port and
- additional documentation can be found a Documentation/spi/pxa2xx.rst.
+ controller. The driver can be configured to use any SSP port.
config SPI_PXA2XX_PCI
def_tristate SPI_PXA2XX && PCI && COMMON_CLK
--
2.43.0.rc1.1.gbec44491f096
There is no user of the linux/spi/pxa2xx_spi.h. Move its contents
to the drivers/spi/spi-pxa2xx.h.
Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/spi-pxa2xx-dma.c | 1 -
drivers/spi/spi-pxa2xx-pci.c | 4 +--
drivers/spi/spi-pxa2xx.c | 1 -
drivers/spi/spi-pxa2xx.h | 36 ++++++++++++++++++++++++-
include/linux/spi/pxa2xx_spi.h | 48 ----------------------------------
5 files changed, 37 insertions(+), 53 deletions(-)
delete mode 100644 include/linux/spi/pxa2xx_spi.h
diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index be563f0dd03a..26416ced6505 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -12,7 +12,6 @@
#include <linux/scatterlist.h>
#include <linux/sizes.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/spi/spi.h>
#include "spi-pxa2xx.h"
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 861b21c63504..e11a613bc340 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -10,11 +10,11 @@
#include <linux/pci.h>
#include <linux/platform_device.h>
-#include <linux/spi/pxa2xx_spi.h>
-
#include <linux/dmaengine.h>
#include <linux/platform_data/dma-dw.h>
+#include "spi-pxa2xx.h"
+
#define PCI_DEVICE_ID_INTEL_QUARK_X1000 0x0935
#define PCI_DEVICE_ID_INTEL_BYT 0x0f0e
#define PCI_DEVICE_ID_INTEL_MRFLD 0x1194
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index f4435c39d096..e22d9d29c7e9 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -24,7 +24,6 @@
#include <linux/property.h>
#include <linux/slab.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/spi/spi.h>
#include "spi-pxa2xx.h"
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 45cdbbc71c4b..08296729ea80 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -7,6 +7,7 @@
#ifndef SPI_PXA2XX_H
#define SPI_PXA2XX_H
+#include <linux/dmaengine.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/types.h>
@@ -15,7 +16,40 @@
#include <linux/pxa2xx_ssp.h>
struct gpio_desc;
-struct pxa2xx_spi_controller;
+
+/*
+ * The platform data for SSP controller devices
+ * (resides in device.platform_data).
+ */
+struct pxa2xx_spi_controller {
+ u8 num_chipselect;
+ u8 enable_dma;
+ u8 dma_burst_size;
+ bool is_target;
+
+ /* DMA engine specific config */
+ dma_filter_fn dma_filter;
+ void *tx_param;
+ void *rx_param;
+
+ /* For non-PXA arches */
+ struct ssp_device ssp;
+};
+
+/*
+ * The controller specific data for SPI target devices
+ * (resides in spi_board_info.controller_data),
+ * copied to spi_device.platform_data ... mostly for
+ * DMA tuning.
+ */
+struct pxa2xx_spi_chip {
+ u8 tx_threshold;
+ u8 tx_hi_threshold;
+ u8 rx_threshold;
+ u8 dma_burst_size;
+ u32 timeout;
+};
+
struct spi_controller;
struct spi_device;
struct spi_transfer;
diff --git a/include/linux/spi/pxa2xx_spi.h b/include/linux/spi/pxa2xx_spi.h
deleted file mode 100644
index e5a4a045fb67..000000000000
--- a/include/linux/spi/pxa2xx_spi.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Copyright (C) 2005 Stephen Street / StreetFire Sound Labs
- */
-#ifndef __LINUX_SPI_PXA2XX_SPI_H
-#define __LINUX_SPI_PXA2XX_SPI_H
-
-#include <linux/dmaengine.h>
-#include <linux/types.h>
-
-#include <linux/pxa2xx_ssp.h>
-
-struct dma_chan;
-
-/*
- * The platform data for SSP controller devices
- * (resides in device.platform_data).
- */
-struct pxa2xx_spi_controller {
- u8 num_chipselect;
- u8 enable_dma;
- u8 dma_burst_size;
- bool is_target;
-
- /* DMA engine specific config */
- dma_filter_fn dma_filter;
- void *tx_param;
- void *rx_param;
-
- /* For non-PXA arches */
- struct ssp_device ssp;
-};
-
-/*
- * The controller specific data for SPI target devices
- * (resides in spi_board_info.controller_data),
- * copied to spi_device.platform_data ... mostly for
- * DMA tuning.
- */
-struct pxa2xx_spi_chip {
- u8 tx_threshold;
- u8 tx_hi_threshold;
- u8 rx_threshold;
- u8 dma_burst_size;
- u32 timeout;
-};
-
-#endif /* __LINUX_SPI_PXA2XX_SPI_H */
--
2.43.0.rc1.1.gbec44491f096
Since driver can parse num-cs device property, replace platform data
with this new approach. This pursues the following objectives:
- getting rid of the public header that barely used outside of
the SPI subsystem (more specifically the SPI PXA2xx drivers)
- making a trampoline for the driver to support non-default number
of the chip select pins in case the original code is going to be
converted to Device Tree model
It's not expected to have more users in board files except this one.
Signed-off-by: Andy Shevchenko <[email protected]>
---
arch/arm/mach-pxa/spitz.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 318402ad685e..3c5f5a3cb480 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -18,10 +18,10 @@
#include <linux/i2c.h>
#include <linux/platform_data/i2c-pxa.h>
#include <linux/platform_data/pca953x.h>
+#include <linux/property.h>
#include <linux/spi/spi.h>
#include <linux/spi/ads7846.h>
#include <linux/spi/corgi_lcd.h>
-#include <linux/spi/pxa2xx_spi.h>
#include <linux/mtd/sharpsl.h>
#include <linux/mtd/physmap.h>
#include <linux/input-event-codes.h>
@@ -569,10 +569,6 @@ static struct spi_board_info spitz_spi_devices[] = {
},
};
-static struct pxa2xx_spi_controller spitz_spi_info = {
- .num_chipselect = 3,
-};
-
static struct gpiod_lookup_table spitz_spi_gpio_table = {
.dev_id = "spi2",
.table = {
@@ -583,10 +579,20 @@ static struct gpiod_lookup_table spitz_spi_gpio_table = {
},
};
+static const struct property_entry spitz_spi_properties[] = {
+ PROPERTY_ENTRY_U32("num-cs", 3),
+ { }
+};
+
+static const struct software_node spitz_spi_node = {
+ .properties = spitz_spi_properties,
+};
+
static void __init spitz_spi_init(void)
{
struct platform_device *pd;
int id = 2;
+ int err;
if (machine_is_akita())
gpiod_add_lookup_table(&akita_lcdcon_gpio_table);
@@ -601,8 +607,13 @@ static void __init spitz_spi_init(void)
if (pd == NULL) {
pr_err("pxa2xx-spi: failed to allocate device id %d\n", id);
} else {
- pd->dev.platform_data = &spitz_spi_info;
- platform_device_add(pd);
+ err = device_add_software_node(&pd->dev, &spitz_spi_node);
+ if (err) {
+ platform_device_put(pd);
+ pr_err("pxa2xx-spi: failed to add software node\n");
+ } else {
+ platform_device_add(pd);
+ }
}
spi_register_board_info(ARRAY_AND_SIZE(spitz_spi_devices));
--
2.43.0.rc1.1.gbec44491f096
The PCI || ACPI dependency is the historical part of the x86 support.
Narrow the Kconfig option visibility by limiting this dependency to x86.
The drop of x86 for PCI case had happened in the commit 2b49ebda39d6
("spi/pxa2xx: allow building on a 64-bit kernel"), while the ACPI
was specifically added for Intel Lynx Point in the commit a3496855d9f1
("spi/pxa2xx: add support for Lynxpoint SPI controllers").
Note that X86 covers both 32- and 64-bit variants.
Suggested-by: Mark Brown <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/spi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 26ba34a4100b..c1bb1895009c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -817,7 +817,7 @@ config SPI_PPC4xx
config SPI_PXA2XX
tristate "PXA2xx SSP SPI master"
- depends on ARCH_PXA || ARCH_MMP || PCI || ACPI || COMPILE_TEST
+ depends on ARCH_PXA || ARCH_MMP || (X86 && (PCI || ACPI)) || COMPILE_TEST
select PXA_SSP if ARCH_PXA || ARCH_MMP
help
This enables using a PXA2xx or Sodaville SSP port as a SPI master
--
2.43.0.rc1.1.gbec44491f096
On Wed, 27 Mar 2024 21:29:19 +0200, Andy Shevchenko wrote:
> As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
> its content is being used solely internally to SPI subsystem
> (PXA2xx drivers). Hence this refactoring series with the additional
> win of getting rid of legacy documentation.
>
> Changelog v2:
> - dropped applied patches
> - added patch to amend dependencies (Mark)
> - amended the second patch accordingly (Mark)
> - elaborated purpose of the patch 6 in the commit message (Mark)
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/9] spi: pxa2xx: Narrow the Kconfig option visibility
commit: 3af201a405b3e5abee65102b062c309fff68cc0e
[2/9] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
commit: 9907c475dcab9b269422972577360122129ac84c
[3/9] spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper
commit: 7290f1e4075d28ab961df5a454503296fa289271
[4/9] spi: pxa2xx: Skip SSP initialization if it's done elsewhere
commit: bb77c99ee6d3d704086acf141d3ec92601747809
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
On Fri, Mar 29, 2024 at 01:29:10AM +0000, Mark Brown wrote:
> On Wed, 27 Mar 2024 21:29:19 +0200, Andy Shevchenko wrote:
> > As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
> > its content is being used solely internally to SPI subsystem
> > (PXA2xx drivers). Hence this refactoring series with the additional
> > win of getting rid of legacy documentation.
> >
> > Changelog v2:
> > - dropped applied patches
> > - added patch to amend dependencies (Mark)
> > - amended the second patch accordingly (Mark)
> > - elaborated purpose of the patch 6 in the commit message (Mark)
> >
> > [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
>
> Thanks!
>
> [1/9] spi: pxa2xx: Narrow the Kconfig option visibility
> commit: 3af201a405b3e5abee65102b062c309fff68cc0e
> [2/9] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
> commit: 9907c475dcab9b269422972577360122129ac84c
> [3/9] spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper
> commit: 7290f1e4075d28ab961df5a454503296fa289271
> [4/9] spi: pxa2xx: Skip SSP initialization if it's done elsewhere
> commit: bb77c99ee6d3d704086acf141d3ec92601747809
Thank you!
Do I need to do anything else to get the rest applied?
--
With Best Regards,
Andy Shevchenko
On Wed, Apr 03, 2024 at 02:07:29PM +0300, Andy Shevchenko wrote:
> Do I need to do anything else to get the rest applied?
All the concerns I have with swnodes just being a more complex and less
maintainable way of doing things still stand, I'm not clear that this is
making anything better.
On Wed, Apr 03, 2024 at 02:29:38PM +0100, Mark Brown wrote:
> On Wed, Apr 03, 2024 at 02:07:29PM +0300, Andy Shevchenko wrote:
>
> > Do I need to do anything else to get the rest applied?
>
> All the concerns I have with swnodes just being a more complex and less
> maintainable way of doing things still stand, I'm not clear that this is
> making anything better.
As I explained before it's not less maintainable than device tree sources.
The only difference is that we don't have validation tool for in-kernel
tables. And I don't see why we need that. The data describes the platforms
and in the very same way may come to the driver from elsewhere.
How would you validate that? It the same as we trust firmware (boot loader)
or not. If we don't than how should we do at all?
Can you point out what the exact aspect is most significant from C language
perspective that we miss after conversion? Type checking? Something else?
--
With Best Regards,
Andy Shevchenko
On Wed, Apr 03, 2024 at 04:39:13PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 03, 2024 at 02:29:38PM +0100, Mark Brown wrote:
> > On Wed, Apr 03, 2024 at 02:07:29PM +0300, Andy Shevchenko wrote:
> >
> > > Do I need to do anything else to get the rest applied?
> >
> > All the concerns I have with swnodes just being a more complex and less
> > maintainable way of doing things still stand, I'm not clear that this is
> > making anything better.
>
> As I explained before it's not less maintainable than device tree sources.
> The only difference is that we don't have validation tool for in-kernel
> tables. And I don't see why we need that. The data describes the platforms
> and in the very same way may come to the driver from elsewhere.
> How would you validate that? It the same as we trust firmware (boot loader)
> or not. If we don't than how should we do at all?
>
> Can you point out what the exact aspect is most significant from C language
> perspective that we miss after conversion? Type checking? Something else?
Also note, after hiding the data structures from that file we open
the door for the much bigger cleanup, and I have patches already precooked
(need a bit of time to test, though).
--
With Best Regards,
Andy Shevchenko