On 15-05-14 12:08 PM, Mark Brown wrote: > On Thu, May 14, 2015 at 11:19:01AM -0700, Scott Branden wrote: >> On 15-05-14 03:31 AM, Mark Brown wrote: > >>> Chip vendors often say this sort of thing and then get surprised by what >>> their users choose to do, and even if it only ever gets used with flash >>> all it would take is some new flash command which can use full duplex >>> for something. Please write the code so it at least tries to handle >>> full duplex operation, if you can't test it fully that's not the end of >>> the world. It doesn't look like it should be particularly difficult. > >> Yes, there is always room for improvements in code. In this case - it >> really is not worth our time to add code we can't test. We try to deliver >> code that we can test and actually works. Yes, if anyone needs to use the > > While I try to not apply code that has obvious problems with silent data > corruption in it which is what we have just now. > >> mspi for full duplex operation code can be added in the future - it is >> software. This block has gone through many generations of our SoCs and has >> only been used for this purpose - the bootROM boots from this SPI only. It >> is dedicated for this purpose. > > All it takes is one hardware engineer who sees a SPI controller and a > GPIO they can use for chip select; I wouldn't be so sure that nobody > ever fixed this up locally (or happened to use a device that only needed > single duplex). > Hi Mark. Would it help if we just set the flags to half duplex using SPI_MASTER_HALF_DUPLEX when we register the master? -- 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
