From: "Pete Batard" <pete@akeo.ie>
To: Leif Lindholm <leif.lindholm@linaro.org>
Cc: devel@edk2.groups.io, ard.biesheuvel@linaro.org
Subject: Re: [edk2-platforms][PATCH v2 2/5] Platform/RPi3/RpiFirmwareDxe: Improve serial number population
Date: Thu, 10 Oct 2019 13:41:20 +0100 [thread overview]
Message-ID: <766e6b6f-d788-e46e-e58f-84a2f851645c@akeo.ie> (raw)
In-Reply-To: <20191010084344.GT25504@bivouac.eciton.net>
Hi Leif,
It's a disagreement. And the same goes for 3/5 & 4/5. Please see the
note I wrote in 0/5 for the v2, because the cover letter this is usually
the place I try to clarify elements that may throw off a maintainer, and
that don't belong in a commit message.
Not so sound flippant here, but as long as there isn't an MTV award for
"Most atomic codebase ever", I just don't have the time to split what I
consider to be frivolous commits. The reasoning behind that is that I
realistically don't consider that people are actually going to be thrown
off by a "while I was here I also fixed an obvious typo" that got added
into an existing commit or, most important, that even if they do, the
amount of time that is going to be collectively wasted by people who
might be thrown of by not having uber atomicity is not going to exceed
the amount of time it will cost *me* to split it.
Therefore, while I do understand the desire to have an atomic commit
history, I'm afraid that if we can't strike a balance between how much
extra time contributors are expected to waste vs how atomic a
*real-life* codebase is enforced to be, if I have to split every little
typo and stylistic fix into yet another commit, I'm simply not going to
bother fixing typos or low hanging fruits I see any more.
Regards,
/Pete
On 2019.10.10 09:43, Leif Lindholm wrote:
> On Tue, Oct 08, 2019 at 01:38:38PM +0100, Pete Batard wrote:
>> Improve RpiFirmwareGetSerial() to derive a serial number from the
>> MAC address, in case the platform returns 0 for the serial number.
>>
>> Also fix a typo where "%s" was used instead of "%a".
>
> I did not see a reply to my feedback on the previous round, so I'm
> unsure if this is a mistake or a disagreement?
>
>> Signed-off-by: Pete Batard <pete@akeo.ie>
>> ---
>> Platform/RaspberryPi/RPi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/Platform/RaspberryPi/RPi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c b/Platform/RaspberryPi/RPi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
>> index 378c99bcba05..c2344252d2c0 100644
>> --- a/Platform/RaspberryPi/RPi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
>> +++ b/Platform/RaspberryPi/RPi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
>> @@ -219,7 +219,7 @@ RpiFirmwareSetPowerState (
>>
>> if (!EFI_ERROR (Status) &&
>> PowerState ^ (Cmd->TagBody.PowerState & RPI_MBOX_POWER_STATE_ENABLE)) {
>> - DEBUG ((DEBUG_ERROR, "%a: failed to %sable power for device %d\n",
>> + DEBUG ((DEBUG_ERROR, "%a: failed to %aable power for device %d\n",
>
> This is clearly a bugfix, but I don't see it as being part of "Improve
> serial number population", which is what it claims to be if I view it
> wih git blame.
>
> /
> Leif
>
>> __FUNCTION__, PowerState ? "en" : "dis", DeviceId));
>> Status = EFI_DEVICE_ERROR;
>> }
>> @@ -393,7 +393,14 @@ RpiFirmwareGetSerial (
>> }
>>
>> *Serial = Cmd->TagBody.Serial;
>> - return EFI_SUCCESS;
>> + // Some platforms return 0 for serial. For those, try to use the MAC address.
>> + if (*Serial == 0) {
>> + Status = RpiFirmwareGetMacAddress ((UINT8*) Serial);
>> + // Convert to a more user-friendly value
>> + *Serial = SwapBytes64 (*Serial << 16);
>> + }
>> +
>> + return Status;
>> }
>>
>> #pragma pack()
>> --
>> 2.21.0.windows.1
>>
next prev parent reply other threads:[~2019-10-10 12:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 12:38 [edk2-platforms][PATCH v2 0/5] Platform/RPi3: Various SMBIOS improvements Pete Batard
2019-10-08 12:38 ` [edk2-platforms][PATCH v2 1/5] Platform/RPi3/RpiFirmwareDxe: Add more query functions Pete Batard
2019-10-10 8:39 ` Leif Lindholm
2019-10-10 12:41 ` Pete Batard
2019-10-10 16:43 ` Leif Lindholm
2019-10-10 17:27 ` Pete Batard
2019-10-08 12:38 ` [edk2-platforms][PATCH v2 2/5] Platform/RPi3/RpiFirmwareDxe: Improve serial number population Pete Batard
2019-10-10 8:43 ` Leif Lindholm
2019-10-10 12:41 ` Pete Batard [this message]
2019-10-10 16:49 ` Leif Lindholm
2019-10-10 17:28 ` Pete Batard
2019-10-08 12:38 ` [edk2-platforms][PATCH v2 3/5] Platform/RPi3/PlatformSmbiosDxe: Improve population of SMBIOS entries Pete Batard
2019-10-10 8:59 ` Leif Lindholm
2019-10-08 12:38 ` [edk2-platforms][PATCH v2 4/5] Platform/RPi3/PlatformSmbiosDxe: Populate BIOS major/minor from PCD Pete Batard
2019-10-10 9:01 ` Leif Lindholm
2019-10-08 12:38 ` [edk2-platforms][PATCH v2 5/5] Platform/RPi3/PlatformSmbiosDxe: Derive RAM size from board revision Pete Batard
2019-10-10 9:03 ` Leif Lindholm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=766e6b6f-d788-e46e-e58f-84a2f851645c@akeo.ie \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox