All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Greg Malysa <greg.malysa@timesys.com>
Cc: u-boot@lists.denx.de, Ian Roberts <ian.roberts@timesys.com>,
	Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Subject: Re: Upcoming Analog Devices SoC Support Submission
Date: Thu, 28 Mar 2024 16:47:37 -0400	[thread overview]
Message-ID: <20240328204737.GG3442575@bill-the-cat> (raw)
In-Reply-To: <CAAjXUar=97omadi8MSLox5V_iCwix+YSUP_fMCGsLhUzUfBpcw@mail.gmail.com>

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

On Mon, Mar 25, 2024 at 10:47:30PM -0400, Greg Malysa wrote:

> Hi Tom,
> 
> I wanted to get a little bit of guidance before dumping some patches
> on the mailing list. I've been preparing to submit support we've
> developed for the Analog Devices SC5xx SoCs including both core SoC
> support and specific device trees and defconfigs for the eval kits
> available from ADI. I've submitted several small patches to touch
> various shared parts of U-Boot that we needed to extend to get this
> hardware running and to get some familiarity with using patman to
> format and submit things, but now I have a roughly 15k line changeset
> consisting of a new mach type and all of the required drivers for the
> system. It's broken down into a bunch of commits: one for the mach
> type support, one per driver we've added, and one per target board
> supported.
> 
> What is the best way to submit this? Ideally I'd love to get feedback
> on individual drivers from the respective subsystem maintainers, but
> it seems rude to have a 20-element patch series that gets resubmitted
> each time feedback comes in for one component. If we break it down
> into separate patches for each piece, what would be the best way to
> ensure that all of the dependencies are merged in order?

Well, I would first make sure that CI passes for your tree. Then, make
sure that you're using OF_UPSTREAM to get your device trees as well.
Then just submit the SoC core + board (and make sure it's using plain
text environment and standard boot and so on), then start with the
additional drivers.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

      reply	other threads:[~2024-03-28 20:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26  2:47 Upcoming Analog Devices SoC Support Submission Greg Malysa
2024-03-28 20:47 ` Tom Rini [this message]

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=20240328204737.GG3442575@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=greg.malysa@timesys.com \
    --cc=ian.roberts@timesys.com \
    --cc=nathan.morrison@timesys.com \
    --cc=u-boot@lists.denx.de \
    /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.