On 27/04/18 17:20, Lukasz Majewski wrote:
Hi Bryan,
Compiling the f_mass_storage driver for an x86 target results in a
compilation error as set_bit and clear_bit are provided by bitops.h
Looking at the provenance of the current u-boot code and the git
change history in the kernel, it looks like we have a local copy of
set_bit and clear_bit as a hold-over from porting the Linux driver
into u-boot.
These days __set_bit and __clear_bit are optionally provided by an
arch and can be used as inputs to generic_bit_set and
generic_bit_clear.
This patch switches over to generic_set_bit and generic_clear_bit to
accommodate.
Tested on i.MX WaRP7 and Intel Edison
Just I'm a bit puzzled:
This is v3 8/9, followed by 9/9 (v1)?
I sent out two previous versions of this patch as a standalone, if you
recall.
And after some time you sent v2 8/9 and v2 9/9.
I suppose that the latter ones are correct?
Also it is very handy to have some kind of change log in patches - i.e.:
Cover letter contains, and I believe best practice is to keep the
changelog in the cover-letter - not the patch itself.
##
V2:
- Fix commit log nds2 -> nds32
- Fix copy/paste error resulting in double colon "arch : : text"
V1:
Following on from a discussion with Marek and Lukasz re: a namespace
collision with set_bit and clear_bit in f_mass_storage, I noticed some
inconsistencies in the definition and usage of PLATFORM__SET_BIT and
PLATFORM__CLEAR_BIT as well as a similar use of __set_bit in the composite
USB gadget driver.
__set_bit is lock-prefixed on x86 whereas set_bit is not and the analog
driver in upstream Linux does set_bit() not __set_bit().
This series addresses all of those inconsistencies.
There are some usages of __set_bit() but those are in SoC specific GPIO
code-paths and therefore don't really need to change IMO.
##
Anyway I'll resend this set as a v3 since Bin Meng needs a change to the
log text anyway.
---
bod
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
