Received-SPF: pass (google.com: domain of linux-kernel+bounces-130620-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Thu, 4 Apr 2024 00:24:54 +0300
To: Colin Foster <colin.foster@in-advantage.com>
Cc: Mark Brown <broonie@kernel.org>,
	Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>,
	linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 6.8 SPI Chip Select Regression
Message-ID: <Zg3JJtzdB5Q3aGsl@surfacebook.localdomain>
References: <Zgx5glZznSCheksj@euler>
 <467644bf-85d0-429a-bd11-7155b1cb5fbc@sirena.org.uk>
 <Zgy7llSklu7iU2Om@euler>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zgy7llSklu7iU2Om@euler>

Tue, Apr 02, 2024 at 09:14:46PM -0500, Colin Foster kirjoitti:
> Hi Mark,
> 
> Thanks for the quick response.
> 
> On Wed, Apr 03, 2024 at 12:52:44AM +0100, Mark Brown wrote:
> > On Tue, Apr 02, 2024 at 04:32:50PM -0500, Colin Foster wrote:
> > > Hi Amit,
> > 
> > Amit, please respond to these issues - you never replied to the mails
> > about the other regressions this introduced either...
> > 
> > > [    3.459990] omap2_mcspi 48030000.spi: chipselect 0 already in use
> > > [    3.466135] spi_master spi0: spi_device register error /ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/soc@0
> > > [    3.477495] spi_master spi0: Failed to create SPI device for /ocp/interconnect@48000000/segment@0/target-module@30000/spi@0/soc@0
> > 
> > > Is this a known issue? Is there anything I either might need to do to a
> > > device tree, or something you might suggest to help troubleshoot this?
> > 
> > This is not known, and given that you say there's only one chip select
> > in use on the system seems clearly bogus.  There were some regressions
> > with trying to use more than the hard coded maximum number of chip
> > selects but they have a different error pattern.  It's late so I'll not
> > look properly right now but...
> > 
> > Do you know what chip select 0 is - if you add a WARN_ON() to
> > spi_set_chipselect() it should show a prior call to the function,
> 
> Log is below. There aren't any other SPI devices, so I'm not really sure
> what is the issue just yet. It is also using the built-in chip select,
> not a GPIO.
> 
> > or is
> > it some logic bug that somehow is not manifesting on other systems that
> > use chip select 0?  Though looking quickly there has been some factoring
> > out since that commit was merged...  just to confirm, did you bisect to
> > find the problematic commit? 
> 
> I bisected, and just confirmed again that the previous commit,
> f05e2f61fe88: ("ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select")
> does boot as expected.
> 
> I noticed the issue on 6.9-rc2, then jumped back to 6.8, then 6.7.
> Bisected between 6.7 and 6.8.
> 
> > If you could show the DT for your setup
> > that'd help, especially if this is a GPIO chip select.
> 
> It should be attached. It is really nothing more than the beaglebone
> black with this SPI addition. The only things out-of-tree are some VLAN
> and MTU tweaks I had to make for my DSA networking setup to work.

You have
addr cell = 1
sz cell = 0

At the same time you have 
reg <0 0>

AFAICT the SPI core behaves correctly. Am I wrong?

I.o.w. you either want to have reg = <0>, or <0 1> or something which has
different values.

-- 
With Best Regards,
Andy Shevchenko