linux-kernel - Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers

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: <20150424200326.GA14443@datacom.ind.br>
Date:	Fri, 24 Apr 2015 17:03:26 -0300
From:	Jonatas Rech <jonatas.rech@...acom.ind.br>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers

On Fri, Apr 24, 2015 at 07:17:45PM +0100, Mark Brown wrote:
> On Thu, Apr 23, 2015 at 03:06:22PM -0300, Jonatas Rech wrote:
> 
> > I agree, but please note that this came up while I was trying to fix the
> > full-duplex functionality, and it's a different problem. Fixing this would
> > impact protocol drivers, as stated earlier. It would take some time for me to
> > study other drivers and come up with the best solution for this driver plus
> > (at least) the m25p80, which supports the hardware I currently have access to.
> 
> > I know this must be fixed, but wouldn't it be subject to a different patch?
> > Thanks in advance for the advice.
> 
> The commit message says "this correction has exposed an inconsistency"
> which suggests that the problem was masked before this fix.  Did you
> mean to say that while fixing this you noticed a separate bug that's
> present anyway?

Exactly. Besides fixing the full-duplex capability I reorganized things
inside the main loop so that anybody can spot where the extra bytes are
being sent, but the code works just the same as before in that respect.

My guess is that, appart from memory chips, most SPI devices are
accessed with short transfers, and since this only arises when one wants
to read/write more than 64KiB at once, it has remained unnoticed. So, as
long as flash memories work with this driver (and they do, because of
the bug), there won't be the need for it to be fixed. Apparently it was
implemented this way on purpose by the original author.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/