<rfs613>
commit 2564fce7eea added "config SPL_ARMV7_SET_CORTEX_SMPEN" to arch/arm/cpu/armv7/Kconfig
<rfs613>
I'd like to use this for non-SPL, so I have to add "config ARMV7_SET_CORTEX_SMPEN" (eg. without the SPL_ prefix)
<rfs613>
should I also add a TPL version while I am there? what is the general practise for this?
mckoan is now known as mckoan|away
<marex>
rfs613: why ?
<rfs613>
marex: so that #if CONFIG_IS_ENABLED(ARMV7_SET_CORTEX_SMPEN) works in non-SPL
<rfs613>
it took me a few minutes to figure out why simply adding "select ARMV7_SET_CORTEX_SMPEN" did not have any effect
<Tartarus>
You shouldn't add a TPL variant unless you really need it
<Tartarus>
And then yes, if it makes sense to have as an option in full u-boot add it
<rfs613>
i figured I'd save the next person the hassle of working this out
<Tartarus>
and CONFIG_IS_ENABLED(FOO) evaluates correctly for main/SPL/TPL
<Tartarus>
Well, it also comes down to if it makes sense to do something, at that stage
<Tartarus>
TPL is for the "oh this is such a constrained environment I can't een load our regular constrained environment loader directly"
<rfs613>
I don't use TPL currently, but for this particular symbol, it controls a setting that must be done "before any cache or TLB maintenance operations are performed"
<rfs613>
ok, I'll send patch just for u-boot, not TPL. Gives me a chance to practise my patman skills ;-)
<marex>
rfs613: dont you use SPL on your board anyway ?
<rfs613>
marex: nope, we do not use SPL on this particular board.
<rfs613>
the BootROM loads u-boot directly into on-chip SRAM and jumps to it.
<rfs613>
it's RZ/N1 by the way ;-)
<vagrantc>
i get why it's important to have submission guidelines, but whenever i submit a spelling correction, which is often a 2-3 character patch ... it seems silly to add a description which is a duplicate and to have to submit a v2 for that ... (only to get the v2 slightly wrong still)
<vagrantc>
could the submission guidelines make an exception for cases like spelling or other typos?
<vagrantc>
and for whatever reason, the prefixes people ask me to use are at odds with what patman complains about
<cambrian_invader>
IMO patman's tags are not useful
<cambrian_invader>
presumably Simon likes them
<rfs613>
vagrantc: in your first version of the kwboot.1 spelling fix, you have the Signed-off-by as the first line of the commit message.
<rfs613>
when someone views the git history, this will be what they see for the description of the commit.
<rfs613>
we would rather see something that helps localize the change (so that when skimming quickly, I can rule out things that are not relevant)
<rfs613>
hence the first line should be "tools: kwboot: fix spelling mistake" for example
<rfs613>
then a blank line, then your Signed-off-by.
<Tartarus>
vagrantc: I don't see a trivial spelling exception in the linux kernel process, which we generally mirror.
<vagrantc>
marex: oooh. i think i will stop using patman then :)
<cambrian_invader>
a lot of times I will run `for patch in *.patch; do echo $(tput bold)$patch$(tput sgr0); scripts/get_maintainer.pl $patch; done`
<vagrantc>
feels easier to just compose the stuff in my email, and then i can more easily sign it too, fwiw
<cambrian_invader>
which lets me pick out the appropriate people
<marex>
vagrantc: git commit -s ?
<vagrantc>
heh. guess i've never used git-format-patch/send-email/etc with signed commits
<rfs613>
vagrantc: -s just adds the Signed-off-by to the commit message
<rfs613>
it saves you the step of doing it manually (and making silly typo in your name/email...)
<rfs613>
not that I would ever have done that ;-)
<marex>
Sighed-off-by
<vagrantc>
singed-off-by
<vagrantc>
well, this'll improve my workflow for trivial submissions :)
<mps>
heh, nowadays mostly using these web interfaces I forgot how to use git send-email
<marex>
heh
<marex>
mps: github and gitlab code review is attrocious
<marex>
try to comment on commit message ... not possible
<mps>
marex: I agree heartily
<marex>
try to review "v2" or "v3" ? context from previous changes or previous comments is strangely disappearing and it is real hard to compare patch revisions
<marex>
that is what really does make me very unhappy about gitlab workflow
<marex>
it becomes utter chaos at v3 onward
<marex>
oh ... and the
<mps>
for gitlab I only learned 'git push --force ...'
<marex>
"did you actually look at the patch ? I pushed new version" ... gitlab does not show that
<rfs613>
marex: I agree with you, but we now have a full generatio of developers who grew up on PRs and the associated "bad" UI
<marex>
it just frob and hides and unhides random comments, but not "hey, patch has changed" notification
<marex>
should I even mention Gerrit ?
<rfs613>
gerrit feels like bugzilla - the old tool that isn't cool anymore, but was actually better in functionailty than the modern shiny repacements (*cough* JIRA)
prabhakarlad has joined #u-boot
torez has quit [Ping timeout: 250 seconds]
torez has joined #u-boot
<marex>
uh
<cambrian_invader>
I've found gerrit's ux to be pretty good
<marex>
cambrian_invader: gerrit2 or gerrit3 ?
<cambrian_invader>
3
beanbag- has left #u-boot [Leaving]
machinehum has quit [Read error: Connection reset by peer]
machinehum has joined #u-boot
torez has quit [Remote host closed the connection]
littlebobeep has joined #u-boot
sbach has quit [Read error: Connection reset by peer]