Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Protecting the handlers' vector is not enough. Managing the interrupts
involves other tasks that must be serialized. Mainly to handle the first
request and the last free of a VIC handler.

The VIC internal locking (vec_lock) is not useful anymore, but I do not
remove it because theoretically the VIC should be an independent bunch of
code.

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 spec->irq_lock is a SPEC 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>

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 f7ee35460).
Just leave a reminder for driver developer when something goes wrong.

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>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

The main reason to introduce this EXTRACFLAGS variable is to allow people
to cross compile on x86 architectures over 32bits and 64bits

    make EXTRACFLAGS="-m32"
    make EXTRACFLAGS="-m64"

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

The Kbuild writesin 'src' the correct path to the source code automatically.
This avoid us to explicitly write 'M' variable

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Benoit Rat authored 11 years ago and Alessandro Rubini committed 11 years ago

* D/d,0,1 modes can not be used by the first channel (ch0)
* C/c mode is only useful for the last channel (ch4)

* wr-pps can not be used for channel 0

Benoit Rat authored 11 years ago and Alessandro Rubini committed 11 years ago

This also updates the links to binaries in the documentation.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

- Remove only for write in #72557df7
- NetworkManger (Unbuntu LTS 12.04) insists on accessing to the phy
when it is used from LM32 and flood the dmesg so we remove the warning.

This also documents how to write the eeprom, using the new writable
file in sysfs.  A working image for the eeprom is included, for people
with devices that were not programmed by the manufacturer.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Theodor-Adrian Stana authored 11 years ago and Alessandro Rubini committed 11 years ago

This is needed so the gennum core (as opposed to the gennum chip)
can access the SPI flash from the newly-programmed fpga image.
With this gpio setting, both the lm32 from inside the fpga
and the host computer can read and write the flash device.

Signed-off-by: Theodor Stana <t.stana@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

Now we can properly have spec.ko drive a carrier with no mezzanine.
We can then use tools/spec-fwloader and do other mezzanine-independent
things.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The device is master-enabled at boot time, but the disable_device()
at remove time clears it. pci_enable_device() doesn't re-enable, so
we need to also pci_set_master().

Otherwise DMA works at first load, and the machine freezes at second load.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Juan David González Cobas authored 11 years ago and Alessandro Rubini committed 11 years ago

For traceability purposes, we include commit descriptions
as MODULE_VERSION information in drivers that are deployed
in CERN control system.

Ideally, the commit description should be added to all the
binary blobs installed, but the kernel module is critical
in this connection, as it is crucial to trace back quickly
the whereabouts of installed .ko sources.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The module parameter eeprom=  accepts a list of filenames (looked for
in /lib/firmware) to fake eeprom images. The list is in probe order,
which means it is unpredictable if you have more than one spec card
plugged -- but it's the same every time your reload the module.

This is a tool for developers who want to experiment with eeproms, so
this "rude" approach to multi-card setups is not considered an issue.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>