On 26 Aug 2020, at 20:21, Brandon Bergren <bdra...@freebsd.org> wrote: > On Wed, Aug 26, 2020, at 2:19 PM, Jessica Clarke wrote: >> On 26 Aug 2020, at 20:16, Brandon Bergren <bdra...@imap.cc> wrote: >>> On Tue, Aug 25, 2020, at 9:37 PM, Alan Somers wrote: >>>> Author: asomers >>>> Date: Wed Aug 26 02:37:42 2020 >>>> New Revision: 364799 >>>> URL: https://svnweb.freebsd.org/changeset/base/364799 >>>> >>>> Modified: head/sys/dev/sec/sec.c >>>> ============================================================================== >>>> --- head/sys/dev/sec/sec.c Wed Aug 26 02:13:27 2020 (r364798) >>>> +++ head/sys/dev/sec/sec.c Wed Aug 26 02:37:42 2020 (r364799) >>>> @@ -851,6 +851,9 @@ sec_desc_map_dma(struct sec_softc *sc, struct sec_dma_ >>>> case CRYPTO_BUF_MBUF: >>>> size = m_length(crp->crp_buf.cb_mbuf, NULL); >>>> break; >>>> + case CRYPTO_BUF_VMPAGE: >>>> + size = PAGE_SIZE - cb->cb_vm_page_offset; >>>> + break; >>>> default: >>>> return (EINVAL); >>>> } >>> >>> Uh, where is cb coming from? Shouldn't this be using >>> crp->crp_buf.cb_vm_page_offset? This is causing a build failure on powerpc >>> and powerpcspe. I don't see why other platforms aren't also erroring out >>> here. >> >> Because it's PowerPC-specific: >> >> sys/conf/files.powerpc:dev/sec/sec.c optional sec mpc85xx >> >> Jess >> >> > > No, I mean literally. What scope is cb coming from? It's not a variable that > is in scope for that function as far as I can tell.
Oh no I agree it's wrong and your proposal sounds correct. I was just explaining why it's only noticed in PowerPC builds. Jess _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
