lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zg3JJtzdB5Q3aGsl@surfacebook.localdomain>
Date: Thu, 4 Apr 2024 00:24:54 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Colin Foster <colin.foster@...advantage.com>
Cc: Mark Brown <broonie@...nel.org>,
	Amit Kumar Mahapatra <amit.kumar-mahapatra@....com>,
	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: 6.8 SPI Chip Select Regression

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@...00000/segment@...arget-module@...00/spi@...oc@0
> > > [    3.477495] spi_master spi0: Failed to create SPI device for /ocp/interconnect@...00000/segment@...arget-module@...00/spi@...oc@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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ