[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1719d289-ae1a-708e-ffd7-889007465b4e@broadcom.com>
Date: Fri, 6 Jan 2023 19:57:15 -0800
From: William Zhang <william.zhang@...adcom.com>
To: Mark Brown <broonie@...nel.org>
Cc: Linux SPI List <linux-spi@...r.kernel.org>,
Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>,
anand.gore@...adcom.com, tomer.yacoby@...adcom.com,
dan.beygelman@...adcom.com, joel.peshkin@...adcom.com,
f.fainelli@...il.com, jonas.gorski@...il.com,
kursad.oney@...adcom.com, dregan@...l.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 14/16] spi: bcm63xx-hsspi: prepend: Disable spi mem dual
io read op support
On 01/06/2023 02:07 PM, Mark Brown wrote:
> On Fri, Jan 06, 2023 at 12:08:06PM -0800, William Zhang wrote:
>> In general the controller supports SPI dual mode operation but the
>> particular SPI flash dual io read op switches from single mode in cmd
>> phase to dual mode in address and data phase. This is not compatible
>> with prepend operation where cmd and address are sent out through the
>> prepend buffer and they must use same the number of io pins.
>>
>> This patch disables these SPI flash dual io read ops through the mem_ops
>> supports_op interface when prepend mode is used. This makes sure the SPI
>> flash driver selects the compatible read ops at run time.
>
> This suggests that your prepend mode is attempting to combine
> incompatible transfers doesn't it? Presumably other devices could
> generate similar access patterns...
>
As far as I can see, only spi mem op has such pattern but agree it is
possible that other device can generate such usage. I can add a check
for this condition(all the prepend data must use same io width) so error
can be printed and user can switch to dummy cs workaround.
Thank you for your feedbacks so far and have a nice weekend!
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4212 bytes)
Powered by blists - more mailing lists