Probe devices in linux

Проба оборудования

Создание пробы компьютера позволяет узнать подробности строения компьютера, проверить работоспособность устройств и передать системные логи разработчикам для выявления и исправления проблем с поддержкой оборудования. В случае, если для какого-либо устройства в дистрибутиве отсутствует драйвер, то проба предложит подходящую версию ядра Линукс согласно данным LKDDb или сторонние драйвера.

Для создания пробы компьютера на системах ALT Linux P9 и более новых нужно поставить пакет hw-probe:

apt-get update apt-get install hw-probe

sudo -E hw-probe -all -upload

Далее сохранить ссылку, которую вернет команда:

Что с ней можно делать?

С пробой легко обращаться в поддержку или за советом к друзьям (в группу ВК, на форум или Багзиллу) — все логи уже собраны и не будет лишних вопросов.

База оборудования

Помимо упрощения общения с поддержкой, на основе проб разных пользователей создается публичная база данных поддерживаемого оборудования, в которой можно изучать опыт дргугих пользователей по использованию схожих моделей компьютеров и устройств.

База является частью глобальной Линукс-базы, в которой можно посмотреть отчеты для вашего оборудования, загруженные с других дистрибутивов (большинство проблем с оборудованием общие в силу общего апстрима ядра Линукс).

Статистика

Отладка ACPI подсистемы

apt-get install acpica sudo -E hw-probe -all -upload -decode-acpi

В пробе будет добавлен лог acpidump_decoded.

Другие дистрибутивы

На данный момент проба оборудования есть в Linux-дистрибутивах CentOS 8, CentOS 7, CentOS 6, OpenVZ 7, Fedora, Manjaro, openSUSE, Ubuntu, Debian, Alpine, Endless и Alt Linux, а также во FreeBSD, OpenBSD, MidnightBSD и DragonFlyBSD. Для других надо воспользоваться инструкцией или воспользоваться универсальными пакетами AppImage, Docker, Snap или Flatpak. Проще всего пользоваться AppImage — установка окружения вообще не нужна, нужно только скачать файл и запустить.

Приватность

Приватная информация (включая имя пользователя, имя компьютера, IP-адрес, MAC-адрес, серийные номера) НЕ собирается в пробе. Инструмент загружает лишь часть SHA512 хэша от MAC-адреса и серийных номеров для идентификации уникальных компьютеров и компонентов. Данные в базу отправляются по зашифрованному соединению HTTPS.

Источник

Hardware probe

Check operability of computer hardware and find drivers.

Contents

General

Hardware probe (or hw-probe) is a project to simplify collecting of hardware devices operability information on Linux-powered computers.

The main purpose of the project is to gather hardware information in one place and help developers and users to collaboratively debug hardware related issues.

It is the new-gen replacement for the Smolt project with better navigation tools, database scalability, cross-Linux support, sanity operability auto-tests for devices and statistical analysis.

Howto

User’s point of view

Make a hardware probe if something is wrong with the computer or device on board and share the probe link with the developers. All necessary system info and logs are included to the probe and available online by the probe ID/URL and no any additional feedback is needed.

Command line to make a probe:

sudo -E hw-probe -all -upload

Developer’s point of view

Receive a message with problem description and probe ID. Start debugging the problem immediately w/o the need to ask for any logs. All logs are already available in the probe.

The database is created automatically. You can search for interested devices on other computers to learn how to better configure the device.

Install

Select and install an RPM package for your openSUSE distribution.

sudo zypper addrepo https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.4/ hardware sudo zypper install hw-probe

sudo zypper addrepo https://download.opensuse.org/repositories/hardware/openSUSE_Tumbleweed/ hardware sudo zypper install hw-probe

Another way is to use one of the universal packages: AppImage, Flatpak or Docker.

Stats

The following statistical reports are dumped to Github:

Privacy

Private info is not collected. Moreover, it’s safer to share your logs by hw-probe rather than share manually, because most private data is removed or hashed at the client side before uploading.

Warning: Please note that a 32-byte prefix of salted SHA512 hashes of MAC addresses and serial numbers are uploaded to the server in order to properly identify unique computers and parts. These are unlikely to be reversible.

Источник

Who calls the probe() of driver

How does probe() call gets called? Who calls it? As per my understanding, __init() registers driver and then somehow probe() is called to register the device data and irq etc. How exactly it happens? I am working on touchscreen driver and its __init registers itself to i2c driver . Then probe expect i2c_clien t data which returns null. I want to track where it gets filled.

6 Answers 6

Long story short: the probe() function of the driver is called as a result of calling the register_driver for that specific bus. More precisely, it’s called by the probe() of that bus_type structure. In your case: i2c_bus_type .

Here’s the call chain in your I2C case:

• i2c_register_driver
• driver_register
• bus_add_driver
• driver_attach
• __driver_attach (for your device)
• driver_probe_device
• really_probe
• i2c_device_probe (this is what dev->bus->probe is for an i2c driver)
• your_probe_function

When does i2c_register_driver get called? Is it when you call i2cdetect and it finds a device on the bus with a name that matches a registered struct i2c_driver ?

I have prepared a graph that traces platform drive’s probe function. You are working with I2C driver which AFAIK is a platform driver. I hope this helps you to trace the issue.

Also, look into following link to see the discussion on kernelnewbies.

Lets consider an example of a platform device driver :

1. The starting trigger function for the driver->probe() callback is the module_init() macro called while loading the driver; this macro is defined in include/linux/module.h .
2. module_init(my_driver_init) has the callback to my_driver_init() function. my_driver_init() function should have a call to platform_driver_register(my_driver)
3. platform_driver_register(my_driver) assigns my_driver -> probe() handle to generic drv -> probe() and calls the driver_register(my_driver) function.
4. driver_register(my_driver) function adds my_driver to the platform bus and calls driver_attach() function.
5. In the same way, even the platform_device needs to attach to the platform bus.
6. Finally, only if the driver_match_device() returns success based on the .name & .id_table of the driver matches in the platform devices list that comes either from ACPI/DTS , then the driver_probe_device() gets called that has the drv->probe() callback.

@iSegFault : probe() will be called to make sure that the device exist and the functionality is fine.If device is not hot-pluggable, functionality of probe() can be put inside init() method.This will reduce driver’s run time memory footprint. P.S link

Probe() happens at the time of device boot or when device is connected.For a «platform» device the probe function is invoked when a platform device is registered and it’s device name matches the name specified on the device driver. P.S link

The i2c_detect function probes the I2C adapter, looking for the different addresses specified in the addr_data structure. If a device is found, the chip_detect function then is called. P.S link.

One link that will surely clear your doubt. P.S link

In kernel 2.4.29, i can show you that how does probe happen ? Please see below (File name: drivers/acorn/char/pcf8583.c)

static struct i2c_driver pcf8583_driver = < name: "PCF8583", id: I2C_DRIVERID_PCF8583, flags: I2C_DF_NOTIFY, attach_adapter: pcf8583_probe, /* This will be called from i2c-core.c P.S see below function i2c_add_driver()*/ detach_client: pcf8583_detach, command: pcf8583_command >; 

File Name: drivers/i2c/i2c-core.c

int i2c_add_driver(struct i2c_driver *driver) < . . /* now look for instances of driver on our adapters */ if (driver->flags& (I2C_DF_NOTIFY|I2C_DF_DUMMY)) < for (i=0;iattach_adapter(adapters[i]); /*This is a location from where probe is called. Pointer **driver** is of type **pcf8583_driver** which you have passed into this function*/ > ADAP_UNLOCK(); return 0; > 

In PCI for kernel-2.4.29, it gets called when vendor and device id are identified. PCI bus driver do this for you. Please see below code:

File Name: drivers/pci/pci.c

static int pci_announce_device(struct pci_driver *drv, struct pci_dev *dev) < const struct pci_device_id *id; int ret = 0; if (drv->id_table) < dev); /* check for device presence*/ if (!id) < ret = 0; goto out; >> else dev_probe_lock(); if (drv->probe(dev, id) >= 0) < /* This is a location from where probe is called*/ dev->driver = drv; ret = 1; > dev_probe_unlock(); out: return ret; > 

Источник