From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 12 Jun 2014 09:29:30 -0600 Subject: [U-Boot] [PATCH] test: dfu: script enhancements In-Reply-To: <20140612115126.3df1808b@amdc2363> References: <1402439290-32731-1-git-send-email-swarren@wwwdotorg.org> <20140612115126.3df1808b@amdc2363> Message-ID: <5399C75A.1080508@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 06/12/2014 03:51 AM, Lukasz Majewski wrote: > Hi Stephen, > >> From: Stephen Warren >> >> Various misc enhancements to dfu_gadget_test.sh: >> >> * After every write (download), perform a write to a different file >> with different data. This ensures that the DFU buffer's content is >> replaced, so that if the read (upload) succeeds, we know that the >> correct data was actually read from the storage device, rather than >> simply being left over in the DFU buffer. This requires two alt >> setting names to be passed to the script, and a dummy data file to >> be generated by dfu_gadget_test_init.sh. >> >> * Fix the assumption that dfu_gadget_test.sh is run from the directory >> that contains it, by cd'ing to that directory before invoking >> ./dfu_gadget_test_init.sh. >> >> * Use $DIR$RCV_DIR consistently, rather than using plain $RCV_DIR in >> some places. >> >> * Add 959, 961 test file sizes, to be consistent with having one >> more than and one less than all the other "round" sizes 64, 128, and >> 4096. >> >> * Remove references to $BKP_DIR from dfu_gadget_test_init.sh, since it >> isn't used. > > Thanks for enhancements Stephen - a lot of issues addressed. > > However, I'm a bit puzzled, since this patch applies on top of patch > which wasn't accepted (yet) to mainline. Yes, I applied your patch locally and worked on top of that. > If Simon who had a minor comments agrees, I would opt for adding the > initial commit with this script to ML: > > http://patchwork.ozlabs.org/patch/355283/ > > And on top apply this one. > Afterwards other comments would be addressed as well. > > I would like to avoid sending many patches for base code which is still > floating on the ML. Unfortunately, code takes so long to get applied that approach isn't very practical. There's no issue working on top of unapplied patches; I'm quite happy to rebase and resend my patch if you need to resend yours and mine no longer applies.