public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Cc: u-boot@lists.denx.de, u-boot-custodians@lists.denx.de
Subject: Re: U-Boot CONFIG_DM_SERIAL migration deadline
Date: Fri, 14 Oct 2022 13:28:37 -0400	[thread overview]
Message-ID: <20221014172837.GC2020586@bill-the-cat> (raw)
In-Reply-To: <CAOf5uwkX4tiinU7LsV4Ze9U27dM5rmGFpkDg8ot49s2Hyk3bYA@mail.gmail.com>

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

On Fri, Oct 14, 2022 at 07:06:21PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi Tom
> 
> On Fri, Oct 14, 2022 at 7:01 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Oct 14, 2022 at 06:58:50PM +0200, Michael Nazzareno Trimarchi wrote:
> > > Hi
> > >
> > > On Fri, Oct 14, 2022 at 5:18 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > Hey all,
> > > >
> > > > I'm sending this email out to the main and custodian lists, and bcc'ing
> > > > all of the listed maintainers for platforms that have a problem here.
> > > > The migration deadline for switching from CONFIG_SERIAL to
> > > > CONFIG_DM_SERIAL is the v2023.04 release. Now, per how I've behaved in
> > > > the past, I'm not going to immediately remove these platforms. But it
> > > > would be very good to jump on migrating them now, rather than waiting
> > > > further. The full list (at least in so far as our Makefile check can
> > > > determine) is:
> > > > SBx81LIFKW SBx81LIFXCAT pogo_e02 pogo_v4 dns325 iconnect d2net_v2
> > > > net2big_v2 inetspace_v2 netspace_lite_v2 netspace_max_v2
> > > > netspace_mini_v2 netspace_v2 dreamplug guruplug openrd_base
> > > > openrd_client openrd_ultimate sheevaplug ib62x0 dockstar goflexhome
> > > > nas220 ds109 nsa310s mx23evk mx28evk imx28_xea imx28_xea_sb
> > > > mx23_olinuxino vexpress_ca9x4 am43xx_evm_qspiboot am43xx_hs_evm_qspi
> > > > ti816x_evm vinco bcm7260 bcm7445 ls1021aiot_qspi ls1021aiot_sdcard
> > > > ls1021aqds_nand ls1021aqds_nor_SECURE_BOOT ls1021aqds_qspi
> > > > ls1021aqds_sdcard_ifc ls1021aqds_sdcard_qspi ls1021atsn_qspi
> > > > ls1021atsn_sdcard ls1021atwr_nor_SECURE_BOOT ls1021atwr_qspi
> > > > ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT
> > > > ls1021atwr_sdcard_qspi mx51evk mx53loco usbarmory m53menlo udoo
> > > > wandboard mx6qsabrelite nitrogen6dl nitrogen6dl2g nitrogen6q
> > > > nitrogen6q2g nitrogen6s nitrogen6s1g imx6dl_mamoj dh_imx6 marsboard
> > > > riotboard imx6dl_icore_nand imx6q_icore_nand imx6qdl_icore_mipi
> > > > imx6qdl_icore_mmc imx6qdl_icore_nand imx6qdl_icore_rqs imx6ul_geam_mmc
> > > > imx6ul_geam_nand imx6ul_isiot_emmc imx6ul_isiot_nand mx6memcal
> > >
> > > We should take care of engicam boards. I will ask jagan if we have all of them
> >
> > As you're the first person to speak up about an i.MX family of boards,
> > this is one of the cases where I really would like to see a solution at
> > the SoC level.  I hope there's not a reason that all imx6* can't just
> > enable DM_SERIAL at this point.  I really want to hope imx* can enable
> > it, but it certainly needs to be sanity tested throughout the families.
> >
> > But yes, starting with moving all of the engicam boards over is better
> > than not moving anything over, and I do understand not everyone is
> > comfortable making wide sweeping changes they can't also test.
> >
> 
> Well, I said that will help with this. I will check it out later. Last
> time on imx8mn,
> We drop few lines of code and rework the code in the board itself. I need to run
> some test

Great, thanks!

-- 
Tom

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

      reply	other threads:[~2022-10-14 17:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14 15:18 U-Boot CONFIG_DM_SERIAL migration deadline Tom Rini
2022-10-14 16:58 ` Michael Nazzareno Trimarchi
2022-10-14 17:01   ` Tom Rini
2022-10-14 17:06     ` Michael Nazzareno Trimarchi
2022-10-14 17:28       ` 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=20221014172837.GC2020586@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=michael@amarulasolutions.com \
    --cc=u-boot-custodians@lists.denx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox