0

I have to read MAC address from EEPROM and set it to the network interface while the interface is initializing.
And I followed the comment from Read EEPROM entry from linux module to read EEPROM through sysfs. But the result is failed.

When I opened the EEPROM file through filp_open(), it always return error pointer with -EACCESS.

struct file *kernel_open(const char *filename, int flags, umode_t mode) {
    struct file *filp = NULL;
    mm_segment_t oldfs = get_fs();
    set_fs(get_ds());
    filp = filp_open(filename, flags, mode);
    set_fs(oldfs);
    return filp;
}

const char *filename = "/sys/bus/i2c/devices/6-0054/eeprom";
struct file filp = kernel_open(filename, O_RDONLY, 0);
if (IS_ERR(filp)) {
    printk(KERN_ERR "Failed to open file (code: %d)\n", PTR_ERR(filp));
    return; <-- always return here and filp value with -13, aka -EACCESS, aka Permission denied
}

Have any ideas?

[Updated]
- Processor: AST2500 (ARMv6)
- Kernel version: 4.19
- EEPROM: at24c64

Richard B. Vannacutt
  • 9
  • 5
  • *Which* EEPROM? On *what* system? Connected *how*??? Does i2c-detect find anything? – Chris Stratton Mar 19 '19 at 18:11
  • @ChrisStratton The EEPROM is at24c64, and my module is running under ARM platform with kernel 4.19. The i2c-detect shows UU on the EEPROM address, in my opinion, it's because the EEPROM driver is dealing with the device. – Richard B. Vannacutt Mar 20 '19 at 01:23
  • "ARM" is not meaningful as a platform, you must be specific: processor, board, distribution, loaded drivers... Also you must document the *wiring* of the eeprom to the the processor. – Chris Stratton Mar 20 '19 at 01:30
  • And you really should be trying this from userspace, first. Also turn on debugging the driver you believe is used, or load it up with your own printk()'s. – Chris Stratton Mar 20 '19 at 01:31
  • @ChrisStratton I am implementing our BMC based on OpenBMC. After I checked /proc/cpuinfo, the processor model shows ARMv6-compatible. Also I read the EEPROM from sysfs in userspace, the result is OK. – Richard B. Vannacutt Mar 20 '19 at 01:45
  • My bad, the processor is AST2500 – Richard B. Vannacutt Mar 20 '19 at 02:07
  • If it works from userspace, then the issue is likely around the horrible ugly hack of trying to use userspace interfaces from within the kernel. The usual guidance is **"don't do that"**. Do you have to do this in the kernel? Can you use a more specific API of the driver to do it, rather than abuse sysfs? – Chris Stratton Mar 20 '19 at 02:21
  • If the EEPROM does not have a unique physical association with the network interface but is rather a more general system resource, or wired like one, then having userspace startup scripts read out the MAC address and re-inject it into the network driver is actually a fairly normal type of startup task for an embedded system. It also gives you a good place to supply an alternate if that address hasn't yet been written by your manufacturing rig. – Chris Stratton Mar 20 '19 at 02:54
  • Normally, I'd read the MAC address EEPROM from the bootloader code (especially if the bootloader has Ethernet support) and get the bootloader to fix up the "mac-address" property for the Ethernet device in the Linux device tree blob passed from the bootloader to the Linux kernel. However, I think you can get the Linux kernel to read the MAC address from the EEPROM itself by using the "nvmem-cells" and "nvmem-cell-names" properties in the device tree node for the Ethernet device. – Ian Abbott Mar 20 '19 at 18:02
  • @ChrisStratton Why the usual guidance is telling us "don't open file in kernel"? I cannot figure it out:( – Richard B. Vannacutt Mar 21 '19 at 04:00
  • Because sysfs is for *userspace*. It is *not intended* for the kernel to use to talk to itself. – Chris Stratton Mar 21 '19 at 04:13
  • @IanAbbott Thanks for the suggestions. I tried to read MAC address in uboot before; However, I found there is no i2c driver for AST2500 in my uboot:( I'll go straight ahead with nvmem and device tree stuff. – Richard B. Vannacutt Mar 21 '19 at 07:06
  • @ChrisStratton Does it cause any implicit issue if I access the sysfs? – Richard B. Vannacutt Mar 21 '19 at 07:12
  • It's a shame that support for nvmem-cells and nvmem-cell-names = "mac-address" isn't wired into the `device_get_mac_address` or `fwnode_get_mac_address` function yet, otherwise the only thing you'd need to change would be the device tree, probably. – Ian Abbott Mar 21 '19 at 10:32

0 Answers0