Re: [PATCH V5 0/4] arm64: dts: freescale: Add chargebyte Charge Control Y

From: Frank Li

Date: Fri Oct 02 2026 - 12:07:57 EST


On Fri, Oct 02, 2026 at 05:31:23PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 23.09.26 um 11:19 schrieb Stefan Wahren:
> > Hi Frank,
> > hi Vinod,
> >
> > Am 21.09.26 um 16:46 schrieb Frank Li:
> > > On Mon, Sep 21, 2026 at 03:09:23PM +0200, Stefan Wahren wrote:
> > > > Hi Frank,
> > > >
> > > > Am 07.09.26 um 17:04 schrieb Stefan Wahren:
> > > > > This series adds support for the chargebyte Charge Control Y, which is
> > > > > an Electrical Vehicle Supply Equipment (EVSE) for MCS (Megawatt
> > > > > Charging System) charging stations.
> > > > >
> > > > > sashiko reported in the first version of the series [1] that
> > > > > X_nRST_LAN
> > > > > is available via GPIO line names, but there is no reset
> > > > > mechanismn in the
> > > > > device tree. This finding is valid. Since the reset line feature isn't
> > > > > implemented for LAN8651 driver yet, I like to proceed with the current
> > > > > version. The LAN8651 handles reset via SPI commands and in rare cases
> > > > > we still have the possibility to control the reset from userspace.
> > > > > Btw the pin has a pull resistor in hardware, so it's not floating.
> > > > >
> > > > > sashiko complained in the fourth version of the series [2] about the
> > > > > reset polarity of ethphy2 and the different drive strength across the
> > > > > data lines. Both is intended.
> > > > >
> > > > > [1] - https://lore.kernel.org/linux-devicetree/20260818093147.E556C1F000E9@xxxxxxxxxxxxxxx/
> > > > > [2] - https://lore.kernel.org/linux-devicetree/20260903082122.A777C1F000E9@xxxxxxxxxxxxxxx/
> > > > >
> > > > > Changes in V5:
> > > > > - fix delete-node for pinctrl_leds (reported by sashiko)
> > > > > - add Krzysztof's Reviewed-by
> > > > I didn't received any feedback for V5 yet. Do you have any
> > > > comments or could
> > > > it be merged?
> > > Wait for vinod pick phy binding part.
> > @Vinod are you fine with both PHY bindings?
> >
> > @Frank I noticed that this patch has a conflict with the Makefile in
> > linux-next. Should I rebase or do you resolve the conflict?
> would it be better if I rebase now and send a V6, I concerned that this
> misses the cycle.

Vinod missed pickup one of binding patch.

Frank

>
> Best regards
> >
> > Best regards
> > >
> > > Frank
> > >
> > > > Best regards
> > > >
> >
>