On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
> Disclaimer: I am not familiar with the hardware for which this patch
> adds support.
>
> However, I am familiar m25p80.c and as I understand it the controller
> is basically supposed to implement m25p80.c in hardware when this flag
> is set.
That, to me, sounds like what you have is:
---m25p80 specific interface--->SPI bus--->m25p80 device
Where the m25p80 specific interface does not expose direct access to the
SPI bus?
If that's the case, then maybe you should consider whether using the SPI
bus infrastructure is really the best way forward. Would it make more
sense instead to adopt a different software structure, something more
high-level like:
+-------------------------------------------+
| m25p80 high-level driver |
+----------------------+--------------------+
| SPI m25p80 driver | |
+----------------------+ |
| SPI layer | Special driver |
+----------------------+ |
| SPI bus driver | |
+----------------------+--------------------+
| SPI hardware | Special hardware |
+----------------------+--------------------+
Rather than what you seem to be trying to do, which seems to be:
+----------------------+
| SPI m25p80 driver |
+----------------------+
| SPI layer |
+----------------------+
| Translation driver |
+----------------------+
| Special hardware |
+----------------------+
where this requires M25P80 specific hacks to be introduced into the SPI
layer so that you can communicate additional information between the SPI
M25P80 driver and the translation driver.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
