| Message ID | 20240619121703.3411989-1-ckeepax@opensource.cirrus.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/2] spi: cs42l43: Refactor accessing the SDCA extension properties | expand |
On Wed, 19 Jun 2024 13:17:02 +0100, Charles Keepax wrote: > Refactor accessing the SDCA extension properties to make it easier to > access multiple properties to assist with future features. Return the > node itself and allow the caller to read the actual properties. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/2] spi: cs42l43: Refactor accessing the SDCA extension properties commit: 6914ee9cd1b0c91bd2fb4dbe204947c3c31259e1 [2/2] spi: cs42l43: Add speaker id support to the bridge configuration (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
On Wed, Jun 19, 2024 at 01:50:48PM +0100, Mark Brown wrote: > On Wed, 19 Jun 2024 13:17:02 +0100, Charles Keepax wrote: > > Refactor accessing the SDCA extension properties to make it easier to > > access multiple properties to assist with future features. Return the > > node itself and allow the caller to read the actual properties. > > > > > > Applied to > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next > > Thanks! > > [1/2] spi: cs42l43: Refactor accessing the SDCA extension properties > commit: 6914ee9cd1b0c91bd2fb4dbe204947c3c31259e1 > [2/2] spi: cs42l43: Add speaker id support to the bridge configuration > (no commit info) > Not sure all went smoothly here. This seems to have picked up v1 of the first patch and not picked up the second one. Thanks, Charles
On Wed, Jun 19, 2024 at 02:26:36PM +0100, Charles Keepax wrote: > On Wed, Jun 19, 2024 at 01:50:48PM +0100, Mark Brown wrote: > > [1/2] spi: cs42l43: Refactor accessing the SDCA extension properties > > commit: 6914ee9cd1b0c91bd2fb4dbe204947c3c31259e1 > > [2/2] spi: cs42l43: Add speaker id support to the bridge configuration > > (no commit info) > Not sure all went smoothly here. This seems to have picked up v1 > of the first patch and not picked up the second one. That's because when I told you that the second patch didn't apply I left the other one in the queue, and what you sent now didn't apply either.
On Wed, Jun 19, 2024 at 02:30:33PM +0100, Mark Brown wrote: > On Wed, Jun 19, 2024 at 02:26:36PM +0100, Charles Keepax wrote: > > On Wed, Jun 19, 2024 at 01:50:48PM +0100, Mark Brown wrote: > > > > [1/2] spi: cs42l43: Refactor accessing the SDCA extension properties > > > commit: 6914ee9cd1b0c91bd2fb4dbe204947c3c31259e1 > > > [2/2] spi: cs42l43: Add speaker id support to the bridge configuration > > > (no commit info) > > > Not sure all went smoothly here. This seems to have picked up v1 > > of the first patch and not picked up the second one. > > That's because when I told you that the second patch didn't apply I left > the other one in the queue, and what you sent now didn't apply either. Hmm... what branch are you applying this to? Pulling the patch off the list and git am-ing it onto your spi for-next branch works fine for me. I mean I can just resend it but presumably we will hit the same issue again. Thanks, Charles
On Wed, Jun 19, 2024 at 02:40:04PM +0100, Charles Keepax wrote: > On Wed, Jun 19, 2024 at 02:30:33PM +0100, Mark Brown wrote: > > That's because when I told you that the second patch didn't apply I left > > the other one in the queue, and what you sent now didn't apply either. > Hmm... what branch are you applying this to? Pulling the patch > off the list and git am-ing it onto your spi for-next branch > works fine for me. Nothing gets applied to for-next or for-linus, they get applied to the version specific branches or sometimes a topic branch. Those two branches are constantly regenerated merges. > I mean I can just resend it but presumably we will hit the same > issue again. I didn't mail you yet because I didn't look at trying to figure out what it might apply to.
On Wed, Jun 19, 2024 at 02:40:04PM +0100, Charles Keepax wrote: > On Wed, Jun 19, 2024 at 02:30:33PM +0100, Mark Brown wrote: > > On Wed, Jun 19, 2024 at 02:26:36PM +0100, Charles Keepax wrote: > > > On Wed, Jun 19, 2024 at 01:50:48PM +0100, Mark Brown wrote: > > > > > > [1/2] spi: cs42l43: Refactor accessing the SDCA extension properties > > > > commit: 6914ee9cd1b0c91bd2fb4dbe204947c3c31259e1 > > > > [2/2] spi: cs42l43: Add speaker id support to the bridge configuration > > > > (no commit info) > > > > > Not sure all went smoothly here. This seems to have picked up v1 > > > of the first patch and not picked up the second one. > > > > That's because when I told you that the second patch didn't apply I left > > the other one in the queue, and what you sent now didn't apply either. > > Hmm... what branch are you applying this to? Pulling the patch > off the list and git am-ing it onto your spi for-next branch > works fine for me. > > I mean I can just resend it but presumably we will hit the same > issue again. > Ah I see I think your applying to the for-6.11 branch, which is missing 60980cf5b8c8 ("spi: cs42l43: Drop cs35l56 SPI speed down to 11MHz"). I can send a version based not on that but might make a bit of an annoying merge conflict later? Thanks, Charles
On Wed, Jun 19, 2024 at 02:47:25PM +0100, Charles Keepax wrote: > Ah I see I think your applying to the for-6.11 branch, which is > missing 60980cf5b8c8 ("spi: cs42l43: Drop cs35l56 SPI speed down > to 11MHz"). I can send a version based not on that but might make > a bit of an annoying merge conflict later? Like I say I haven't looked at this yet. I will tell you if I can't apply it.
diff --git a/drivers/spi/spi-cs42l43.c b/drivers/spi/spi-cs42l43.c index 8b618ef0f711..7b6fc6158a3b 100644 --- a/drivers/spi/spi-cs42l43.c +++ b/drivers/spi/spi-cs42l43.c @@ -9,6 +9,7 @@ #include <linux/array_size.h> #include <linux/bits.h> #include <linux/bitfield.h> +#include <linux/cleanup.h> #include <linux/device.h> #include <linux/errno.h> #include <linux/gpio/machine.h> @@ -246,11 +247,10 @@ static size_t cs42l43_spi_max_length(struct spi_device *spi) return CS42L43_SPI_MAX_LENGTH; } -static bool cs42l43_has_sidecar(struct fwnode_handle *fwnode) +static struct fwnode_handle *cs42l43_find_xu_node(struct fwnode_handle *fwnode) { static const u32 func_smart_amp = 0x1; struct fwnode_handle *child_fwnode, *ext_fwnode; - unsigned int val; u32 function; int ret; @@ -266,21 +266,12 @@ static bool cs42l43_has_sidecar(struct fwnode_handle *fwnode) if (!ext_fwnode) continue; - ret = fwnode_property_read_u32(ext_fwnode, - "01fa-sidecar-instances", - &val); - - fwnode_handle_put(ext_fwnode); - - if (ret) - continue; - fwnode_handle_put(child_fwnode); - return !!val; + return ext_fwnode; } - return false; + return NULL; } static void cs42l43_release_of_node(void *data) @@ -298,7 +289,8 @@ static int cs42l43_spi_probe(struct platform_device *pdev) struct cs42l43 *cs42l43 = dev_get_drvdata(pdev->dev.parent); struct cs42l43_spi *priv; struct fwnode_handle *fwnode = dev_fwnode(cs42l43->dev); - bool has_sidecar = cs42l43_has_sidecar(fwnode); + struct fwnode_handle *xu_fwnode __free(fwnode_handle) = cs42l43_find_xu_node(fwnode); + int nsidecars = 0; int ret; priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); @@ -350,7 +342,9 @@ static int cs42l43_spi_probe(struct platform_device *pdev) return ret; } - if (has_sidecar) { + fwnode_property_read_u32(xu_fwnode, "01fa-sidecar-instances", &nsidecars); + + if (nsidecars) { ret = software_node_register(&cs42l43_gpiochip_swnode); if (ret) return dev_err_probe(priv->dev, ret, @@ -373,7 +367,7 @@ static int cs42l43_spi_probe(struct platform_device *pdev) return dev_err_probe(priv->dev, ret, "Failed to register SPI controller\n"); - if (has_sidecar) { + if (nsidecars) { if (!spi_new_device(priv->ctlr, &l_info)) return dev_err_probe(priv->dev, -ENODEV, "Failed to create left amp slave\n");
Refactor accessing the SDCA extension properties to make it easier to access multiple properties to assist with future features. Return the node itself and allow the caller to read the actual properties. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> --- Based off the SPI for-next branch no need for this to go through the same tree as c38082bf223f ("ASoC: cs35l56: Attempt to read from cirrus,speaker-id device property first"). Changes since v1: - Move header include to correct patch - Rebase Thanks, Charles drivers/spi/spi-cs42l43.c | 26 ++++++++++---------------- 1 file changed, 10 insertions(+), 16 deletions(-)