All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kambalin, Sergey" <sergey.kambalin@auriga.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Sergey Kambalin <serg.oker@gmail.com>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] [rpi4b] Make bootable rpi4b model
Date: Mon, 22 May 2023 11:42:38 +0000	[thread overview]
Message-ID: <ea63d09bb2d249b282a429ff9d373e4d@auriga.com> (raw)
In-Reply-To: <CAFEAcA8bLr+_raHie4JxoEJAQ7cuj5nJKTYt5+7r6T0w8FFNsg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

Aw, I thought the entire machine should work at the first patch.

Thank you for the detailed clarification! I think I've got the idea. I'll split it up.

Could you please tell me what size is appropriate for a single patch?

________________________________
От: Peter Maydell <peter.maydell@linaro.org>
Отправлено: 22 мая 2023 г. 13:58:42
Кому: Kambalin, Sergey
Копия: Sergey Kambalin; qemu-arm@nongnu.org; qemu-devel@nongnu.org
Тема: Re: [PATCH] [rpi4b] Make bootable rpi4b model

On Mon, 22 May 2023 at 11:42, Kambalin, Sergey
<sergey.kambalin@auriga.com> wrote:
>
> Hi!
>
> Unfortunately it can't be split without losing a functionality. It is a minimal amount of code to make it able to boot the kernel (and therefore confirm that it works).

No, it absolutely can. Each individual patch should be a
coherent chunk of work, and needs to compile cleanly,
but it doesn't have to be immediately useful on its own.
The usual setup is that a patchseries adding a new board
gradually adds pieces like new devices or bugfixes to
existing code, and it's only in a patch fairly late in the
series that the new board proper is added and enabled.

In a 5 minute scan of this patch I saw at least one cleanup
patch that should be separate (changing hard-coded numbers
in the switch cases in the bcm2835_property.c file). Anything
where you're touching the existing bcm2835/2836 code because
you need to refactor it to be a better base for the bcm2838
work should be a separate patch (this is particularly
important so we can review that the changes don't break the
existing boards). And the usual approach with a new board is
that you have a patch per new device being added (you have
several here) and then a patch at the end for the board changes.
New test cases can be their own patch. Documentation (which
seems to be missing here) can be its own patch.

I would estimate that this will end up being at least 6 patches,
probably more.

thanks
-- PMM

[-- Attachment #2: Type: text/html, Size: 3178 bytes --]

  reply	other threads:[~2023-05-22 11:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22 10:29 [PATCH] [rpi4b] Make bootable rpi4b model Sergey Kambalin
2023-05-22 10:32 ` Peter Maydell
2023-05-22 10:42   ` Kambalin, Sergey
2023-05-22 10:58     ` Peter Maydell
2023-05-22 11:42       ` Kambalin, Sergey [this message]
2023-05-22 12:01         ` Peter Maydell
2023-05-22 12:41           ` Kambalin, Sergey
2023-05-22 13:41             ` Philippe Mathieu-Daudé
2023-05-22 15:21               ` Kambalin, Sergey

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-all 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=ea63d09bb2d249b282a429ff9d373e4d@auriga.com \
    --to=sergey.kambalin@auriga.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=serg.oker@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.