Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

When possible, avoid statement-scope variable for a better maintanability
of the code.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

If there are no reasons for a *_free() function to return an error, change
the return type to void
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The irq_lock is a SVEC spinlock, but we must protect VIC variables. In order
to make the VIC code independent, use a dedicated VIC spinlock
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Make the VIC code indipendently as much as possible
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Use the specular name: we used init, we should use exit
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

On spec driver remove, do not clean-up VIC stuff. The VIC should be cleaned
by the mezzanine driver when it release all its handlers (see patch a628fa3).
Just leave a reminder for driver developer when something goes wrong.

Moreove, we do not need to user sver_irq_exit() any more. If the mezzanine
driver is properly written it will clear all its interrupts, and thanks to
patch a628fa3 we can safely assume that everything was cleared.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Interrupt resources are not properly released. Mainly two problems:

  1. on IRQ free the driver was using the IRQ number instead of the the
     component base address. So, the component IRQ handlers were never
     released

  2. on IRQ free, supposing that the first problem was not there, when
     all component's IRQ handlers were released the PCI IRQ handler (VIC
     dispatcher) should have released, but it was not. In consequence of this
     even if the driver was removed an interrupt can be handled by a
     ghost handler.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The patch 355e1019 move two fields in the spec_dev structure, but other
drivers may include this header and use this structure, so it breakes
all the fields's offset.

Revert this modification in order to make the modification more backward
compatible. It will not fix all the situations (sizeof) but some of them
yes.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The driver was not setting HAS_GOLDEN/HAS_CUSTOM flags when changing gatewares. This made
EEPROM reprogramming impossible as the svec_[read|write]_ee functions thought that golden bitstream
is never loaded.

This patch allows to load an userspace-provided bitstream to a SVEC card through sysfs attributes.
It does not rely on kernel firmware loader mechanism (so the gateware files are not restricted
to /lib/firmware directory). Userspace communication is ensured through firmware_blob and firmware_cmd
sysfs entries. The former inputs the bitstream in PAGESIZEd chunks, the latter receives gateware update start/finish commands.

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The kbuild environment writes into 'obj' the path to the output directory
automatically. This avoid us to specify 'M'
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

This lets us use the driver without re-declaring every SVEC in the CCDB to have window size of 0x80000.

kernel: prevent creating an A24 window at 0xf00000 (Tsi148 uses same address range for its internal regs)

Conflicts:
	kernel/svec-sysfs.c

Previous size of 0x100000 allowed for up to 16 cards configured in A24. We have some crates with more than 16 slots.

The new vme_addr sysfs attribute had incorrect validation:
it was the old value stored in the card structure who was
validated by mistake. Moreover, the vme_addr is an offset,
so it has to be compared with the configured size, not
the end of the (absolute) vme address range of the board.