Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

If sphinx not found, make recipe will fail and it will throw error.
Hence CI will also fail.

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Resolve "Make the root makefile uniform with other projects"

Closes #10

See merge request be-cem-edl/fec/hardware-modules/fmc!5

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Resolve "Use fec-build-sw to build FMC"

Closes #9

See merge request be-cem-edl/fec/hardware-modules/fmc!4

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

The targets were explicitly listed and had separate make commands for
each of the directories which could be combined into one. Putting the
directories in a common variable will also help to implement 'flawfinder'
and 'cppcheck' at later stages.

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Resolve "at24 module should be loaded before FMC probe"

Closes #8

See merge request be-cem-edl/fec/hardware-modules/fmc!3

In cases where driver modules are not built into the kernel itself, at24
module is not loaded at the desired time, and thus, can cause error when
trying to read the eeprom.

Also, listing at24 as a soft dependency doesn't solves our problem as it
does not guarantees the time at which the module will be loaded.

Hence, load the module using request_module(), and throw a kernel warning
in syslog if it fails.

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

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

Resolve "fix documentation"

Closes #2

See merge request be-cem-edl/fec/hardware-modules/fmc!2

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

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

Resolve "Review Vaibhav Patches"

Closes #1

See merge request be-cem-edl/fec/hardware-modules/fmc!1

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

On error, set the slot->nvmem to NULL. This keeps the data structure in
line with the real status (the nvmem device was not found).

Reported by: Federico Vaga <federico.vaga@cern.ch>
Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

With nvmem framework, the reference counter of the nvmem device is
increased when we ask the device from the kernel via helper functions
like "nvmem_device_find()", "nvmem_device_get()", etc. If reference
count is zero, the driver can be unloaded (rmmod) during ongoing
operations.

Thus, the reference count should be incremented during add, and
decremented during delete.

Reported-by: Federico Vaga <federico.vaga@cern.ch>
Signed-off-by: Vaibhav Gupta <vaibhav.gupta@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>

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

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

To use "nvmem_device_get()" we need to find correct name of our nvmem
device, which is a very complex job than it seems.

The way nvmem-consumer framework is designed, we only have the info
about the parent device which is handled by i2c. Thus, there is no
non-hackish way we can get the name of our nvmem-device.

One pattern which is helpful is that the nvmem framework names its
devices by just appending an id to the name of the parent device. So,
if the parent device is "2-0050", the nvmem device will be 2-005<id>.

The silver lining in our case is that as per FMC standard, we have only
one eeprom/nvmem device per i2c handler. Thus, we just need to check
that out of all nvmem devices, which one contains the name of our
i2c handler.

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

nvmem_device_get() may return an error pointed instead of NULL, thus
check for it.

Picked from the changes done by Mathis Marion for Oscimp-WRTD project.

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Update APIs wherever needed to supposrt linux v5.10.65 as well.

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>