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>

* 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

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>

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>

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>

Now we read the whole eeprom area with a single command. Reading
time is thus 1/3 of what it was, and initialization time goes
down from 2 seconds to 0.6 seconds.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

fmc-bus is now fixed WRT the dev->release(). Now devices are correctly
released when their use count reaches zero. Thus, we can't release them
ourselves.

This commit picks the new fmc-bus and adapts th own releae method.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

When using the SPEC as White Rabbit grandmaster, you need to feed it
with 10MHz, which would kill the computer with an interrupt flood.

DIO interrupts are now disabled if they consume more than 80% of the
total time, which usually triggers between 100kHz and 200kHz. Network
interrupts are not affected.

Thanks to Anders Wallin for reporting the problem and helping in the
diagnosis.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This is a long-standing bug, and completely my fault.  Since our i2c
is simply a bitbanging gpio-based interface, I need to add some delays
into the operations.  Without this, accessing eeprom worked with most
mezzanines but not with all of them. The measured speed was more than 1MHz.

The devices are rated at 400kHz, so delay 1.25 usecs at each output
operation (thus, writing is three such delay for each bit).  Addin the
unpredictable software delays I see slightly more than than 200kHz
in my test system.

The driver now takes 2.5s to read the whole eeprom, but there's ample
space to make it better by fixing the FIXME in spec-i2c.c .
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

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

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

NetworkManager tries to access the phy, so this WARN_ON is
pretty common if the daemon is running. Now we know who is
misbehaving, and the driver can keep silent (disclaimer: this
opinionated message is by Alessandro :)

When the user passes "gateware=", the code uses a wrong SDB entry
point: "Can't find SDB at address 0x630000" (with one too many zeroes.

Replace typoed constant values with WRN_SDB_ADDR.

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