2017-11-15 1 views
0

Ich möchte auf I2C-Gerätetreiberknoten aus Benutzerbereich in einem Linux-Kernel 3.10.14 zugreifen. Ich habe i2c-dev in die Kernel-Konfiguration aufgenommen und die/dev/i2c- * Geräteknoten bekommen. Allerdings Erlaubnis haben sieEinstellung der Geräteberechtigung von Treibercode schlägt fehl

$ ls -l /dev/i2c-* 
crw------- root  root  89, 1 2014-08-21 20:00 i2c-1 

In drivers/i2c/i2c-dev.c ich den Rückruf

hinzugefügt
static char *i2c_dev_devnode(struct device *dev, umode_t *mode) 
{ 
    if (!mode) 
      return NULL; 
    if (MAJOR(dev->devt) == I2C_MAJOR) 
      *mode = 0666; 
    return NULL; 
} 

und in der gleichen Datei habe ich den Rückruf an die Geräteklasse Struktur:

static int __init i2c_dev_init(void) 
{ 
    ... 
    i2c_dev_class = class_create(THIS_MODULE, "i2c-dev"); 
    ... 

    /* set access rights */ 
    i2c_dev_class->devnode = i2c_dev_devnode; 
    ... 
} 

jedoch die Zugriffsrechte des Geräteknotens

bleiben
crw------- root  root  89, 1 2014-08-21 20:00 i2c-1 

Es gibt keine /lib/udev/rules.d oder /etc/udev/rules.d

Ich würde mich über Vorschläge freuen, was hier schief gehen könnte.

Ich bin auch an Ideen interessiert, wie man dieses Problem prüft.

Antwort

0

Ich verstehe, dass der Rückgabewert der devnode Callback-Funktion nicht "NULL" sein soll, sondern der Name des Geräteknotens. So, Ändern Sie den Rückgabewert Ihrer Funktionen von "NULL" zu "devname". Siehe den Code:

---------------------- Patch ------------------- -

diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c 
index 6f638bb..35a42c6 100644 
--- a/drivers/i2c/i2c-dev.c 
+++ b/drivers/i2c/i2c-dev.c 
@@ -614,6 +614,14 @@ static int i2cdev_notifier_call(struct notifier_block *nb, unsigned long action, 
    .notifier_call = i2cdev_notifier_call, 
}; 

+static char *i2c_dev_devnode(struct device *dev, umode_t *mode) 
+{ 
+ printk("\n\n****%s: %d\n\n",__func__,__LINE__); 
+ if (mode != NULL) 
+   *mode = 0666; 
+ return kasprintf(GFP_KERNEL, "i2cr/%s", dev_name(dev));; 
+} 
+ 
/* ------------------------------------------------------------------------- */ 

/* 
@@ -636,7 +644,12 @@ static int __init i2c_dev_init(void) 
     goto out_unreg_chrdev; 
    } 
    i2c_dev_class->dev_groups = i2c_groups; 
+ /* set access rights */ 
+ printk(KERN_INFO "i2c setting devnode\n"); 
+ i2c_dev_class->devnode = i2c_dev_devnode; 
+ 

+ 
    /* Keep track of adapters which will be added or removed later */ 
    res = bus_register_notifier(&i2c_bus_type, &i2cdev_notifier); 
    if (res) 

Ergebnisse: Ohne Anwendung dieser Patch:

[email protected]:~# ls -l /dev/i2c-* 
crw------- 1 root root 89, 0 Nov 1 13:47 /dev/i2c-0 
crw------- 1 root root 89, 1 Nov 1 13:47 /dev/i2c-1 

Mit Patch:

[email protected]:~# ls -l /dev/i2cr/*  
crw-rw-rw- 1 root root 89, 0 Nov 1 13:38 /dev/i2cr/i2c-0 
crw-rw-rw- 1 root root 89, 1 Nov 1 13:38 /dev/i2cr/i2c-1 

+0

Dies hat die Berechtigungen der Gerätedatei nicht geändert. In – keepitintheground

+0

Treiber/I 2 C/I 2 C-dev.c Ich fand auch das Helfermakro DEVICE_ATTR für Geräte definieren Attribute: Es wird verwendet als: statische DEVICE_ATTR (foo, S_IRUGO, show_foo, store_foo); so sollte die Berechtigungen von/dev/i2c- sein cr - r - r-- aber nicht. – keepitintheground

+0

Ich habe das für Sie getestet. Das funktioniert perfekt. Putting unter Patch & Test Res. – rk1825

0

Sie könnten Folgendes versuchen. Dies funktioniert zumindest mit Kernel 4.9.56.

static int my_uevent(struct device *dev, struct kobj_uevent_env *env) 
{ 
    add_uevent_var(env, "DEVMODE=%#o", 0666); 
    return 0; 
} 

static int __init i2c_dev_init(void) 
{ 
    ... 
    i2c_dev_class = class_create(THIS_MODULE, "i2c-dev"); 
    ... 

    /* set access rights */ 
    i2c_dev_class->dev_uevent = my_uevent; 
    ... 
} 
0

Einrichten des Geräteknotens ist die Verantwortung von udev. Wir müssen also die korrekte udev-Regel verwenden. Ein weiterer init.rc-Ansatz wird fehlschlagen, wenn der Treiber nach der Boot-Zeit geladen wird, zum Beispiel, wenn es ein ladbares Modul ist. Ihre Distribution verwendet möglicherweise eine andere Möglichkeit, Hotplug zu unterstützen, daher müssen wir die Dokumentation zu dieser Distribution konsultieren.