[PATCH 0/3] fpga: Remove lattice and ACEX1 support

[Alexander Dahl]

Hello Tom,

Am Fri, Jul 25, 2025 at 08:00:35AM -0600 schrieb Tom Rini:
> On Fri, Jul 25, 2025 at 02:03:12PM +0200, Michal Simek wrote:
> > 
> > 
> > On 7/25/25 14:00, Alexander Dahl wrote:
> > > Hello Michal,
> > > 
> > > Am Fri, Jul 25, 2025 at 01:25:51PM +0200 schrieb Michal Simek:
> > > > Hi,
> > > > 
> > > > when fpga drivers were enabled via sandbox some coverity issues came and
> > > > make no sense to fix them when there is no user of these drivers that's why
> > > > it is easier just remove them completely.
> > > > 
> > > > Another candidate for removal is FPGA_CYCLON2 which is enabled only by
> > > > mx53cx9020_defconfig.
> > > 
> > > We use FPGA_CYCLON2 downstream with devices containing Altera Cyclone
> > > III and IV or Efinix Trion T20 chips.  These are _not_ legacy devices,
> > > few quantities per year, but still produced and sold.
> > > 
> > > If you need board code to keep the upstream support, I would need
> > > to talk to some people here if we can upstream our board code, or at
> > > least some of it.  That might be difficult though, so if there are
> > > alternatives, please advise.  O:-)
> > 
> > CYCLON2 is enabled in one board that's why it is fine until that board is around.
> 
> Heck, we can just leave it on for sandbox *but* that does mean someone
> needs to step up to maintain the driver part. The report is at
> https://lore.kernel.org/u-boot/20250725132645.GA1807455@bill-the-cat/
> and it's that there's some dead code. 

I can look into that report and at the generic fpga code, or at least
some of it, maybe next week.

> It's also been not quite 3 years
> since the last "real" change made to the driver by you, so are there any
> other general fixes / improvements that should be upstreamed? Thanks!

Just looked into my patch stack again, there are only two things which
are not board code:

1. return value wrapping in cmd/fpga.c which I submitted as a patch
some years ago, was denied back then.

2. a generic dm driver for passive serial configuration over spi.
upstreaming that driver would make sense together with some board code
using it. ;-)

Which means: I sent patches for everything which is not board code,
and most of them were accepted. :-)

Greets
Alex