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
| ||
|
Message-ID: <DM4PR12MB5769823E40D7F2C15F8C2012C3879@DM4PR12MB5769.namprd12.prod.outlook.com> Date: Thu, 23 Mar 2023 11:57:55 +0000 From: Krishna Yarlagadda <kyarlagadda@...dia.com> To: Hillf Danton <hdanton@...a.com> CC: "robh+dt@...nel.org" <robh+dt@...nel.org>, "broonie@...nel.org" <broonie@...nel.org>, "peterhuewe@....de" <peterhuewe@....de>, "jgg@...pe.ca" <jgg@...pe.ca>, "jarkko@...nel.org" <jarkko@...nel.org>, "krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: RE: [Patch V8 2/3] tpm_tis-spi: Add hardware wait polling > -----Original Message----- > From: Hillf Danton <hdanton@...a.com> > Sent: 19 March 2023 19:58 > To: Krishna Yarlagadda <kyarlagadda@...dia.com> > Cc: robh+dt@...nel.org; broonie@...nel.org; peterhuewe@....de; > jgg@...pe.ca; jarkko@...nel.org; krzysztof.kozlowski+dt@...aro.org; linux- > kernel@...r.kernel.org > Subject: Re: [Patch V8 2/3] tpm_tis-spi: Add hardware wait polling > > External email: Use caution opening links or attachments > > > On 2 Mar 2023 09:48:03 +0530 Krishna Yarlagadda <kyarlagadda@...dia.com> > > +static int tpm_tis_spi_hw_flow_transfer(struct tpm_tis_data *data, > > + u32 addr, u16 len, u8 *in, > > + const u8 *out) > > +{ > > + struct tpm_tis_spi_phy *phy = to_tpm_tis_spi_phy(data); > > + struct spi_transfer spi_xfer[3]; > > + struct spi_message m; > > + u8 transfer_len; > > + int ret; > > + > > + while (len) { > > + transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE); > > + > > + spi_message_init(&m); > > + phy->iobuf[0] = (in ? 0x80 : 0) | (transfer_len - 1); > > + phy->iobuf[1] = 0xd4; > > + phy->iobuf[2] = addr >> 8; > > + phy->iobuf[3] = addr; > > + > > + memset(&spi_xfer, 0, sizeof(spi_xfer)); > > + > > + spi_xfer[0].tx_buf = phy->iobuf; > > + spi_xfer[0].len = 1; > > + spi_message_add_tail(&spi_xfer[0], &m); > > + > > + spi_xfer[1].tx_buf = phy->iobuf + 1; > > + spi_xfer[1].len = 3; > > + spi_message_add_tail(&spi_xfer[1], &m); > > + > > + if (out) { > > + spi_xfer[2].tx_buf = &phy->iobuf[4]; > > + spi_xfer[2].rx_buf = NULL; > > + memcpy(&phy->iobuf[4], out, transfer_len); > > + out += transfer_len; > > + } > > + > > + if (in) { > > + spi_xfer[2].tx_buf = NULL; > > + spi_xfer[2].rx_buf = &phy->iobuf[4]; > > + } > > + > > + spi_xfer[2].len = transfer_len; > > + spi_message_add_tail(&spi_xfer[2], &m); > > + > > + reinit_completion(&phy->ready); > > What breaks without reinit? Or what sense made by init-ing it again? When length is over frame size, this loop will run for more than one iterations. Reinit to start transfer again. KY > > + > > + ret = spi_sync_locked(phy->spi_device, &m); > > + if (ret < 0) > > + return ret; > > + > > + if (in) { > > + memcpy(in, &phy->iobuf[4], transfer_len); > > + in += transfer_len; > > + } > > + > > + len -= transfer_len; > > + } > > + > > + return ret; > > +}
Powered by blists - more mailing lists