[PATCH 0/7] realtek: add HPE 1920 support

Sander Vanheule sander at svanheule.net
Thu Jul 28 08:11:00 PDT 2022



On Thu, 2022-07-28 at 16:51 +0200, Daniel Golle wrote:
> On Thu, Jul 28, 2022 at 03:27:14PM +0200, Sander Vanheule wrote:
> > On Thu, 2022-07-28 at 15:10 +0200, Jan Hoffmann wrote:
> > > > This adds support for three switches from the HPE 1920 series. It has
> > > > been tested on HPE 1920-8G and HPE 1920-16G. Support for HPE 1920-24G
> > > > is also included, as it uses the same board as the 16-port model.
> > > > 
> > > > The patch series depends on the firmware-utils patch adding the
> > > > mkh3cimg and mkh3cvfs tools.
> > > 
> > > This patch series has just been merged. However, as mentioned in the 
> > > cover letter, it depends on new tools in firmware-utils. As the 
> > > corresponding patch series ("add tools for H3C devices") hasn't been 
> > > merged yet, this won't actually build.
> > 
> > I've pushed a revert commit to avoid breaking the builds.
> > 
> > Can someone explain why this whole series needed to be merged so quickly? These *7* patches have
> > only been posted on Saturday, and testing was performed for patches 2-4. At least patches 5-7
> > could've remained unmerged awaiting some further comments.
> 
> As 5-7 depend on the actual device for testing they are unlikely to
> receive great amounts of feedback, but are also unlikely to break
> anything.

Well, I started with replying to the firmware-utils changes yesterday. Now those two patches are
merged with still a plethora of errors and warnings from checkpatch.pl, and someone will have to
clean up those files incrementally.

In general, I feel that if anyone thinks patches are good enough without any real  discussion, or is
waiting for changes to be merged, I would strongly prefer that they express this via a public notice
on those patches. At least give people 24h to let you know they still want to review something.

Best,
Sander

> 
> > 
> > > 
> > > Please tell me if I should have made this dependency clearer in any way, 
> > > so I can avoid similar situations in the future.
> > 
> > It was plainly stated in the cover letter, I don't think you could have been any clearer about
> > this
> > dependency.
> 
> Yes, it was absolutely clear and I had it in my local firmware-utils
> tree for which I used CONFIG_SRC_TREE_OVERRIDE.
> The fact that the cover letter doesn't become part of git history was
> part of the reason why I forgot about that before pushing.
> 
> 



More information about the openwrt-devel mailing list