From: "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
To: Trent Piepho <tpiepho@kymetacorp.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>,
"abbotti@mev.co.uk" <abbotti@mev.co.uk>
Subject: Re: Problem loading environment from spi-nor flash partition since barebox 2017.01.0
Date: Mon, 16 Jan 2017 08:13:41 +0100 [thread overview]
Message-ID: <20170116071341.vvp5cmdv66qsnx3a@pengutronix.de> (raw)
In-Reply-To: <1484329660.30810.68.camel@kymetacorp.com>
On Fri, Jan 13, 2017 at 05:46:41PM +0000, Trent Piepho wrote:
> On Wed, 2017-01-11 at 09:32 +0100, Sascha Hauer wrote:
> > With (real) SPI this is a little different and works as expected: If the
> > qspi node would be handled by the SPI layer then the SPI core would
> > register the child nodes as devices on a SPI bus. The normal probe
> > mechanism would then bind the device and the driver together.
> >
> > With the cadence-quadspi driver a device is registered in
> > cqspi_setup_flash(), but there is never a driver attached to it, thus
> > the dev->driver test fails.
> >
> > The proper way if probably to register the n25q00 device on a qspi bus
> > and to provide a qspi-nor-flash driver which gets probed then.
> > The not-so-proper, faster way could be to just create a dummy driver
> > struct and attach it to the device allocated in cqspi_setup_flash().
>
> The qspi device is more like an MTD device than a SPI master. It just
> supports memory devices, not arbitrary SPI slaves that have their own
> drivers.
>
> But that said, there is sort of a driver for the SPI NOR chips attached
> to the qspi in spi-nor.c, but it is not a real 'struct driver_d' driver.
> Maybe it could be?
>
> qspi could create a "qspi" or "spi-flash" bus (I don't think it will fit
> well as a generic SPI bus) with the flash devices on it, and then
> spi-nor could bind to them like a normal driver.
Yes, that was what I tried to express in my mail.
>
> Or spi-nor could have a driver_d that's not registered and make
> nor->dev->driver point to it in spi_nor_scan().
Yes.
>
> Or spi_nor_scan() could just set nor->dev->driver =
> nor->dev->parent->driver.
Probably not a good idea. I looks wrong.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2017-01-16 7:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 16:01 Ian Abbott
2017-01-10 19:42 ` Trent Piepho
2017-01-11 11:37 ` Ian Abbott
2017-01-11 8:32 ` Sascha Hauer
2017-01-11 13:02 ` Ian Abbott
2017-01-13 17:46 ` Trent Piepho
2017-01-16 7:13 ` s.hauer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170116071341.vvp5cmdv66qsnx3a@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=abbotti@mev.co.uk \
--cc=barebox@lists.infradead.org \
--cc=tpiepho@kymetacorp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox