Hw cdcacm sys как удалить
Перейти к содержимому

Hw cdcacm sys как удалить

  • автор:

Общие сведения о перечислении коллекций интерфейсов на составных USB-устройствах

Интерфейсы на составном USB-устройстве можно сгруппировать в коллекции. Универсальный родительский драйвер USB (Usbccgp.sys) может перечислять коллекции интерфейсов четырьмя способами.

Эти четыре метода перечисления коллекций интерфейсов упорядочены иерархически следующим образом:

  1. Процедуры обратного вызова, предоставляемые поставщиком Если поставщик зарегистрировал подпрограмму обратного вызова в универсальном родительском драйвере USB (Usbccgp.sys), универсальный родительский драйвер имеет приоритет перед подпрограммой обратного вызова и позволяет подпрограмме обратного вызова группировать интерфейсы, а не использовать какой-то другой метод. Дополнительные сведения о перечислении коллекции интерфейсов с помощью процедур обратного вызова, предоставляемых поставщиком, см. в статье Перечисление коллекций интерфейсов на составных usb-устройствах.
  2. Функциональные дескрипторы объединения . Если поставщик включил перечисление CDC и WMCDC в универсальном родительском драйвере USB, универсальный родительский драйвер использует функциональные дескрипторы объединения (UFD) для группировки интерфейсов в коллекции. Если этот параметр включен, этот метод имеет приоритет над всеми другими методами, за исключением процедур обратного вызова, предоставляемых поставщиком.
  3. Дескрипторы сопоставлений интерфейсов Если дескрипторы ассоциаций интерфейсов (IAD) присутствуют, универсальный родительский драйвер USB всегда группирует интерфейсы с помощью IAD, а не с помощью устаревших методов. Корпорация Майкрософт рекомендует поставщикам использовать IAD для определения коллекций интерфейсов.
  4. Устаревший звуковой метод Универсальный родительский драйвер USB может перечислять коллекции интерфейсов с помощью устаревших методов, зарезервированных для звуковых функций. Универсальный родительский драйвер не использует этот метод, если на устройстве есть идентификаторы ID.

Настройка перечисления коллекций интерфейсов для составных устройств

Некоторые USB-устройства имеют коллекции интерфейсов, которые не может описать дескриптор ассоциаций usb-интерфейсов (IAD). В Windows Vista и более поздних операционных системах поставщики могут настроить способ определения и перечисления коллекций интерфейсов устройства в универсальном родительском драйвере USB (Usbccgp.sys). Это делается с помощью процедуры обратного вызова перечисления в драйвере фильтра. Подпрограмма обратного вызова помогает универсальному родительскому драйверу определить коллекции пользовательских интерфейсов для устройства.

Чтобы универсальный родительский драйвер определял коллекции пользовательских интерфейсов, поставщик составного устройства должен:

  1. Реализуйте подпрограмму обратного вызова перечисления (USBC_START_DEVICE_CALLBACK).
  2. Укажите указатель на подпрограмму обратного вызова в интерфейсе конфигурации USB-устройства (элемент StartDeviceCallbackUSBC_DEVICE_CONFIGURATION_INTERFACE_V1).
  3. Укажите INF-файл, который соответствует идентификатору устройства составного устройства и явно загружает как универсальный родительский драйвер USB, так и драйвер фильтра.

Рекомендации по реализации

Драйвер фильтра, содержащий подпрограмму обратного вызова перечисления, может быть верхним или нижним драйвером фильтра. Когда универсальный родительский драйвер USB получает IRP_MN_START_DEVICE запрос на запуск составного устройства, он запрашивает интерфейс конфигурации USB-устройства, отправляя запрос IRP_MN_QUERY_INTERFACE в верхнюю часть стека драйверов.

При получении запроса IRP_MN_QUERY_INTERFACE драйвер фильтра должен проверка тип GUID в элементе InterfaceType запроса, чтобы убедиться, что запрошенный интерфейс имеет тип USB_BUS_INTERFACE_USBC_CONFIGURATION_GUID. Если это так, драйвер фильтра возвращает указатель на интерфейс в элементе Интерфейс IRP.

Подпрограмма обратного вызова перечисления должна возвращать указатель на массив дескрипторов функций (USBC_FUNCTION_DESCRIPTOR), описывающих коллекции интерфейсов. Каждый дескриптор функции содержит массив дескрипторов интерфейса (USB_INTERFACE_DESCRIPTOR), описывающих коллекцию интерфейсов. Подпрограмма обратного вызова должна выделять дескрипторы функций и дескрипторы интерфейса из нестраничного пула. Универсальный родительский драйвер освобождает эту память. Подпрограмма обратного вызова должна гарантировать, что член NumberOfInterfaces каждого USB_INTERFACE_DESCRIPTOR точно сообщает количество интерфейсов в коллекции интерфейсов.

Универсальный родительский драйвер создает объект физического устройства (PDO) для каждого дескриптора функции.

Интерфейс конфигурации USB-устройства и подпрограмма обратного вызова перечисления приведены в разделе Универсальные родительские подпрограммы драйвера.

Механизм загрузки универсального родительского драйвера USB

Если составное устройство соответствует требованиям, описанным в разделе Перечисление составных USB-устройств, операционная система создает совместимый USB\COMPOSITE идентификатор , чтобы указать, что устройство является составным. Совместимый идентификатор создает совпадение в usb.inf, и операционная система автоматически загружает универсальный родительский драйвер USB без помощи предоставленного поставщиком INF-файла.

Однако этот механизм по умолчанию не работает для составных устройств, которым требуется пользовательское перечисление коллекций интерфейсов, так как в механизме по умолчанию система не загружает необходимый драйвер фильтра, предоставленный поставщиком. Чтобы механизм подпрограммы обратного вызова перечисления работал, драйвер фильтра, предоставляющий интерфейс конфигурации USB-устройства, уже должен быть загружен, когда универсальный родитель USB перечисляет коллекции интерфейсов составного устройства. Для этого поставщик составного устройства должен установить INF-файл, соответствующий идентификатору составного устройства, и явно загружает как универсальный родительский драйвер USB, так и драйвер фильтра.

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

В Windows Vista универсальный родительский драйвер USB (Usbccgp.sys) обеспечивает поддержку устройств, включенных в класс устройств связи (CDC) универсальной последовательной шины (USB) и класс устройств беспроводной мобильной связи USB (WMCDC).

Спецификация USB Wireless Mobile Communication Device Class (WMCDC) устанавливает стандарт для подключения, управления и обмена содержимым между узлом и беспроводным мобильным устройством (например, мобильным телефоном), когда устройство подключено к USB-порту. WMCDC — это расширение класса устройств связи (CDC), включающее в себя широкий спектр коммуникационных и сетевых устройств. В этом разделе описывается архитектура, поддерживающая устройства CDC и WMCDC в операционных системах Windows.

Устройства WMCDC состоят из нескольких функций, сгруппированных в логические телефоны. Большинство устройств WMCDC имеют один логический телефон, но устройство может иметь несколько логических телефонов. Логические телефоны обычно включают такие функции, как модем данных и факсов, хранилище объектов и средство управления вызовами. Логический телефон может также включать вспомогательные функции, определенные другими спецификациями USB, такими как спецификация класса USB Audio, спецификация класса USB Human Input Device (HID) и спецификация класса ВИДЕО USB.

Архитектура Windows WMCDC использует собственные драйверы Windows для управления функциями устройства WMCDC. Например, вы можете использовать подсистему программного интерфейса приложения телефонии Windows (TAPI) для управления функциями голосового и факсимильного модема вашего устройства, а также подсистему спецификации сетевого интерфейса драйвера Windows (NDIS) для управления функцией Локальной сети Ethernet устройства. Кроме того, вы можете управлять некоторыми функциями, например функцией OBEX, в программном обеспечении в пользовательском режиме с помощью WinUSB (Winusb.sys).

На этом изображении показан пример стека драйверов для устройства WMCDC.

Схема примера конфигурации устройства и стека драйверов.

На предыдущем рисунке устройство WMCDC содержит один логический телефон: функцию OBEX и функцию модема. INF-файл, предоставляемый поставщиком, загружает собственные драйверы Windows для управления модемом. Функция OBEX управляется предоставленным поставщиком драйвером пользовательского режима, который выполняется в среда выполнения платформы драйвера режима пользователя (UMDF). Драйвер пользовательского режима использует протокол Windows Portable Devices (WPD) для взаимодействия с пользовательскими приложениями и интерфейсом, экспортируемым WinUSB для взаимодействия с USB-стеком. Как правило, INF-файл, предоставленный поставщиком, загружает отдельный экземпляр Winusb.sys для каждой коллекции интерфейсов, которая использует Winusb.sys.

Параметры реестра

Стек USB не поддерживает WMCDC автоматически. Необходимо предоставить INF-файл, который загружает экземпляр Usbccgp.sys. INF-файл должен содержать раздел AddReg , который задает значение реестра EnumeratorClass в программном ключе, связанном с Usbccgp.sys, значением REG_BINARY, сформированным из трех чисел: 0x02, 0x00 и 0x 00. В следующем примере кода из примера INF-файла показано, как задать для EnumeratorClass соответствующее значение.

[CCGPDriverInstall.NT] Include=usb.inf Needs=Composite.Dev.NT AddReg=CCGPDriverInstall.AddReg [CCGPDriverInstall.NT.Services] Include=usb.inf Needs=Composite.Dev.NT.Services [CCGPDriverInstall.AddReg] HKR,,EnumeratorClass, 0x00000001,02,00,00 

Значение, которое необходимо назначить EnumeratorClass , создается из трех 1-байтовых двоичных значений, представленных в INF-файле парами шестнадцатеричных цифр: 02, 00 и 00. Эти три числа соответствуют значениям, которые форум разработчиков USB присвоил классу устройств CDC, подклассу устройства CDC и протоколу устройства CDC соответственно.

WmCDC описывается в следующих разделах:

Перечисление коллекций интерфейсов в WMCDC

Класс USB-устройства беспроводной мобильной связи (WMCDC) является подклассом класса USB-устройств связи (CDC). Спецификация WMCDC расширяет, но не существенно изменяет рекомендации CDC по определению коллекций интерфейсов. В частности, устройства WMCDC должны соответствовать рекомендациям CDC по определению коллекций интерфейсов.

Коллекции интерфейсов CDC содержат интерфейс master (USB_INTERFACE_DESCRIPTOR), принадлежащий классу интерфейса связи ( bInterfaceClass = 0x02 ) или классу интерфейса данных ( bInterfaceClass = 0x0A ). Если интерфейс master относится к классу интерфейса связи (что является типичной ситуацией), подкласс интерфейса master (bInterfaceSubClass) указывает модель управления CDC. Модель элемента управления указывает тип интерфейсов, включенных в коллекцию интерфейсов. Описание моделей элементов управления, определяемых форумом разработчиков USB, см. в спецификации CDC и WMCDC.

За интерфейсом master коллекции интерфейсов следует набор обязательных функциональных дескрипторов класса, включая функциональный дескриптор объединения (UFD). В UFD перечислены номера интерфейсов, принадлежащих коллекции. Поле bMasterInterface UFD содержит номер интерфейса master. Ноль или более полей bSubordinateInterface содержат номера других (подчиненных) интерфейсов в коллекции.

Для большинства типов моделей управления универсальный родительский драйвер USB (Usbccgp.sys) создает один объект физического устройства (PDO) для каждого UFD. Но некоторые модели управления включают звуковой интерфейс, который перечисляется универсальным родительским драйвером отдельно от коллекции интерфейсов, к которой принадлежит звуковой интерфейс. Аудиоинтерфейс отображается в списке подчиненных интерфейсов (bSubordinateInterface) в UFD коллекции интерфейсов, но универсальный родительский драйвер создает отдельное PDO для аудиоинтерфейса. PDO для звукового интерфейса и PDO для коллекции интерфейсов, к которой принадлежит звуковой интерфейс, находятся непосредственно над объектом функционального устройства (FDO) родительского составного устройства в дереве объектов устройства. PDO звукового интерфейса не является дочерним элементом коллекции интерфейсов.

Существует две модели управления, характеристики перечисления которых настраиваются в реестре: модель управления беспроводного телефона (WHCM), которая определяет логический телефон, и модель управления OBEX. Чтобы настроить характеристики перечисления этих двух моделей управления, необходимо предоставить INF-файл, который загружает экземпляр Usbccgp.sys и задает значение CdcFlags в программном ключе для этого экземпляра Usbccgp.sys. В следующей таблице описаны параметры конфигурации CdcFlags.

Бит CdcFlags Бит, равный 0 Бит, равный 1
0 (маска = 0x00000001) Универсальный родительский драйвер USB создает отдельное PDO для каждого интерфейса OBEX. Универсальный родительский драйвер USB создает одно PDO для всех интерфейсов OBEX.
1 (маска = 0x00000010) Универсальный родительский драйвер USB не создает PDO для интерфейсов WHCM (логических телефонов). Эти интерфейсы остаются скрытыми с точки зрения дерева объектов устройства. Универсальный родительский драйвер USB создает PDO для каждого интерфейса WHCM.

Например, чтобы очистить оба бита (задать для них значение 0), в INF-файле должна быть указана следующая строка в разделе DDInstall.AddReg .

HKR, , CdcFlags, 0x00010001, 0x00000000 

Чтобы задать для обоих битов значение 1, INF-файл должен содержать следующую строку.

HKR, , CdcFlags, 0x00010001, 0x00000011 

Чтобы задать для бита 0 значение 1, а для бита 1 — 0, INF-файл должен содержать следующую строку.

HKR, , CdcFlags, 0x00010001, 0x00000001 

Любой бит можно задать или сбросить независимо от другого бита.

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

На следующем рисунке показана конфигурация PDO, когда биты 0 и 1 cdcFlags имеют значение 0.

Схема, иллюстрирующая сопоставление коллекции интерфейсов с объектом устройства для CdcFlags = 0x00000000.

Коллекция интерфейсов модели управления беспроводной телефонной связью (WHCM) на предыдущем рисунке содержит три коллекции подчиненных интерфейсов (bSubordinateInterface): две коллекции OBEX и коллекцию модемов. Бит 0 cdcFlags равен 0, поэтому универсальный родительский драйвер USB не создает PDO для коллекции интерфейсов WHCM. Бит 1 cdcFlags равен 0, поэтому универсальный родительский драйвер USB создает отдельное PDO для каждой коллекции интерфейсов OBEX.

На следующем рисунке показана конфигурация PDO, если заданы биты 0 и 1 cdcFlags .

Схема, иллюстрирующая сопоставление коллекции интерфейсов с объектом устройства для CdcFlags = 0x00010001.

Так как бит 0 cdcFlags имеет значение 1, универсальный родительский драйвер USB создает PDO для коллекции интерфейсов WHCM. Так как бит 1 cdcFlags имеет значение 1, универсальный родительский драйвер USB группирует две коллекции OBEX и создает одно PDO для обеих коллекций OBEX.

Может потребоваться представить коллекции OBEX с одним PDO на уровне ядра и различать каждую отдельную коллекцию OBEX в драйвере пользовательского режима. Протокол Windows Portable Devices (WPD) позволяет мультиплексировать потоки данных между разными функциями OBEX на уровне пользователя, когда все функции OBEX сгруппированы в одно PDO на уровне ядра.

В следующем примере INF-файла загружается универсальный родительский драйвер USB для управления устройством WMCDC и показано, как создать PDO для логических телефонов и создать одно PDO для всех коллекций OBEX в логическом телефоне.

[Version] Signature="$Windows NT$" Class=USB ClassGUID= Provider=%MSFT% DriverVer=07/01/2001,5.1.2600.0 CatalogFile=ExampleCatalog.cat PnpLockdown=1 [ControlFlags] ExcludeFromSelect=* [Manufacturer] CompanyName=CompanyName,NTamd64 [CompanyName.NTamd64] %COMPANYNAME.DeviceDesc%=CCGPDriverInstall,USB\Vid_. &Pid_. [CCGPDriverInstall.NT] Include=usb.inf Needs=Composite.Dev.NT AddReg=CCGPDriverInstall.AddReg [CCGPDriverInstall.NT.Services] Include=usb.inf Needs=Composite.Dev.NT.Services [CCGPDriverInstall.AddReg] HKR,,EnumeratorClass,0x00000001,02,00,00 HKR,,CdcFlags,0x00010001,0x00010001 [Strings] MSFT="Microsoft" COMPANYNAME.DeviceDesc="USB Phone Parent" 

Обработка коллекций интерфейсов CDC и WMCDC

Универсальный родительский драйвер USB специально обрабатывает интерфейсы модели управления беспроводным телефоном (WHCM).

В следующем списке перечислены наиболее важные способы, которыми обработка коллекций интерфейсов CDC и WMCDC отличается от других коллекций интерфейсов.

  • Класс беспроводных мобильных устройств связи допускает ограниченное вложение коллекций интерфейсов. В частности, коллекция интерфейсов логического набора телефонов (то есть коллекция интерфейсов WHCM) может содержать другие коллекции подчиненных интерфейсов. Например, телефон, совместимый с WMCDC, может иметь коллекцию интерфейсов WHCM, которая, в свою очередь, содержит коллекцию абстрактных моделей управления и коллекцию OBEX.
  • Вы можете настроить универсальный родительский драйвер USB, чтобы не перечислять коллекции интерфейсов WHCM. Коллекции интерфейсов WHCM, которые не перечислены, остаются скрытыми, но универсальный родительский драйвер использует сведения из дескрипторов функций объединения (UFD), принадлежащих коллекциям интерфейсов WHCM, для группировки и перечисления коллекций подчиненных интерфейсов.
  • Вы можете настроить универсальный родительский драйвер USB для создания отдельных объектов физических устройств (PDO) для коллекций интерфейсов моделей элементов управления OBEX или создания одного PDO для всех коллекций интерфейсов модели управления OBEX.
  • Список номеров интерфейсов в UFD может содержать пробелы. То есть номера интерфейсов UFD могут ссылаться на интерфейсы, которые не являются смежными. Этот тип нумерирования недопустим, например для дескриптора ассоциации интерфейса USB (IAD), интерфейсы которого должны быть смежными и иметь последовательные номера.
  • UFD могут включать связанные коллекции звуковых интерфейсов
  • Идентификаторы оборудования для коллекций интерфейсов CDC и WMCDC должны включать подкласс интерфейса. Другие USB-интерфейсы, идентификаторы оборудования которых содержат суффикс MI_%02X, указывающий номер интерфейса, не содержат сведений о подклассе интерфейса. Сведения о подклассе включаются в идентификатор оборудования, чтобы позволить поставщикам предоставлять INF-файлы с совпадениями идентификаторов оборудования для конкретных коллекций интерфейсов, а не полагаться на положение интерфейса в макете дескриптора, чтобы определить, какой драйвер следует загрузить для коллекции. Сведения о подклассе в идентификаторе оборудования также позволяют постепенно переходить от текущих драйверов, предоставляемых поставщиком, которые управляют коллекциями интерфейсов WMCDC, к альтернативным вариантам, таким как драйверы пользовательского режима. Общие сведения о том, как форматируются аппаратные идентификаторы интерфейсов USB, см. в разделе Идентификаторы для USB-устройств.

Модели управления CDC и WMCDC

В разделе Модели управления CDC и WMCDC описываются свойства коллекций интерфейсов, поддерживаемых в операционных системах Microsoft Windows. Каждое описание включает, среди прочего, список идентификаторов оборудования и устройств, которые создается универсальным родительским драйвером USB для коллекции интерфейсов.

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

Ниже перечислены коллекции интерфейсов, описанные в этом разделе.

Интерфейсы класса Audio

Коллекции интерфейсов класса USB Audio Device, которые встречаются на устройствах CDC и WMCDC, имеют следующие свойства.

Свойство Описание
Справка Определение класса устройства универсальной последовательной шины для звуковых устройств версии 1.0.
Класс Все интерфейсы в коллекции интерфейсов должны принадлежать классу звуковых устройств (0x01).
Подкласс Каждый интерфейс в коллекции интерфейсов должен иметь подкласс, отличный от первого интерфейса в коллекции.
Протокол Нет (0x00).
Enumerated Да.
Связанные интерфейсы Ноль или более смежных интерфейсов, принадлежащих к подклассу потоковой передачи (0x02).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&MI_%02x
USB\Vid_%04x&Pid_%04x&MI_%02x

Модель абстрактного элемента управления CDC

Существует две версии абстрактной модели управления (ACM). Исходная версия определена в спецификации класса USB-устройства связи (CDC). Спецификация USB Wireless Mobile Communication Device Class (WMCDC) содержит расширенное определение ACM.

На этой странице описаны коллекции интерфейсов, соответствующие спецификации WMCDC.

Коллекции интерфейсов, соответствующие спецификации CDC, имеют следующие свойства.

Свойство Описание
Справка Определения классов универсальной последовательной шины для устройств связи версии 1.1, раздел 3.6.2.
Класс интерфейса master Класс интерфейса связи (0x02).
Подкласс интерфейса master ACM (0x02).
Протокол Любой.
Enumerated Да.
Связанные интерфейсы Один интерфейс класса данных и дополнительные интерфейсы класса аудио, на которые ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_02&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_02
USB\Vid_%04x&Pid_%04x&Cdc_02&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_02
Совместимые ИД USB\Class_02&SubClass_02&Prot_%02X
USB\Class_02&SubClass_02
USB\Class_02
Специальная обработка UFD может ссылаться на коллекцию звуковых интерфейсов, которая перечисляется независимо от коллекции интерфейсов ACM.
Модель управления сетью CDC ATM

Коллекции интерфейсов МОДЕЛИ управления сетью ATM (ANCM) USB CDC имеют следующие свойства.

Свойство Описание
Справка Определения классов универсальной последовательной шины для устройств связи версии 1.1, раздел 3.8.3
Класс интерфейса master Класс интерфейса связи (0x02)
Подкласс интерфейса master ANCM (0x07)
Протокол Нет (0x00)
Enumerated Да
Связанные интерфейсы Один интерфейс класса данных, на который ссылается функциональный дескриптор объединения (UFD)
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_07&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_07
USB\Vid_%04x&Pid_%04x&Cdc_07&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_07
Совместимые ИД USB\Class_02&SubClass_07&Prot_00
USB\Class_02&SubClass_07
USB\Class_02
Специальная обработка Нет
Модель управления CDC CAPI

Коллекции интерфейсов модели управления COMMON ISDN API (CAPI) USB CDC имеют следующие свойства.

Свойство Описание
Справка Определения классов универсальной последовательной шины для устройств связи, версия 1.1, раздел 3.7.2
Класс интерфейса master Класс интерфейса связи (0x02)
Подкласс интерфейса master CAPI (0x05)
Протокол Нет (0x00)
Enumerated Да
Связанные интерфейсы Один интерфейс класса данных, на который ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_05&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_05
Совместимые ИД USB\Class_02&SubClass_05&Prot_00
USB\Class_02&SubClass_05
Специальная обработка Нет
Модель управления прямой линией CDC

Коллекции интерфейсов модели прямого управления (DLCM) USB CDC имеют следующие свойства.

Свойство Описание
Справка Определения классов универсальной последовательной шины для устройств связи версии 1.1, раздел 3.6.1.
Класс интерфейса master Класс интерфейса связи (0x02).
Подкласс интерфейса master DLCM (0x01).
Протокол Нет (0x00).
Enumerated Да.
Связанные интерфейсы Класс audio или определяемые поставщиком интерфейсы, на которые ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_01&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_01
USB\Vid_%04x&Pid_%04x&Cdc_01&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_01
Совместимые ИД USB\Class_02&SubClass_01&Prot_00
USB\Class_02&SubClass_01«USB\Class_02
Специальная обработка UFD ссылается на коллекцию интерфейсов аудиоклассов, которая перечисляется независимо от коллекции интерфейсов DLCM.
Модель управления сетью CDC Ethernet

Коллекции интерфейсов модели управления сетью (ENCM) USB CDC Ethernet имеют следующие свойства.

Свойство Описание
Справка Определения классов универсальной последовательной шины для устройств связи версии 1.1, раздел 3.8.2.
Класс интерфейса master Класс интерфейса связи (0x02).
Подкласс интерфейса master ENCM (0x06).
Протокол Нет (0x00).
Enumerated Да.
Связанные интерфейсы Один интерфейс класса данных, на который ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_06&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_06
USB\Vid_%04x&Pid_%04x&Cdc_06&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_06
Совместимые ИД USB\Class_02&SubClass_06&Prot_00
USB\Class_02&SubClass_06
USB\Class_02
Специальная обработка Совместимые идентификаторы этой модели управления совпадают в предоставленном Корпорацией Майкрософт INF-файле. Если операционная система не находит совпадение для одного из идентификаторов оборудования в предоставленном поставщиком INF-файле, система автоматически загружает собственный драйвер мини-порта NDIS для управления коллекцией интерфейсов.
Модель управления CDC с несколькими каналами ISDN

Коллекции многоканационных моделей управления ISDN (MCCM) USB CDC имеют следующие свойства.

Свойство Описание
Справка Определения классов универсальной последовательной шины для устройств связи, версия 1.1, раздел 3.7.1
Класс интерфейса master Класс интерфейса связи (0x02)
Подкласс интерфейса master MCCM (0x04)
Протокол Нет (0x00)
Enumerated Да
Связанные интерфейсы Несколько интерфейсов класса данных, на которые ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_04&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_04
USB\Vid_%04x&Pid_%04x&Cdc_04&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_04
Совместимые ИД USB\Class_02&SubClass_04&Prot_00
USB\Class_02&SubClass_04
USB\Class_02
Специальная обработка Нет
Модель управления телефоном CDC

Коллекции интерфейсов модели управления телефоном USB CDC (TCM) имеют следующие свойства.

Свойство Описание
Справка Определения классов универсальной последовательной шины для устройств связи, версия 1.1, раздел 3.6.3.
Класс интерфейса master Класс интерфейса связи (0x02).
Подкласс интерфейса master TCM (0x03).
Протокол Любой.
Enumerated Да.
Связанные интерфейсы Интерфейсы класса audio, на которые ссылается функциональный дескриптор объединения (UFD).
Код оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_03&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_03
USB\Vid_%04x&Pid_%04x&Cdc_03&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_03
Совместимый идентификатор USB\Class_02&SubClass_03&Prot_%02X
USB\Class_02&SubClass_03
USB\Class_02
Специальная обработка UFD может ссылаться на коллекцию интерфейсов класса аудио, которая перечисляется независимо от коллекции интерфейсов TCM.
Интерфейсы MCPC, уникальные для поставщика

Консорциум по продвижению мобильных вычислений (MCPC) определил формат для коллекций интерфейсов до того, как спецификация класса беспроводных мобильных устройств связи (WMCDC) предоставила формат для устройств CDC, уникальных для поставщиков. Таким образом, коллекции интерфейсов MCPC не соответствуют стандарту WMCDC.

Однако универсальный родительский драйвер USB может перечислить коллекции интерфейсов MCPC, если включен WMCDC. Коллекции интерфейсов MCPC имеют следующие свойства.

Свойство Описание
Справка Спецификация GL-004 консорциума по продвижению мобильных вычислений (MCPC)
Класс CDC (0x02)
Подкласс 0x88
Протокол Нет (0x00)
Enumerated Да
Связанные интерфейсы Ноль или более интерфейсов класса данных, на которые ссылается функциональный дескриптор объединения (UFD)
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_88&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_88
USB\Vid_%04x&Pid_%04x&Cdc_88&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_88
Совместимые ИД USB\Class_02&SubClass_88&Prot_00
USB\Class_02&SubClass_88
USB\Class_02
Специальная обработка Нет
Интерфейсы класса Video

Коллекции интерфейсов класса видеоустройств USB, которые происходят на устройствах CDC и WMCDC, имеют следующие свойства.

Свойство Описание
Справка Определение класса устройства универсальной последовательной шины для видеоустройств версии 1.0.
Класс Видео (0x0E).
Подкласс Управление видео (0x01).
Протокол Нет (0x00).
Enumerated Да.
Связанные интерфейсы Ноль или несколько смежных интерфейсов, принадлежащих к подклассу потоковой передачи (0x02).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&MI_%02x
USB\Vid_%04x&Pid_%04x&MI_%02x
Совместимые ИД USB\Class_0E&SubClass_01&Prot_00
USB\Class_0E&SubClass_01
USB\Class_0E
Специальная обработка Коллекции интерфейсов видеоклассов получают специальную обработку на устройствах CDC. На устройствах, отличных от CDC, коллекции интерфейсов видеоклассов определяются дескрипторами ассоциаций интерфейсов (IAD). На устройствах CDC коллекции интерфейсов видеоклассов определяются функциональными дескрипторами объединения (UFD).
Абстрактная модель управления WMCDC

Существует две версии абстрактной модели управления (ACM). Исходная версия определена в спецификации класса USB Communication Device (CDC). Спецификация USB Wireless Mobile Communication Device Class (WMCDC) содержит расширенное определение ACM. Коллекции ACM, содержащие функцию факса или модема, должны использовать определение WMCDC ACM, а не исходное определение CDC ACM.

На этой странице описаны коллекции интерфейсов, соответствующие спецификации CDC.

Коллекции интерфейсов, соответствующие спецификации WMCDC, имеют следующие свойства.

Свойство Описание
Справка Спецификация подкласса CDC универсальной последовательной шины для беспроводных мобильных устройств связи, версия 1.0, раздел 6.2.
Класс интерфейса master Класс коммуникационного интерфейса (0x02).
Подкласс интерфейса master ACM (0x02).
Протокол Если в коллекции используется протокол набора команд AT, значение протокола, внедренное в совместимые идентификаторы, будет 0x01. Если коллекция использует один из протоколов, описываемых спецификацией WMCDC, значение протокола, внедренное в совместимые идентификаторы, 0x2 через 0x06 или 0xFE.
Enumerated Да.
Связанные интерфейсы Один интерфейс класса данных, на который ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_Modem&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_Modem
USB\Vid_%04x&Pid_%04x&Cdc_Modem&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_Modem
Совместимые ИД USB\Class_02&SubClass_Modem&Prot_%02X
USB\Class_02&SubClass_Modem
USB\Class_02
Специальная обработка UFD может ссылаться на коллекцию звуковых интерфейсов, которая перечисляется независимо от коллекции интерфейсов ACM.

Коллекции интерфейсов должны соответствовать специальным требованиям к дескриптору и конечной точке, указанным в разделе 6.2 спецификации WMCDC. Если коллекция интерфейсов не соответствует требованиям WMCDC, но интерфейс соответствует требованиям CDC, универсальный родительский драйвер USB перечисляет коллекцию интерфейсов и идентификаторы универсального оборудования с форматами CDC.

Модель управления устройствами WMCDC

Коллекции интерфейсов модели управления устройствами (DMM) USB WMCDC имеют следующие свойства.

Свойство Описание
Справка Спецификация подкласса CDC универсальной последовательной шины для беспроводных мобильных устройств связи, версия 1.0, раздел 6.6.
Класс интерфейса master Класс коммуникационного интерфейса (0x02).
Подкласс интерфейса master DMM (0x09).
Протокол Любой.
Enumerated Да.
Связанные интерфейсы Нет.
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_09&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_09
USB\Vid_%04x&Pid_%04x&Cdc_09&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_09
Совместимые ИД USB\Class_02&SubClass_09&Prot_%02X
USB\Class_02&SubClass_09
USB\Class_02
Специальная обработка Эта модель управления не использует функциональный дескриптор объединения (UFD).
Модель wmcdc mobile direct line

Коллекции интерфейсов МОДЕЛИ MDLM для мобильных устройств USB WMCDC имеют следующие свойства:

Свойство Описание
Справка Спецификация подкласса CDC универсальной последовательной шины для беспроводных устройств мобильной связи, версия 1.0, раздел 6.7
Класс интерфейса master Класс интерфейса связи (0x02)
Подкласс интерфейса master MDLM (0x0A)
Протокол Любой
Enumerated Да
Связанные интерфейсы Один или несколько интерфейсов класса данных, на которые ссылается функциональный дескриптор объединения (UFD)
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_0A&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_0A
USB\Vid_%04x&Pid_%04x&Cdc_0A&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_0A
Совместимые ИД USB\Class_02&SubClass_0A&Prot_%02X
USB\Class_02&SubClass_0A
USB\Class_02
Специальная обработка Нет.
Модель управления OBEX WMCDC (несколько PDO)

Существует два способа перечисления коллекций интерфейсов модели управления obex: универсальный родительский драйвер USB может сгруппировать все интерфейсы OBEX и создать один объект физического устройства (PDO) для всех интерфейсов OBEX, или родительский драйвер может создать отдельное PDO для каждого интерфейса OBEX.

Когда универсальный родительский драйвер USB назначает отдельные PDO для каждого интерфейса OBEX, PDO имеют следующие свойства.

Свойство Описание
Справка Спецификация подкласса CDC универсальной последовательной шины для беспроводных устройств мобильной связи, версия 1.0, раздел 6.5.
Класс интерфейса master Класс интерфейса связи (0x02).
Подкласс интерфейса master OBEX (0x0B).
Протокол Нет (0x00).
Enumerated Да.
Связанные интерфейсы Один интерфейс класса данных, на который ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_0B&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_0B
USB\Vid_%04x&Pid_%04x&Cdc_0B&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_0B
Совместимые ИД USB\Class_02&SubClass_0B&Prot_00
USB\Class_02&SubClass_0B
USB\Class_02
Специальная обработка Параметры реестра, связанные с экземпляром универсального родительского драйвера USB, который управляет составным устройством, определяют, управляются ли интерфейсы OBEX с помощью одного PDO или нескольких PDO.
Модель управления OBEX WMCDC (одно PDO)

Существует два способа перечисления коллекций интерфейсов модели управления obex: универсальный родительский драйвер USB может сгруппировать все интерфейсы OBEX и создать один объект физического устройства (PDO) для всех интерфейсов OBEX, или родительский драйвер может создать отдельное PDO для каждого интерфейса OBEX.

Когда универсальный родительский драйвер USB назначает одно PDO всем интерфейсам OBEX, PDO имеет следующие свойства.

Свойство Описание
Справка Спецификация подкласса CDC универсальной последовательной шины для беспроводных устройств мобильной связи, версия 1.0, раздел 6.5.
Класс интерфейса master Класс интерфейса связи (0x02).
Подкласс интерфейса master OBEX (0x0B).
Протокол Нет (0x00).
Enumerated Да.
Связанные интерфейсы Один интерфейс класса данных, на который ссылается функциональный дескриптор объединения (UFD).
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&WPD_OBEX&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&WPD_OBEX
USB\Vid_%04x&Pid_%04x&WPD_OBEX&MI_%02x
USB\Vid_%04x&Pid_%04x&WPD_OBEX
Совместимые ИД USB\Class_02&WPD_OBEX
USB\Class_02
Специальная обработка Параметры реестра, связанные с экземпляром универсального родительского драйвера USB, который управляет составным устройством, определяют, управляются ли интерфейсы OBEX с помощью одного PDO или нескольких PDO. Описание параметров реестра, определяющих, как универсальный родительский драйвер USB перечисляет интерфейсы OBEX, см. в разделе Перечисление коллекций интерфейсов на составных USB-устройствах.
Модель управления беспроводным телефоном WMCDC

Универсальный родительский драйвер USB не всегда перечисляет коллекции интерфейсов модели управления беспроводными телефонами (WHCM). Параметры реестра, связанные с экземпляром универсального родительского драйвера USB, который управляет коллекцией интерфейсов WHCM, определяют, создает ли универсальный родительский драйвер USB объект физического устройства (PDO) для коллекции интерфейсов. Описание параметров реестра, определяющих, как универсальный родительский драйвер USB перечисляет интерфейсы WHCM, см. в разделе Перечисление коллекций интерфейсов на составных usb-устройствах.

Перечисленные коллекции интерфейсов WHCM имеют следующие свойства.

Свойство Описание
Справка Спецификация подкласса CDC универсальной последовательной шины для беспроводных устройств мобильной связи, версия 1.0, раздел 6.1.
Класс интерфейса master Класс интерфейса связи (0x02).
Подкласс интерфейса master WHCM (0x08).
Протокол Нет (0x00).
Enumerated Да.
Связанные интерфейсы Нет.
Идентификаторы оборудования USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_08&MI_%02x
USB\Vid_%04x&Pid_%04x&Rev_%04x&Cdc_08
USB\Vid_%04x&Pid_%04x&Cdc_08&MI_%02x
USB\Vid_%04x&Pid_%04x&Cdc_08
Совместимые ИД USB\Class_02&SubClass_08&Prot_00
USB\Class_02&SubClass_08
USB\Class_02
Специальная обработка Функциональный дескриптор объединения (UFD) определяет интерфейсы, связанные с логическим телефоном.

Форматы идентификаторов оборудования в предыдущих разделах описывают следующие соглашения:

  • Формат printf языка C представляет целые числа. Например, «%04x» означает 4-значное шестнадцатеричное целое число, «%02x» означает 2-значное шестнадцатеричное целое число и т. д.
  • Целое число, следующее за строкой «Vid_», представляет собой 4-значное шестнадцатеричное представление кода поставщика, который комитет USB () назначает поставщику.
  • Целое число, следующее за строкой «Pid_», представляет собой 4-значное шестнадцатеричное представление кода продукта, назначаемого поставщиком устройству.
  • Целое число, следующее за строкой «Rev_», представляет собой 4-значное шестнадцатеричное представление номера редакции устройства.
  • Целое число, следующее за строкой «Cdc_», является подклассом интерфейса.
  • Целое число, следующее за строкой «Prot_», является номером протокола.
  • Целое число, следующее за строкой «MI_», представляет собой 2-значное шестнадцатеричное представление номера интерфейса, которое извлекается из поля bInterfaceNumber дескриптора интерфейса.

Перечисление коллекций интерфейсов на USB-устройствах с идентификаторами IAD

Если составное USB-устройство имеет дескриптор ассоциации интерфейса (IAD) во встроенном ПО, Windows перечисляет коллекции интерфейсов так, как если бы каждая коллекция была одним устройством, и назначает один объект физического устройства (PDO) каждой коллекции интерфейсов и связывает оборудование и совместимые идентификаторы (ID) с PDO. Подробное описание идентификаторов IAD см. в разделе Дескриптор ассоциации интерфейсов USB. В этом разделе описываются идентификаторы оборудования и совместимые идентификаторы (ID), назначенные коллекциям интерфейсов, связанным с IAD.

Идентификаторы оборудования USB-устройств с идентификаторами IAD

В этих идентификаторах оборудования:

  • v(4) — это четырехзначный код поставщика, который комитет USB назначает поставщику и извлекается из поля idVendor дескриптора устройства.
  • p(4) — это четырехзначный код продукта, который поставщик назначает устройству и извлекается из поля idProduct дескриптора устройства.
  • r(4) — это четырехзначный номер выпуска устройства в двоичной десятичной редакции, который поставщик назначает устройству и извлекается из поля bcdDevice дескриптора устройства.
  • z(2) — это двухзначный номер интерфейса, извлеченный из поля bFirstInterface IAD.
Совместимые идентификаторы USB-устройств с IAD

В этих совместимых идентификаторах c(2), s(2) и p(2) содержат значения, взятые соответственно из полей bFunctionClass, bFunctionSubClass и bFunctionProtocol IAD.

Нельзя использовать IAD рекурсивно для привязки функций функций. В частности, если во встроенном ПО устройства есть дескрипторы IAD, универсальный родительский драйвер не будет группировать интерфейсы по классу звукового устройства, как описано в статье Перечисление коллекций интерфейсов на составных USB-устройствах.

Перечисление коллекций интерфейсов на звуковых устройствах без IAD

Для звуковых устройств операционная система Windows может перечислить группы интерфейсов (коллекции интерфейсов), связанные с функцией, и назначить один объект физического устройства (PDO) каждой группе, даже если устройство не имеет дескриптора ассоциации интерфейса (IAD).

Операционная система группирует интерфейсы составных звуковых устройств в коллекции интерфейсов, если интерфейсы соответствуют следующим условиям:

  • Все интерфейсы в коллекции интерфейсов должны быть последовательными. Другими словами, интерфейсы должны находиться рядом друг с другом в памяти встроенного ПО.
  • Все интерфейсы в коллекции интерфейсов должны принадлежать классу звукового устройства. Производитель устройства указывает, что интерфейс принадлежит классу звукового устройства, присваивая значение 0x01 полю bInterfaceClass дескриптора интерфейса.
  • Каждый интерфейс в коллекции интерфейсов должен иметь подкласс, отличный от первого интерфейса в коллекции. Поле bInterfaceSubClass дескриптора интерфейса указывает подкласс устройства интерфейса.

Если интерфейс не соответствует всем этим трем условиям, Windows попытается перечислить его отдельно, а не группировать с другими интерфейсами класса звука.

Операционная система не группирует интерфейсы аудиоклассов особым образом, если в встроенном ПО устройства присутствует дескриптор связи интерфейса (IAD). Метод IAD всегда является предпочтительным методом группирования USB-интерфейсов.

В этом разделе описываются аппаратные и совместимые идентификаторы (ID), связанные с PDO, созданным операционной системой для коллекции интерфейсов, интерфейсы которой принадлежат к классу звукового устройства.

Идентификаторы оборудования звуковых устройств без IAD

В этих идентификаторах оборудования:

  • v(4) — это четырехзначный код поставщика, который комитет по стандартам USB назначает поставщику и извлекается из поля idVendor дескриптора устройства.
  • p(4) — это четырехзначный код продукта, который поставщик назначает устройству и извлекается из поля idProduct дескриптора устройства.
  • r(4) — это четырехзначный номер выпуска устройства в двоичной десятичной редакции, который поставщик назначает устройству и извлекается из поля bcdDevice дескриптора устройства.
  • z(2) — это двухзначный номер интерфейса, извлекаемый из поля bInterfaceNumber дескриптора интерфейса.
Совместимые идентификаторы звуковых устройств без IAD

В этих совместимых идентификаторах c(2), s(2) и p(2) содержат значения, взятые соответственно из полей bInterfaceClass, bInterfaceSubClass и bInterfaceProtocol первого дескриптора интерфейса USB в каждой коллекции интерфейсов.

Связанные темы

  • Универсальный родительский драйвер USB (Usbccgp.sys)
  • USB-драйверы, предоставляемые корпорацией Майкрософт

Обратная связь

Были ли сведения на этой странице полезными?

Проблемы в ядре Linux

В настоящем разделе представлена информация о проблемах в ядре ОС Linux, обнаруженных в рамках проектов Linux Driver Verification, KEDR и Linux File System Verification.

Кликните на номер замечания для просмотра подробных сведений. Кликните на заголовке для сортировки списка по указанному столбцу.

Номер Тип Краткое описание Добавлено Принято Статус
K0009 Утечка (ath5k) Память для sc->ah выделяется в ath5k_init_softc(), но нигде не освобождается 2011-08-08 Kernel Bug Tracker, bug #37592 Исправлено в ядре 3.1-rc1
K0005 Утечка (ath5k) Не все элементы массива chinfo[pier].pd_curves[] освобождаются 2011-04-05 Kernel Bug Tracker, bug #32942 Исправлено в ядре 3.0
K0004 Утечка (ath5k) Не всегда освобождается память, выделенная в ath5k_eeprom_convert_pcal_info_* с помощью kcalloc 2011-04-05 Kernel Bug Tracker, bug #32722 Исправлено в ядре 3.0
K0002 Падение (ext4) Вызов kfree для неинициализированного указателя в ext4_mb_init_backend 2011-03-10 Kernel Bug Tracker, bug #30872 Исправлено в ядре 2.6.39-rc1
K0001 Падение (ext4) Разыменование NULL при использовании sb->s_fs_info после неудачной попытки монтирования 2011-01-14 Kernel Bug Tracker, bug #26752 Исправлено в ядре 2.6.39-rc1
K0003 Падение (fat) Нет обработки ошибок выделения памяти в fat_cache_add 2010-12-10 Kernel Bug Tracker, bug #24622 Исправлено в ядре 3.0
L0282 Предложение i2c: simtec: release_mem_region() вместо release_resource() 2017-08-14 https://www.spinics.net/lists/linux-i2c/msg30831.html
commit
Исправлено в ядре 4.13-rc7
L0207 Падение staging: r8188eu: обработка ошибок _enter_critical_mutex() 2015-10-28 https://www.spinics.net/lists/kernel/msg2094451.html
commit
Исправлено в ядре 4.4-rc1
L0176 Падение m501fb: успешный код возврата в случае ошибки в sm501fb_probe() 2014-11-29 https://www.marc.info/?l=linux-kernel&m=141479528508209&w=2
commit
Исправлено в ядре 3.19-rc1
L0328 Утечка watchdog: sprd_wdt: некорректная обработка ошибок в sprd_wdt_enable 2019-09-09 https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1631370.html
commit
Исправлено в ядре v4.17-rc1
L0301 Утечка usb: phy: tahvo: некорректная обработка ошибок в функции tahvo_usb_probe 2019-08-28 https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1518946.html
commit
Исправлено в ядре v4.15-rc1
L0315 Утечка rtc: несбалансированные вызовы clk_prepare_enable/clk_disable_unprepare в omap_rtc_probe 2019-08-29 https://patchwork.ozlabs.org/patch/845309/
commit
Исправлено в ядре v4.16-rc1
L0318 Утечка clk: si5351: отсутствует обработчик remove 2019-09-04 https://patchwork.kernel.org/patch/9953897
commit
Исправлено в ядре v4.16-rc1
L0295 Падение serial: sccnxp: возврат нуля из sccnxp_probe() при неполностью инициализированных данных 2017-09-18 https://patchwork.kernel.org/patch/9935805/
commit
Исправлено в ядре 4.14-rc4
L0294 Несогласованность Input: ucb1400_ts: некорректные suspend и resume 2017-08-31 https://patchwork.kernel.org/patch/9933247/
commit
Исправлено в ядре 4.14-rc1
L0293 Состояние гонки dmaengine: rcar-dmac: разыменование нулевого указателя из-за преждевременной регистрации обработчика прерываний 2017-08-28 https://patchwork.kernel.org/patch/9911633/
commit
Исправлено в ядре 4.14-rc1
L0291 Противоречие USB: Gadget core: противоречие в интерфейсе usb_add_gadget_udc_release() 2017-08-28 https://patchwork.kernel.org/patch/9906907/
commit
Исправлено в ядре 4.14-rc1
L0296 Падение ASoC: samsung: i2s: разыменование нулевого указателя в samsung_i2s_remove 2017-09-18 https://patchwork.kernel.org/patch/9897495/
commit
Исправлено в ядре 4.14-rc4
L0292 Падение video: fbdev: udlfb: использование памяти после освобождения в dlfb_usb_probe() 2017-08-28 https://patchwork.kernel.org/patch/9895789/
commit
Исправлено в ядре 4.14-rc1
L0281 Падение mISDN: Разыменование нулевого указателя в mISDN_FsmNew() 2017-08-11 https://patchwork.kernel.org/patch/9895787/
commit
Исправлено в ядре 4.13-rc6
L0287 Падение dmaengine: qcom_hidma: освобождение неинициализированного указателя 2017-08-21 https://patchwork.kernel.org/patch/9894059/
commit
Исправлено в ядре 4.14-rc1
L0288 Утечка media: dvb-usb: Утечка памяти на ошибочном пути в dw2102_probe() 2017-08-27 https://patchwork.kernel.org/patch/9893915/
commit
Исправлено в ядре 4.14-rc1
L0290 Предложение parport: release_mem_region() вместо release_resource() 2017-08-28 https://patchwork.kernel.org/patch/9893889/
commit
Исправлено в ядре 4.14-rc1
L0289 Падение wan: dscc4: отсутствие проверок успешности dma mapping 2017-08-27 https://patchwork.kernel.org/patch/9881993/
commit
Исправлено в ядре 4.14-rc1
L0285 Состояние гонки loop: условие гонки в результате преждевременной регистрации устройства 2017-08-15 https://patchwork.kernel.org/patch/9879301/
commit
Исправлено в ядре 4.14-rc1
L0284 Утечка drivers/serial: sysfs group не удаляются на ошибочных путях в aspeed_vuart_probe() 2017-08-15 https://patchwork.kernel.org/patch/9869267/
commit
Исправлено в ядре 4.14-rc1
L0280 Состояние гонки hysdn: состояние гонки в put_log_buffer 2017-08-07 https://patchwork.kernel.org/patch/9869039/
commit
Исправлено в ядре 4.13-rc5
L0279 Опечатка platform/x86: wmi: Неправильный порядок освобождения ресурсов acpi_wmi_init() 2017-07-21 https://patchwork.kernel.org/patch/9857717/
commit
Исправлено в ядре 4.13-rc4
L0283 Утечка serial: 8250: некорректная обработка ошибочных ситуаций в of_platform_serial_probe() 2017-08-15 https://patchwork.kernel.org/patch/9850717/
commit
Исправлено в ядре 4.14-rc1
L0278 Падение smsc911x: Отсутствие проверки успешности ioremap_nocache() 2017-07-12 https://patchwork.kernel.org/patch/9837373/
commit
Исправлено в ядре 4.13-rc1
L0276 Опечатка x86/paravirt: return из void функции 2017-06-24 https://patchwork.kernel.org/patch/9807731/
commit
Исправлено в ядре 4.13-rc1
L0277 Утечка vmlfb: Утечка на ошибочном пути в cr_pll_init() 2017-07-04 https://patchwork.kernel.org/patch/9805343/
commit
Исправлено в ядре 4.13-rc1
L0275 Взаимная блокировка staging: iio: ad7152: Взаимная блокировка в ad7152_write_raw_samp_freq() 2017-05-27 https://patchwork.kernel.org/patch/9751347/
commit
Исправлено в ядре 4.12-rc6
L0274 Падение net: atheros: atl2: atl2_probe() может вернуть 0 в случае ошибки 2017-05-20 https://patchwork.kernel.org/patch/9738301/
commit
Исправлено в ядре 4.12-rc3
L0271 Падение scsi: mvumi: отсутствие обработки ошибок dma mapping функций 2017-04-24 https://patchwork.kernel.org/patch/9695327/
commit
Исправлено в ядре 4.12-rc1
L0269 Падение usb: gadget: mv_u3d: некорректная обработка ошибок в mv_u3d_probe() 2017-04-01 https://patchwork.kernel.org/patch/9657299/
commit
Исправлено в ядре v4.12-rc1
L0267 Падение mtd: spi-nor: hisi: игнорирование ошибок в clk_prepare_enable() 2017-03-25 https://patchwork.kernel.org/patch/9580835/
commit
Исправлено в ядре 4.12-rc1
L0246 Утечка usb: gadget: goku_udc: утечка памяти в goku_probe() 2016-09-20 https://patchwork.kernel.org/patch/9300735/
commit
Исправлено в ядре 4.9-rc1
L0236 Предложение [media] bt8xx: отсутствие обработки ошибок в try_module_get() 2016-07-19 https://patchwork.kernel.org/patch/8786811/
commit
Исправлено в ядре 4.8-rc1
L0340 Падение sc16is7xx: отсутствует проверка ошибочности вызова включения часов 2019-09-20 https://patchwork.kernel.org/patch/10360463
commit
Исправлено в ядре v4.18-rc1
L0330 Утечка spi: jcore: отсутствует отключение часов ref_clk при удалении 2019-09-09 https://patchwork.kernel.org/patch/10290385/
commit
Исправлено в ядре v4.17-rc1
L0306 Утечка dma: отсутствуют вызовы отключения часов на ошибочных путях в fsl_edma_probe 2019-08-28 https://patchwork.kernel.org/patch/10111935
commit
Исправлено в ядре v4.15-rc4
L0323 Утечка fpga: socfpga-a10: отсутствие отключения часов clk при ошибке в socfpga_a10_fpga_probe 2019-09-04 https://patchwork.kernel.org/patch/10103063/
commit
Исправлено в ядре v4.16-rc1
L0316 Утечка tty: serial: mxs-auart: отсутствует отключение часов в mxs_auart_probe 2019-08-29 https://patchwork.kernel.org/patch/10098927
commit
Исправлено в ядре v4.16-rc1
L0307 Утечка usb: dwc3: отсутствует clk_disable_unprepare в функции dwc3_of_simple_clk_init 2019-08-29 https://patchwork.kernel.org/patch/10098333
commit
Исправлено в ядре v4.15-rc4
L0321 Утечка media: pxa_camera: отсутствует отключение и отмена подготовки часов на ошибочных путях 2019-09-04 https://patchwork.kernel.org/patch/10096485/
commit
Исправлено в ядре v4.16-rc1
L0311 Утечка SoC: rockchip: отсутствует отключение часов на ошибочных путях в rk_spdif_probe 2019-08-29 https://patchwork.kernel.org/patch/10096223/
commit
Исправлено в ядре v4.15-rc6
L0324 Утечка rtc: brcmstb-waketimer: отсутствие отключения часов при ошибках в brcmstb_waketmr_probe 2019-09-04 https://patchwork.kernel.org/patch/10064043/
commit
Исправлено в ядре v4.16-rc1
L0192 Взаимная блокировка sound/oss: взаимная блокировка sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND) 2015-04-18 https://marc.info/?l=linux-kernel&m=142931483001579&w=2
commit
Исправлено в ядре 4.1-rc1
L0341 Взаимная блокировка sample: vfio-mdev: взаимная блокировка в функции mdev_access 2019-09-20 https://lkml.org/lkml/2018/7/6/915
commit
Исправлено в ядре v4.18-rc5
L0345 Утечка uwb: hwa-rc: утечка памяти в hwarc_probe 2019-09-20 https://lkml.org/lkml/2018/7/6/412
commit
Исправлено в ядре v4.19-rc1
L0343 Утечка net: mdio-mux: bcm-iproc: неверное соотношение в паре взять/установить 2019-09-20 https://lkml.org/lkml/2018/7/27/772
commit
Исправлено в ядре v4.18-rc8
L0342 Утечка can: ems_usb: утечка памяти при ems_usb_disconnect 2019-09-20 https://lkml.org/lkml/2018/7/27/769
commit
Исправлено в ядре v4.18-rc8
L0351 Падение regulator: tps65217: Разыменование нулевого указателя в функции probe 2019-09-26 https://lkml.org/lkml/2018/7/27/661
commit
Исправлено в ядре v4.19-rc1
L0350 Падение scsi: 3ware: fix return 0 on the error path of probe 2019-09-25 https://lkml.org/lkml/2018/7/27/655
commit
Исправлено в ядре v4.19-rc1
L0344 Падение tty: rocket: потенциальное переполнение буфера в register_PCI 2019-09-20 https://lkml.org/lkml/2018/7/27/644
commit
Исправлено в ядре v4.19-rc1
L0346 Утечка media: dw2102: утечка памяти в dw2102_probe 2019-09-20 https://lkml.org/lkml/2018/7/23/964
commit
Исправлено в ядре v4.19-rc1
L0349 Падение gpio: ml-ioh: выход за границу буфера на ошибочном пути в функции probe 2019-09-24 https://lkml.org/lkml/2018/7/23/949
commit
Исправлено в ядре v4.19-rc1
L0348 Падение firmware: vpd: неверный флаг доступности раздела в vpd_section_destroy 2019-09-20 https://lkml.org/lkml/2018/7/23/944
commit
Исправлено в ядре v4.19-rc1
L0347 Утечка mtd: spi-nor: nxp-spifi: отсутствует освобождение flash_np в nxp_spifi_probe 2019-09-20 https://lkml.org/lkml/2018/5/9/579
commit
Исправлено в ядре v4.19-rc1
L0332 Утечка watchdog: davinci_wdt: отсутствует clk_disable_unprepare на ошибочном пути в функции davinci_wdt_probe 2019-09-16 https://lkml.org/lkml/2018/5/28/731
commit
Исправлено в ядре v4.17-rc1
L0339 Падение i2c: axxia: часы должны быть включены перед вызовом clk_get_rate 2019-09-20 https://lkml.org/lkml/2018/4/30/433
commit
Исправлено в ядре v4.18-rc1
L0336 Утечка spi: pxa2xx: требуется проверять возвращаемое значение функции clk_prepare_enable 2019-09-20 https://lkml.org/lkml/2018/4/30/421
commit
Исправлено в ядре v4.18-rc1
L0338 Утечка spi: meson-spicc: некорректная обработка ошибок в функции meson_spicc_probe 2019-09-20 https://lkml.org/lkml/2018/4/28/191
commit
Исправлено в ядре v4.18-rc1
L0334 Падение spi/bcm63xx-hspi: часы должны быть включены перед вызовом clk_get_rate 2019-09-16 https://lkml.org/lkml/2018/4/26/115
commit
Исправлено в ядре v4.18-rc1
L0337 Падение w1: в функции mxc_w1_probe часы должны быть включены перед вызовом на них функции clk_get_rate 2019-09-20 https://lkml.org/lkml/2018/4/19/363
commit
Исправлено в ядре v4.18-rc1
L0317 Падение RDMA/ocrdma: неправильные права доступа для OCRDMA_RESET_STATS 2019-09-04 https://lkml.org/lkml/2018/3/7/1290
commit
Исправлено в ядре v4.16-rc1
L0335 Утечка spi: stm32: отсутствует отключение часов на ошибочном пути в stm32_spi_probe 2019-09-16 https://lkml.org/lkml/2018/3/30/524
commit
Исправлено в ядре v4.18-rc1
L0320 Утечка serial: 8250_dw: отсутствует отключение часов на ошибочном пути 2019-09-04 https://lkml.org/lkml/2018/3/23/714
commit
Исправлено в ядре v4.16-rc1
L0309 Утечка net: phy: xgene: отсутствует отключение часов на ошибочных путях в xgene_mdio_probe 2019-08-29 https://lkml.org/lkml/2018/3/2/249
commit
Исправлено в ядре v4.15-rc5
L0331 Утечка serial: mxs-auart: отсутствует отключение часов в Alphascale ASM9260 2019-09-16 https://lkml.org/lkml/2018/3/2/1041
commit
Исправлено в ядре v4.17-rc1
L0326 Утечка phy: lpc18xx-usb-otg: утечка на ошибочном пути в функции lpc18xx_usb_otg_phy_power_on 2019-09-09 https://lkml.org/lkml/2018/2/22/829
commit
Исправлено в ядре v4.17-rc1
L0327 Утечка mtd: nand: vf610: отсутствует проверка возвращаемого значения функции mtd_device_register() 2019-09-09 https://lkml.org/lkml/2018/2/12/858
commit
Исправлено в ядре v4.17-rc1
L0329 Утечка watchdog: asm9260_wdt: некорректная обработка ошибок в asm9260_wdt_probe 2019-09-09 https://lkml.org/lkml/2018/2/10/54
commit
Исправлено в ядре v4.17-rc1
L0310 Утечка spi: sun4i: отсутствует отключение часов в sun4i_spi_remove 2019-08-29 https://lkml.org/lkml/2018/1/28/259
commit
Исправлено в ядре v4.15-rc5
L0333 Утечка ir-hix5hd2: отсутствует clk_disable_unprepare на ошибочных путях 2019-09-16 https://lkml.org/lkml/2018/1/26/674
commit
Исправлено в ядре v4.17-rc1
L0325 Утечка crypto: picoxcell: утечка на ошибочном пути в функции spacc_probe 2019-09-09 https://lkml.org/lkml/2018/1/24/356
commit
Исправлено в ядре v4.16-rc2
L0303 Состояние гонки w1: некорректное разблокирование мьютекса и уменьшение счетчика refcnts 2019-08-28 https://lkml.org/lkml/2017/9/29/450
commit
Исправлено в ядре v4.15-rc1
L0298 Состояние гонки loop: fix to a race condition due to the early registration of device 2017-09-16 https://lkml.org/lkml/2017/8/7/390
commit
Исправлено в ядре v4.14-rc1
L0302 Утечка mtd: plat-ram: замена неподходящего ручного управления ресурсами 2019-08-26 https://lkml.org/lkml/2017/8/16/493
commit
Исправлено в ядре v4.15-rc1
L0299 Падение misc: ibmasm: успешный код возврата на неуспешном пути 2019-08-27 https://lkml.org/lkml/2017/8/1/446
commit
Исправлено в ядре v4.15-rc1
L0273 Утечка serial: altera_jtaguart: отсутствие iounmap() 2017-05-18 https://lkml.org/lkml/2017/5/12/612
commit
Исправлено в ядре 4.12-rc3
L0270 Падение m2m-deinterlace: deinterlace_probe() может вернуть 0 в случае ошибки 2017-04-07 https://lkml.org/lkml/2017/4/7/713
commit
Исправлено в ядре 4.12-rc1
L0272 Падение sm501fb: sm501fb_start() может вернуть 0 в случае ошибки 2017-05-02 https://lkml.org/lkml/2017/4/29/94
commit
Исправлено в ядре 4.12-rc1
L0265 Предложение net/sched: act_skbmod: ненужный rcu_read_unlock() в tcf_skbmod_dump() 2017-03-16 https://lkml.org/lkml/2017/3/4/264
commit
Исправлено в ядре 4.11-rc3
L0266 Падение irda: vlsi_ir: некорректная проверка на ошибки при отображении dma 2017-03-25 https://lkml.org/lkml/2017/3/24/946
commit
Исправлено в ядре 4.11-rc6
L0264 Взаимная блокировка z3fold: не освобождается спинлок в z3fold_reclaim_page() 2017-03-16 https://lkml.org/lkml/2017/3/10/1475
commit
Исправлено в ядре 4.11-rc3
L0268 Падение mmc: sdhci-pxav2: отсутствие обработки ошибок при вызове clk_prepare_enable() 2017-03-28 https://lkml.org/lkml/2017/2/10/701
commit
Исправлено в ядре v4.12-rc1
L0305 Утечка net: ethernet: arc: неотключенные часы при обработке ошибок в функции emac_rockchip_probe 2019-08-28 https://lkml.org/lkml/2017/12/9/69
commit 1
commit 2
Исправлено в ядре v4.15-rc4
L0314 Утечка spi: sun6i: отсутствует отключение/отмена подготовки часов при удалении 2019-08-29 https://lkml.org/lkml/2017/12/7/697
commit
Исправлено в ядре v4.16-rc1
L0313 Утечка spi: отсутствует отключение часов при ошибках регистрации контроллера spi в функции jcore_spi_probe 2019-08-29 https://lkml.org/lkml/2017/12/7/202
commit
Исправлено в ядре v4.16-rc1
L0322 Утечка media: s5p-jpeg: отсутствует clk_disable_unprepare 2019-09-04 https://lkml.org/lkml/2017/12/6/630
commit
Исправлено в ядре v4.16-rc1
L0304 Утечка net: mvmdio: отсутствуют вызовы disable/unprepare для часов в функции orion_mdio_probe 2019-08-28 https://lkml.org/lkml/2017/12/6/399
commit
Исправлено в ядре v4.15-rc3
L0308 Утечка dma: отсутствует clk_disable_unprepare в jz4740_dma_probe 2019-08-29 https://lkml.org/lkml/2017/12/6/341
commit
Исправлено в ядре v4.15-rc4
L0312 Утечка thermal: int3400_thermal: отсутствует освобождение ресурсов в функции int3400_thermal_probe 2019-08-29 https://lkml.org/lkml/2017/12/29/413
commit
Исправлено в ядре v4.16-rc1
L0319 Утечка v4l: mt9v032: отсутствует отключение часов на ошибочных путях 2019-09-04 https://lkml.org/lkml/2017/11/24/550
commit
Исправлено в ядре v4.16-rc1
L0260 Падение net: adaptec: starfire: отсутствие проверок на ошибки при отображении dma 2017-01-28 https://lkml.org/lkml/2017/1/27/892
commit
Исправлено в ядре 4.10-rc7
L0263 Падение mmc: wbsd: некорректная проверка валидности dma_addr 2017-02-13 https://lkml.org/lkml/2017/1/13/791
commit
Исправлено в ядре 4.11-rc1
L0245 Падение rapidio/rio_cm: использование GFP_KERNEL в атомарном контексте 2016-09-19 https://lkml.org/lkml/2016/9/9/737
commit
Исправлено в ядре 4.8-rc8
L0243 Состояние гонки dwc_eth_qos: возможные гонки из-за регистрации неполностью инициализированного устройства 2016-09-09 https://lkml.org/lkml/2016/9/8/354
commit
Исправлено в ядре 4.8-rc7
L0248 Состояние гонки speakup: гонка в synth_direct_store 2016-09-21 https://lkml.org/lkml/2016/9/5/322
commit
Исправлено в ядре 4.9-rc1
L0250 Падение net: mvmdio: вызов clk_disable_unprepare() на неинициализированных часах 2016-10-01 https://lkml.org/lkml/2016/9/30/451
commit
Исправлено в ядре 4.9-rc1
L0251 Падение firewire: nosy: разыменование нулевого указателя в случае неуспеха ioremap_nocache() 2016-10-09 https://lkml.org/lkml/2016/9/24/222
commit
Исправлено в ядре 4.9-rc4
L0249 Падение i2c: axxia: отсутствие отключения часов на ошибочном пути в axxia_i2c_probe() 2016-09-23 https://lkml.org/lkml/2016/9/23/150
commit
Исправлено в ядре 4.9-rc1
L0244 Падение IB/rxe: использование GFP_KERNEL в атомарном контексте 2016-09-16 https://lkml.org/lkml/2016/9/2/602
commit
Исправлено в ядре 4.8-rc7
L0240 Падение i2c: ocores: отсутствует clk_disable_unprepare() на ошибочном пути 2016-08-04 https://lkml.org/lkml/2016/8/3/468
commit
Исправлено в ядре 4.8-rc3
L0247 Состояние гонки wl3501_cs: гонка в wl3501_reset() 2016-09-20 https://lkml.org/lkml/2016/8/2/158
commit
Исправлено в ядре 4.9-rc1
L0261 Утечка backlight: adp5520: не удаляется sysfs группа в случае ошибки в adp5520_bl_probe() 2017-01-29 https://lkml.org/lkml/2016/7/8/756
commit
Исправлено в ядре 4.11-rc1
L0229 Утечка i2c: efm32: пропущен clk_disable_unprepare() в efm32_i2c_probe() 2016-07-16 https://lkml.org/lkml/2016/7/15/760
commit
Исправлено в ядре 4.8-rc1
L0230 Состояние гонки libertas: состояние гонки в lbs_mac_event_disconnected() 2016-07-17 https://lkml.org/lkml/2016/6/7/299
commit
Исправлено в ядре v4.8-rc1
L0239 Утечка [media] radio-maxiradio: утечка памяти при удалении устройства 2016-07-28 https://lkml.org/lkml/2016/6/3/805
commit
Исправлено в ядре 4.8-rc1
L0237 Несогласованность drm_aux-dev: некорректная обработка ошибок в drm_dp_aux_dev_init() 2016-07-19 https://lkml.org/lkml/2016/6/29/708
commit
Исправлено в ядре 4.8-rc1
L0228 Падение act_ife: вызов блокирующихся функций в атомарном контексте 2016-06-20 https://lkml.org/lkml/2016/6/16/755
commit
Исправлено в ядре 4.7-rc6
L0233 Состояние гонки rtlwifi: rtl8192ee: Исправлено потенциальное состояние гонки 2016-07-18 https://lkml.org/lkml/2016/6/10/153
commit
Исправлено в ядре 4.8-rc1
L0235 Состояние гонки rtlwifi: rtl8723ae: Исправлено потенциальное состояние гонки 2016-07-18 https://lkml.org/lkml/2016/6/10/153
commit
Исправлено в ядре v4.8-rc1
L0234 Состояние гонки rtlwifi: rtl8723be: Исправлено потенциальное состояние гонки 2016-07-18 https://lkml.org/lkml/2016/6/10/153
commit
Исправлено в ядре v4.8-rc1
L0231 Состояние гонки rtlwifi: rtl8821ae: Исправлено потенциальное состояние гонки 2016-07-17 https://lkml.org/lkml/2016/6/10/153
commit
Исправлено в ядре v4.8-rc1
L0232 Состояние гонки rtlwifi: rtl8188ee: Исправлено потенциальное состояние гонки 2016-07-18 https://lkml.org/lkml/2016/6/10/153
commit
Исправлено в ядре 4.8-rc1
L0227 Падение fbdev: fbmem: игнорирование ошибок в fbmem_init() 2016-05-03 https://lkml.org/lkml/2016/5/2/1059
commit
Исправлено в ядре 4.7-rc1
L0238 Неадекватность ide-tape: опечатка при обработке ошибок в idetape_init() 2016-07-26 https://lkml.org/lkml/2016/4/29/796
commit
Исправлено в ядре 4.8-rc1
L0225 Падение mptsas: некорректная проверка ошибок при dma mapping 2016-04-16 https://lkml.org/lkml/2016/4/15/942
commit
Исправлено в ядре 4.7-rc1
L0226 Утечка mei: блокировка выгрузки модуля при неуспешном probe() 2016-04-30 https://lkml.org/lkml/2016/4/1/642
commit
Исправлено в ядре 4.7-rc1
L0224 Падение USB: whci-hcd: некорректная проверка ошибок dma mapping 2016-03-26 https://lkml.org/lkml/2016/3/25/283
commit
Исправлено в ядре 4.7-rc1
L0222 Падение mtip32xx: некорректная проверка ошибок при dma mapping 2016-03-19 https://lkml.org/lkml/2016/3/18/669
commit
Исправлено в ядре 4.6-rc1
L0220 Взаимная блокировка usb: gadget: bdc_udc: fix race condition in bdc_udc_exit() 2016-02-27 https://lkml.org/lkml/2016/2/26/1034
commit
Исправлено в ядре 4.6-rc1
L0221 Падение at76c50x-usb: двойной usb_put_dev() после загрузки firmware в at76_probe() 2016-03-07 https://lkml.org/lkml/2016/2/20/177
commit
Исправлено в ядре 4.6-rc1
L0259 Предложение samples/vfio-mdev: возврат нуля на ошибочном пути в mtty_dev_init() 2016-12-31 https://lkml.org/lkml/2016/12/30/303
commit
Исправлено в ядре 4.10-rc3
L0262 Падение adm80211: отсутствие проверок на ошибки при отображении dma 2017-01-29 https://lkml.org/lkml/2016/12/2/593
commit
Исправлено в ядре 4.11-rc1
L0258 Утечка uio: pruss: отсутствие clk_disable() 2016-12-14 https://lkml.org/lkml/2016/11/25/785
commit
Исправлено в ядре 4.10-rc1
L0253 Падение net: macb: отсутствие проверок на ошибки при отображении dma в start_xmit() 2016-11-19 https://lkml.org/lkml/2016/11/18/762
commit
Исправлено в ядре 4.9-rc7
L0255 Падение mmc: wbsd: отсутствие проверок на ошибки при отображении dma 2016-11-20 https://lkml.org/lkml/2016/11/11/512
commit
Исправлено в ядре 4.10-rc1
L0252 Падение vmxnet3: некорректное предположение о dma_pa в vmxnet3_set_mc() 2016-10-15 https://lkml.org/lkml/2016/10/7/705
commit
Исправлено в ядре 4.9-rc4
L0254 Падение usb: gadget: mv_u3d: отсутствие проверок на ошибки при отображении dma 2016-11-20 https://lkml.org/lkml/2016/10/28/689
commit
Исправлено в ядре 4.10-rc1
L0256 Падение IB/isert: отсутствие проверок на ошибки при отображении dma 2016-12-14 https://lkml.org/lkml/2016/10/21/926
commit
Исправлено в ядре 4.10-rc1
L0257 Падение SoC: mxs-saif: возможное переполнение буфера в mxs_saif_probe() 2016-12-14 https://lkml.org/lkml/2016/10/14/524
commit
Исправлено в ядре 4.10-rc1
L0219 Падение be2iscsi: отсутствие проверки ошибок при dma mapping 2016-02-23 https://lkml.org/lkml/2016/1/26/1044
commit
Исправлено в ядре 4.6-rc1
L0216 Падение ipw2x00: отсутствие проверок ошибок при dma mapping 2016-01-02 https://lkml.org/lkml/2016/1/1/182
commit
Исправлено в ядре 4.5-rc1
L0204 Утечка usb: gadget: amd5536udc: утечки при обработке ошибок в udc_pci_probe() 2015-09-14 https://lkml.org/lkml/2015/9/5/225
commit
Исправлено в ядре 4.3-rc3
L0206 Взаимная блокировка usb: gadget: взаимная блокировка в pch-udc 2015-09-18 https://lkml.org/lkml/2015/9/28/256
commit
Исправлено в ядре 4.4-rc1
L0202 Блокировка gpio/grgpio: взаимная блокировка в grgpio_irq_unmap() 2015-08-17 https://lkml.org/lkml/2015/8/17/117
commit
Исправлено в ядре 4.3-rc1
L0203 Утечка mtd: nettel: утечка в nettel_init() в случае ошибки в mtd_device_register() 2015-08-18 https://lkml.org/lkml/2015/8/13/753
commit
Исправлено в ядре 4.3-rc1
L0205 Утечка mcb: утечки в mcb_pci_probe() 2015-09-16 https://lkml.org/lkml/2015/7/8/1041
commit
Исправлено в ядре 4.3-rc5
L0197 Утечка usb: gadget: mv_udc_core: утечка I/O памяти 2015-07-20 https://lkml.org/lkml/2015/7/19/92
commit
Исправлено в ядре 4.2-rc4
L0201 Утечка bfa: утечка bfad_im_port_index при выгрузке модуля 2015-08-12 https://lkml.org/lkml/2015/6/11/709
commit
Исправлено в ядре 4.3-rc1
L0194 Утечка iio: light: hid-sensor-prox: утечка памяти в probe() 2015-05-12 https://lkml.org/lkml/2015/5/6/848
commit
Исправлено в ядре 4.1-rc4
L0196 Утечка HID: lenovo: Отсутствует освобождение sysfs group при обработке ошибок 2015-05-29 https://lkml.org/lkml/2015/5/28/790
commit
Исправлено в ядре 4.2-rc1
L0195 Взаимная блокировка target: Двойная блокировка в iscsit_get_tpg() 2015-05-19 https://lkml.org/lkml/2015/5/19/964
commit
Исправлено в ядре 4.1
L0199 Утечка [media] marvell-ccic: Утечка памяти при обработке ошибок в cafe_smbus_setup() 2015-07-21 https://lkml.org/lkml/2015/4/3/585
commit
Исправлено в ядре 4.2-rc8
L0193 Падение pxa168: двойное освобождение ресурсов 2015-04-26 https://lkml.org/lkml/2015/4/24/803
commit
Исправлено в ядре 4.1-rc2
L0191 Утечка dmaengine: pch_dma: утечка памяти при обработке ошибок в pch_dma_probe() 2015-04-17 https://lkml.org/lkml/2015/4/10/833
commit
Исправлено в ядре 4.1-rc1
L0190 Падение NVMe: Некорректная обработка кода возврата class_create(«nvme») 2015-04-07 https://lkml.org/lkml/2015/3/6/858
commit
Исправлено в ядре 4.1-rc1
L0189 Падение staging: ozwpan: отсутствие обработки ошибок в ozwpan_init() 2015-03-26 https://lkml.org/lkml/2015/3/20/650
commit
Исправлено в ядре 4.1-rc1
L0187 Утечка EDAC: утечки при обработки ошибок в edac_init() 2015-02-26 https://lkml.org/lkml/2015/2/6/24
commit
Исправлено в ядре 4.1-rc1
L0186 Падение i40e: утечка памяти при обработке ошибок в i40e_dbg_command_write() 2015-02-26 https://lkml.org/lkml/2015/2/20/576
commit
Исправлено в ядре 4.0-rc3
L0215 Падение prism54: некорректная проверка ошибок при dma mapping 2015-12-26 https://lkml.org/lkml/2015/12/25/57
commit
Исправлено в ядре v4.5-rc1
L0213 Падение natsemi: отсутствие проверки ошибок при dma mapping 2015-12-19 https://lkml.org/lkml/2015/12/19/70
commit
Исправлено в ядре 4.4-rc8
L0212 Взаимная блокировка nfit: acpi_nfit_notify(): device остаётся захваченным 2015-12-11 https://lkml.org/lkml/2015/12/11/781
commit
Исправлено в ядре 4.4-rc6
L0209 Падение sound: некорректная проверка кода ответа register_chrdev() 2015-11-07 https://lkml.org/lkml/2015/11/6/914
commit
Исправлено в ядре 4.4-rc1
L0210 Падение vmxnet3: некорректная проверка ошибок dma mapping 2015-11-28 https://lkml.org/lkml/2015/11/27/498
commit
Исправлено в ядре 4.4-rc4
L0214 Падение [media] lirc_imon: imon_probe() with mutex held 2015-12-20 https://lkml.org/lkml/2015/11/14/98
commit
Исправлено в ядре 4.5-rc1
L0208 Падение mcb: mcb_pci_probe() возвращает 0 в случае ошибки 2015-10-28 https://lkml.org/lkml/2015/10/17/238
commit
Исправлено в ядре 4.4-rc1
L0179 Падение usb/kaweth: необходимо использовать GFP_ATOMIC при захваченном спинлоке в usb_start_wait_urb() 2015-01-12 https://lkml.org/lkml/2015/1/9/725
commit
Исправлено в ядре 3.19-rc5
L0178 Взаимная блокировка drm/radeon: взаимная блокировка из-за некорректной обработки таймаута в kgd_hqd_destroy() 2015-01-04 https://lkml.org/lkml/2015/1/3/116
commit
Исправлено в ядре 3.19-rc4
L0182 Утечка [media] cx231xx: утечка usbdev при обработке ошибок в cx231xx_usb_probe() 2015-01-16 https://lkml.org/lkml/2015/1/16/570
commit
Исправлено в ядре 4.0-rc1
K0010 Неадекватность kernel/module.c: освобождение lock-classes в случае ошибки в parse_args() 2015-02-06 https://lkml.org/lkml/2015/1/14/15
commit
Исправлено в ядре 4.0-rc1
L0181 Утечка [media] mceusb: утечка usbdev 2015-01-12 https://lkml.org/lkml/2014/9/8/661
commit
Исправлено в ядре 3.19-rc6
L0169 Неадекватность ecryptfs: некорректный и ненужный код в ecryptfs_do_create() 2014-09-23 https://lkml.org/lkml/2014/9/22/627
commit
Исправлено в ядре v3.18-rc1
L0180 Утечка [media] imon: утечки usbdev 2015-01-12 https://lkml.org/lkml/2014/9/15/920
commit
Исправлено в ядре 3.19-rc6
L0168 Блокировка ufs: взаимная блокировка в результате слияния sb mutex 2014-09-07 https://lkml.org/lkml/2014/9/1/618
commit
Исправлено в ядре 3.17-rc4
L0167 Падение at76c50x-usb: использование указателя после освобождения в at76_probe() 2014-08-25 https://lkml.org/lkml/2014/8/14/457
commit
Исправлено в ядре 3.17-rc7
L0164 Утечка isdn/bas_gigaset: утечка при обработке ошибок в gigaset_probe() 2014-07-26 https://lkml.org/lkml/2014/7/25/679
commit
Исправлено в ядре 3.16
F0010 Падение f2fs: Возможное использование после освобождения при размонтировании файловой системы 2014-07-25 https://lkml.org/lkml/2014/7/21/198
commit
Исправлено в 3.17-rc1
L0162 Падение farsync: некорректные обращения к памяти в fst_add_one() и fst_init_card() 2014-07-10 https://lkml.org/lkml/2014/7/10/676
commit
Исправлено в ядре 3.16-rc6
L0156 Падение rsi: rsi_module_init() игнорирует ошибки в usb_register() 2014-06-07 https://lkml.org/lkml/2014/6/6/697
commit
Исправлено в ядре 3.17-rc1
L0157 Падение rsi_91x_sdio: обработка ошибок в rsi_module_init() 2014-06-07 https://lkml.org/lkml/2014/6/6/695
commit
Исправлено в ядре 3.17-rc1
L0159 Падение rsi: утечки и обработка ошибок в rsi_91x_usb() 2014-06-27 https://lkml.org/lkml/2014/6/26/527
commit
Исправлено в ядре 3.17-rc1
L0161 Падение usb: host: max3421-hcd: GFP_ATOMIC в max3421_urb_enqueue() 2014-06-29 https://lkml.org/lkml/2014/6/19/507
commit
Исправлено в ядре 3.17-rc1
L0158 Падение staging: line6: probe возвращает 0 несмотря на отсутствие инициализации модуля 2014-06-11 https://lkml.org/lkml/2014/6/10/587
commit
Исправлено в ядре 3.17-rc1
L0151 Блокировка usb-gadget: gr_udc: выделение памяти с GFP_ATOMIC в gr_queue_ext() 2014-05-08 https://lkml.org/lkml/2014/5/7/646
commit
Исправлено в ядре 3.16-rc1
L0160 Утечка [media] tlg2300: утечки при обработке ошибок в poseidon_probe() 2014-06-27 https://lkml.org/lkml/2014/5/30/643
commit
Исправлено в ядре 3.17-rc1
L0155 Утечка [media] usbtv: утечка при обработке ошибок в usbtv_probe() 2014-05-23 https://lkml.org/lkml/2014/5/26/642
commit
Исправлено в ядре 3.17-rc1
F0009 Падение ext4: Удаление ext4_groupinfo_caches во время монтирования вызывает BUG_ON для других примонтированных файловых систем ext4 2014-05-12 https://lkml.org/lkml/2014/5/12/147
commit
Исправлено в 3.16-rc1
L0154 Падение w1: освобождение незахваченного list_mutex в __w1_remove_master_device() 2014-05-23 https://lkml.org/lkml/2014/4/30/591
commit
Исправлено в ядре 3.16-rc1
L0152 Блокировка bfa: при захваченном спинлоке выделять память всегда необходимо с флагом GFP_ATOMIC 2014-05-08 https://lkml.org/lkml/2014/4/18/38
commit
Исправлено в ядре 3.16-rc1
F0008 Падение f2fs: В функции recover_inode_page() срабатывает BUG_ON, когда монтируется корректная файловая система 2014-04-18 https://lkml.org/lkml/2014/4/14/189
commit
Исправлено в ядре 3.17-rc1
L0150 Падение USB: cdc-acm: двойной usb_autopm_put_interface() в acm_port_activate() 2014-04-12 https://lkml.org/lkml/2014/4/11/627
commit
Исправлено в ядре 3.15-rc2
L0147 Утечка p54usb: утечка ресурсов на ошибочном пути в p54u_probe() 2014-03-09 https://lkml.org/lkml/2014/3/7/503
commit
Исправлено в ядре 3.15-rc1
L0149 Падение rtl8187: использование после освобождения на ошибочном пути в rtl8187_probe() 2014-03-29 https://lkml.org/lkml/2014/3/28/425
commit
Исправлено в ядре 3.15-rc1
L0148 Утечка adv7180: утечка прерывания на ошибочном пути в init_device() 2014-03-14 https://lkml.org/lkml/2014/3/14/479
commit
Исправлено в ядре 3.15-rc1
F0007 Падение f2fs: падение в umount, если в процессе системного вызова mkdir сбоит функция f2fs_init_acl() 2014-02-17 https://lkml.org/lkml/2014/2/6/18
commit
Исправлено в kernel 3.15-rc1
L0143 Утечка staging: gdm72xx: fix leaks at failure path in gdm_usb_probe() 2014-02-07 https://lkml.org/lkml/2014/2/5/748
commit
Исправлено в ядре 3.14-rc3
L0145 Падение drm/vmwgfx: исправление разыменования нулевого указателя на ошибочном пути 2014-03-01 https://lkml.org/lkml/2014/2/28/501
commit
Исправлено в ядре 3.14-rc5
L0146 Падение staging: dgap: отсутствие обработки ошибок в dgap_start() 2014-03-09 https://lkml.org/lkml/2014/2/23/92
commit
Исправлено в ядре 3.15-rc1
L0183 Падение uio/uio_pci_generic: успешный код возврата в случае ошибки в probe() 2015-01-16 https://lkml.org/lkml/2014/12/5/506
commit
Исправлено в ядре 4.0-rc1
L0184 Падение staging: dgnc: некорректная обработка ошибок в dgnc_start() 2015-01-17 https://lkml.org/lkml/2014/12/19/368
commit
Исправлено в ядре 4.0-rc1
L0185 Утечка rsi: утечка памяти в rsi_load_ta_instructions() 2015-01-17 https://lkml.org/lkml/2014/12/12/709
commit
Исправлено в ядре 4.0-rc1
L0175 Взаимная блокировка drm/i915: взаимная блокировка при обработке ошибок в __intel_framebuffer_create() 2014-11-29 https://lkml.org/lkml/2014/11/7/674
commit
Исправлено в ядре 3.19-rc1
L0174 Утечка usbip: утечки при обработке ошибок в stub_probe() 2014-11-29 https://lkml.org/lkml/2014/11/28/477
commit
Исправлено в ядре 3.19-rc1
L0173 Неадекватность xen-netback: некорректный код возврата в случае ошибки в backend_create_xenvif() 2014-11-24 https://lkml.org/lkml/2014/11/24/181
commit
Исправлено в ядре 3.18-rc7
L0171 Падение ieee802154: некорректная обработка ошибок в ieee802154fake_probe() 2014-11-15 https://lkml.org/lkml/2014/11/14/709
commit
Исправлено в ядре 3.18-rc6
L0172 Утечка can: esd_usb2: утечка памяти при отключении устройства 2014-11-18 https://lkml.org/lkml/2014/10/10/348
commit
Исправлено в ядре 3.18-rc6
L0137 Утечка NFC: port100: Исправление утечки устройства 2014-01-04 https://lkml.org/lkml/2014/1/4/98
commit
Исправлено в ядре 3.14-rc1
L0144 Блокировка drivers/message/i2o/i2o_config.c: исправление взаимной блокировки в compat_ioctl(I2OGETIOPS) 2014-02-11 https://lkml.org/lkml/2014/1/31/468
commit
Исправлено в ядре 3.14-rc3
L0223 Утечка Input: gtco — fix usb_dev leak 2016-03-20 https://lkml.org/lkml/2014/1/27/399
commit
Исправлено в ядре 4.6-rc1
L0140 Падение RDMA/amso1100: Добавление проверки была ли выделена память из кэша перед ее освобождением 2014-01-23 https://lkml.org/lkml/2014/1/12/29
commit
Исправлено в ядре 3.14-rc1
L0139 Утечка staging: wlan-ng: исправление утечек на путях обработки ошибок в prism2sta_probe_usb() 2014-01-11 https://lkml.org/lkml/2014/1/10/503
commit
Исправлено в ядре 3.14-rc1
L0127 Утечка drivers/net/can/usb/peak_usb/pcan_usb_core.c: утечка памяти на ошибочных путях в peak_usb_start() 2013-09-20 https://lkml.org/lkml/2013/9/4/550
commit
Исправлено в ядре 3.12-rc2
L0153 Утечка carl9170: утечки памяти в carl9170_usb_probe() 2014-05-22 https://lkml.org/lkml/2013/9/27/601
commit
Исправлено в ядре 3.16-rc1
L0128 Утечка drivers/net/wireless/p54/p54usb.c: утечка на ошибочном пути в p54u_load_firmware() 2013-09-26 https://lkml.org/lkml/2013/9/17/380
commit
Исправлено в ядре 3.12-rc2
L0125 Утечка drivers/net/irda/mcs7780.c: утечки памяти в mcs_net_open() 2013-09-13 https://lkml.org/lkml/2013/9/12/631
commit
Исправлено в ядре 3.12-rc1
L0122 Утечка drivers/media/usb/gspca/gspca.c: некорректная обработка ошибок в dev_open() 2013-08-21 https://lkml.org/lkml/2013/8/5/510
commit
Исправлено в ядре 3.11-rc3
L0119 Несогласованность drivers/net/wireless/hostap/hostap_main.c: некорректный код возврата на ошибочном пути в prism2_open() 2013-08-05 https://lkml.org/lkml/2013/8/4/181
commit
Исправлено в ядре 3.11-rc2
L0124 Падение drivers/net/wireless/rtl818x/rtl8187/dev.c: использование после освобождения на ошибочном пути в rtl8187_init_urbs() 2013-09-09 https://lkml.org/lkml/2013/8/31/190
commit
Исправлено в ядре 3.12-rc1
L0121 Падение drivers/net/irda/via-ircc.c: некорректный код возврата при неудачном завершении via_ircc_open() 2013-08-20 https://lkml.org/lkml/2013/8/16/388
commit
Исправлено в ядре 3.11-rc7
L0120 Предупреждение drivers/usb/gadget/amd5536udc.c: возможное неатомарное выделение памяти при удержании спин-блокировки в udc_queue() 2013-08-09 https://lkml.org/lkml/2013/8/1/502
commit
Исправлено в ядре 3.11-rc4
L0117 Утечка drivers/net/can/usb/usb_8dev.c: утечка urb на ошибочном пути в usb_8dev_start() 2013-07-19 https://lkml.org/lkml/2013/7/17/595
commit
Исправлено в ядре 3.11-rc2
L0129 Утечка drivers/media/usb/ttusb-dec/ttusb_dec.c: некорректная обработка ошибок в ttusb_dec_probe() 2013-10-03 https://lkml.org/lkml/2013/7/13/135
commit
Исправлено в ядре 3.12-rc3
L0116 Несогласованность drivers/net/wireless/ath/ath9k/hif_usb.c: гонка между функцией обработчиком request_firmware_nowait() и suspend() 2013-07-17 https://lkml.org/lkml/2013/7/1/520
commit
Исправлено в ядре 3.11-rc2
L0108 Несогласованность tty/serial/sirf: некорректное формирование кода ошибки в sirfsoc_uart_probe() 2013-06-06 https://lkml.org/lkml/2013/6/5/893
commit
Исправлено в ядре 3.10-rc4
L0107 Несогласованность USB: init_usb_class() возвращает IS_ERR(p) вместо PTR_ERR(p) 2013-06-06 https://lkml.org/lkml/2013/6/5/738
commit
Исправлено в ядре 3.10-rc4
L0106 Несогласованность GFS2: некорректное формирование кода ошибки в init_threads() 2013-06-06 https://lkml.org/lkml/2013/6/5/724
commit
Исправлено в ядре 3.10-rc5
L0118 Несогласованность drivers/media/usb/tlg2300/pd-main.c: некорректная обработка ошибок в poseidon_probe() 2013-07-26 https://lkml.org/lkml/2013/6/24/521
commit
Исправлено в ядре 3.11-rc3
L0112 Утечка drivers/staging/media/lirc/lirc_imon.c: утечки в imon_probe() 2013-06-17 https://lkml.org/lkml/2013/6/2/127
commit
Исправлено в ядре 3.10-rc2
L0114 Несогласованность drivers/staging/media/go7007/go7007-usb.c: некорректный код возврата для неподдерживаемых устройств в go7007_usb_probe() 2013-06-21 https://lkml.org/lkml/2013/6/19/608
commit
Исправлено в ядре 3.10-rc7
L0111 Утечка drivers/net/wireless/orinoco/orinoco_usb.c: утечка в ezusb_access_ltv() при отключении устройства 2013-06-14 https://lkml.org/lkml/2013/6/13/476
commit
Исправлено в ядре 3.10-rc2
L0113 Утечка drivers/media/usb/usbvision/usbvision-video.c: утечка alt_max_pkt_size 2013-06-21 https://lkml.org/lkml/2013/6/10/504
commit
Исправлено в ядре 3.10-rc7
L0115 Утечка drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c: утечка в ttusb_probe() 2013-06-21 https://lkml.org/lkml/2013/6/10/432
commit
Исправлено в ядре 3.10-rc7
L0110 Утечка drivers/staging/ft1000/ft1000-usb/ft1000_usb.c: утечка на ошибочном пути в ft1000_probe() 2013-06-12 https://lkml.org/lkml/2013/6/10/412
commit
Исправлено в ядре 3.10-rc6
L0103 Несогласованность Экспортируемые inline функции 2013-05-09 https://lkml.org/lkml/2013/5/9/105
commit 1, commit 2, commit 3, commit 4, commit 5, commit 6, commit 7, commit 8, commit 9
Исправлено в ядре 3.10, 3.11, 3.13
L0105 Падение [media] wl128x: copy_to_user() не допускается вызывать с захваченным spinlock 2013-05-21 https://lkml.org/lkml/2013/5/7/682
commit
Исправлено в ядре 3.10-rc2
F0005 Падение ext4: зависание системы ввиду некорректной обработки нехватки памяти в ext4_mb_new_preallocation() 2013-07-01 https://lkml.org/lkml/2013/5/5/64
commit
Исправлено в kernel 3.10-rc3
L0109 Несогласованность usb: gadget: r8a66597-udc: разблокировка незахваченного спинлока в r8a66597_sudmac_irq() 2013-06-10 https://lkml.org/lkml/2013/5/29/667
commit
Исправлено в ядре 3.10-rc4
F0003 Падение jfs: ошибки в jfs_freeze() и jfs_unfreeze() 2013-05-24 https://lkml.org/lkml/2013/5/24/76
commit
Исправлено в kernel 3.10-rc3
F0004 Блокировка ext4: взаимная блокировка после нехватки памяти в ext4_init_io_end() 2013-06-04 https://lkml.org/lkml/2013/5/13/426
commit
Исправлено в kernel 3.10-rc3
L0099 Падение NFC: pn533: Пропущен вызов usb_put_dev() 2013-04-11 https://lkml.org/lkml/2013/5/1/292
commit
Исправлено в ядре 3.10-rc1
L0102 Падение hfs: Отсутствует проверка возвращаемого значения для hfs_find_init() 2013-05-01 https://lkml.org/lkml/2013/4/9/522
commit
Исправлено в ядре 3.10-rc1
L0098 Падение staging: dgrp: Отсутствует обработка ошибок в функции dgrp_create_class_sysfs_files() 2013-04-05 https://lkml.org/lkml/2013/4/5/479
commit
Исправлено в ядре 3.10-rc1
L0101 Падение usb: phy: Экспортируемая функция в __init секции 2013-04-23 https://lkml.org/lkml/2013/4/29/248
commit
Исправлено в ядре 3.10-rc1
L0104 Падение wlags49_h2: обработка ошибок в pcmcia probe функции 2013-05-13 https://lkml.org/lkml/2013/4/23/557
commit
Исправлено в ядре 3.10-rc2
L0100 Падение [media] cx88: Небезопасная блокировка в suspend-resume функциях 2013-04-22 https://lkml.org/lkml/2013/4/13/144
commit
Исправлено в ядре 3.10-rc1
L0097 Падение SUNRPC/cache: Пропущен вызов module_put() на ошибочном пути в функции cache_open() 2013-04-03 https://lkml.org/lkml/2013/3/22/501
commit
Исправлено в ядре 3.10-rc1
L0094 Падение usb: cdc-acm: Неправильная обработка ошибок в acm_probe() 2013-03-21 https://lkml.org/lkml/2013/3/15/585
commit
Исправлено в kernel 3.9-rc4
L0093 Утечка isdn: hisax: Пропущен usb_free_urb 2013-02-26 https://lkml.org/lkml/2013/3/10/256
commit
Исправлено в kernel 3.9-rc2
L0096 Падение drbd: Пропущен вызов module_put() на ошибочном пути в функции drbd_proc_open() 2013-03-28 https://lkml.org/lkml/2013/3/1/550
commit
Исправлено в ядре 3.10-rc1
L0089 Утечка pcmcia: synclink_cs: Неверная обработка ошибок в mgslpc_probe() 2013-02-08 https://lkml.org/lkml/2013/2/6/701
commit
Исправлено в kernel 3.9-rc1
L0095 Падение [media] stv090x: Разблокировка незахваченного мьютекса в функции stv090x_sleep() 2013-03-24 https://lkml.org/lkml/2013/2/19/468
commit
Исправлено в ядре 3.10-rc1
L0092 Утечка tty: mxser: Неправильная обработка ошибок в mxser_probe() и mxser_module_init() 2013-02-18 https://lkml.org/lkml/2013/2/16/141
commit
Исправлено в kernel 3.9-rc1
L0091 Падение ALSA: ali5451: Неправильное включение прерываний 2013-02-11 https://lkml.org/lkml/2013/2/11/259
commit
Исправлено в kernel 3.9-rc1
L0090 Падение ALSA: rme32.c Включение прерываний после spin_lock_irq 2013-02-11 https://lkml.org/lkml/2013/2/11/237
commit
Исправлено в kernel 3.9-rc1
L0088 Падение stmmac: stmmac_pci_probe() возвращает ноль в случае ошибки 2013-02-03 https://lkml.org/lkml/2013/2/1/613
commit
Исправлено в kernel 3.9-rc1
L0136 Утечка can: ems_usb: исправление утечек urb на путях обработки ошибок 2013-12-17 https://lkml.org/lkml/2013/12/6/862
commit
Исправлено в ядре 3.13-rc5
L0138 Утечка [media] as102: исправление утечек на путях обработки ошибок в as102_usb_probe() 2014-01-07 https://lkml.org/lkml/2013/12/27/199
commit
Исправлено в ядре 3.14-rc1
L0142 Утечка [media] go7007-loader: исправление утечки usb_dev 2014-02-04 https://lkml.org/lkml/2013/12/20/578
commit
Исправлено в ядре 3.14-rc2
L0141 Падение RxRPC: не освобождать незахваченную спин-блокировку в rxrpc_connect_exclusive() 2014-01-26 https://lkml.org/lkml/2013/12/13/564
commit
Исправлено в ядре 3.14-rc1
L0135 Предупреждение libertas sdio: требование устройства перед вызовом sdio_disable_func() 2013-12-05 https://lkml.org/lkml/2013/11/18/474
commit
Исправлено в ядре 3.14-rc1
L0133 Утечка staging: gdm724x: исправление утечки на ошибочном пути в gdm_usb_probe() 2013-11-26 https://lkml.org/lkml/2013/11/15/403
commit
Исправлено в ядре 3.14-rc1
L0130 Утечка drivers/staging/gdm724x/gdm_mux.c: утечка памяти на ошибочном пути 2013-10-11 https://lkml.org/lkml/2013/10/8/645
commit
Исправлено в ядре 3.12-rc5
L0131 Утечка drivers/media/usb/cx231xx/cx231xx-cards.c: повторное освобождение и утечки на ошибочном пути в cx231xx_usb_probe() 2013-10-17 https://lkml.org/lkml/2013/10/7/569
commit
Исправлено в ядре 3.12-rc3
L0132 Утечка drivers/usb/wusbcore/cbaf.c: утечки usb_dev 2013-10-19 https://lkml.org/lkml/2013/10/18/492
commit
Исправлено в ядре 3.12-rc7
L0087 Падение mwifiex: mwifiex_pcie_init() возвращает ноль в случае ошибки 2013-01-30 https://lkml.org/lkml/2013/1/25/611
commit
Исправлено в kernel 3.9-rc1
L0086 Падение iwlegacy: il4965_pci_probe() возвращает ноль в случае ошибки 2013-01-22 https://lkml.org/lkml/2013/1/19/76
commit
Исправлено в kernel 3.9-rc1
L0085 Падение mwl8k: mwl8k_probe[_hw]() возвращает 0 в случае неудачи 2013-01-22 https://lkml.org/lkml/2013/1/18/525
commit
Исправлено в kernel 3.9-rc1
L0078 Падение jffs2: преждевременная разблокировка erase_completion_lock 2012-11-05 https://lkml.org/lkml/2013/1/15/940
commit
Исправлено в kernel 3.8-rc1
L0084 Падение staging: ced1401: GFP_KERNEL используется в атомарном контексте 2013-01-11 https://lkml.org/lkml/2013/1/11/100
commit
Исправлено в kernel 3.9-rc1
L0083 Падение p54pci: p54p_probe() сообщает об успехе, когда это не так 2013-01-07 https://lkml.org/lkml/2013/1/1/36
commit
Исправлено в kernel 3.9-rc1
L0072 Падение staging: sbe-2t3e3: проблемы с обработкой ошибок в t3e3_init_channel() 2012-10-01 https://lkml.org/lkml/2012/9/25/296
commit
Исправлено в kernel 3.7-rc1
L0073 Падение pcmcia: synclink_cs: fix potential tty NULL dereference 2012-10-01 https://lkml.org/lkml/2012/9/13/556
commit
Исправлено в kernel 3.7-rc1
L0071 Падение USB: omninet: разыменование нулевого указателя 2012-10-01 https://lkml.org/lkml/2012/9/13/497
commit
Исправлено в kernel 3.7-rc1
L0067 Утечка staging: bcm: утечка ресурсов в bcm_init() 2012-10-01 https://lkml.org/lkml/2012/9/1/97
commit
Исправлено в kernel 3.7-rc1
L0068 Падение ppdev: ppdev_init() возвращает 0 в случае ошибки 2012-10-01 https://lkml.org/lkml/2012/9/1/94
commit
Исправлено в kernel 3.7-rc1
L0069 Утечка virtio: console: некорректная обработка ошибок в init() функции 2012-10-01 https://lkml.org/lkml/2012/9/1/85
commit
Исправлено в kernel 3.7-rc1
L0061 Падение bio: потенциальная утечка памяти в bio_find_or_create_slab() 2012-09-01 https://lkml.org/lkml/2012/8/9/29
commit
Исправлено в kernel 3.6-rc4
L0064 Падение exofs: потенциальное разыменование нулевого указателя в uri_store() 2012-10-01 https://lkml.org/lkml/2012/8/8/369
commit
Исправлено в kernel 3.7-rc1
L0056 Утечка rndis_wlan: Потенциальная утечка памяти в update_pmkid() 2012-08-12 https://lkml.org/lkml/2012/8/8/336
commit
Исправлено в kernel 3.6-rc2
L0066 Падение can: softing: потенциальная утечка памяти в softing_load_fw() 2012-10-01 https://lkml.org/lkml/2012/8/8/316
commit
Исправлено в kernel 3.6-rc5
L0062 Падение wusb: потенциальная утечка памяти в wusb_dev_sec_add() 2012-10-01 https://lkml.org/lkml/2012/8/8/213
commit
Исправлено в kernel 3.7-rc1
L0053 Утечка net/core: потенциальная утечка памяти в dev_set_alias() 2012-08-08 https://lkml.org/lkml/2012/8/8/171
commit
Исправлено в kernel 3.6-rc2
L0060 Падение drivers/rtc/rtc-pcf2123.c: Инициализация динамических sysfs атрибутов 2012-08-21 https://lkml.org/lkml/2012/8/8/167
commit
Исправлено в kernel 3.6-rc3
L0058 Утечка iio/adjd_s311: Потенциальная утечка памяти в adjd_s311_update_scan_mode() 2012-08-16 https://lkml.org/lkml/2012/8/8/153
commit
Исправлено в kernel 3.6-rc2
L0063 Падение USB: whci-hcd: потенциальная утечка памяти в qset_add_urb_sg() 2012-10-01 https://lkml.org/lkml/2012/8/8/120
commit
Исправлено в kernel 3.7-rc1
L0059 Падение tcm_fc: Исправлен rcu_dereference вне секции rcu lock/unlock 2012-08-20 https://lkml.org/lkml/2012/8/18/57
commit
Исправлено в kernel 3.6-rc3
L0070 Утечка ddbridge: утечка ресурсов в module_init_ddbridge() 2012-10-01 https://lkml.org/lkml/2012/8/15/475
commit
Исправлено в kernel 3.7-rc1
L0065 Падение HID: hidraw: проблемы с обработкой ошибок в hidraw_init() 2012-10-01 https://lkml.org/lkml/2012/8/15/407
commit
Исправлено в kernel 3.7-rc1
L0077 Падение ath6kl: нет проверки возвращаемого значения функции usb_register() 2012-10-14 https://lkml.org/lkml/2012/8/14/50
commit
Исправлено в kernel 3.8-rc1
L0076 Предупреждение md/linear: rcu-разыменование вне секции read-lock 2012-10-11 https://lkml.org/lkml/2012/8/13/674
commit
Исправлено в kernel 3.7-rc1
L0057 Падение bridge: Исправлен rcu_dereference вне rcu_read_lock 2012-08-15 https://lkml.org/lkml/2012/8/13/598
commit
Исправлено в kernel 3.6-rc2
L0055 Падение macvtap: rcu_dereference вне секции чтение-захват 2012-08-12 https://lkml.org/lkml/2012/8/12/13
commit
Исправлено в kernel 3.6-rc2
L0074 Падение usb: gadget: mv_udc: выделение памяти с флагом GFP_KERNEL в build_dtd() вызываемой из обработчика прерываний 2012-10-01 https://lkml.org/lkml/2012/7/5/567
commit
Исправлено в kernel 3.7-rc1
L0052 Падение forcedeth: исправлен spin_unlock_irq в обработчике прерывания 2012-07-20 https://lkml.org/lkml/2012/7/20/409
commit
Исправлено в kernel 3.6-rc1
L0051 Падение drxk: освобождение незахваченного мьютекса в scu_command() 2012-04-05 https://lkml.org/lkml/2012/4/5/373
commit
Исправлено в kernel 3.4-rc4
L0050 Падение dib9000: отсутствие обработки ошибок DibAcquireLock 2012-03-19 https://lkml.org/lkml/2012/3/6/446
commit
Исправлено в kernel 3.5-rc5
L0049 Падение dib9000: исправлено явное несоответствие lock’а 2012-03-19 https://lkml.org/lkml/2012/3/6/444
commit
Исправлено в kernel 3.5-rc5
L0048 Блокировка staging: go7007: мьютекс может остаться захваченным в [read|write]_reg_fp 2012-03-08 https://lkml.org/lkml/2012/2/13/201
commit
Исправлено в kernel 3.5-rc5
L0082 Падение mei: несоответствие в блокировке мьютекса в mei_amthif_read() 2012-12-21 https://lkml.org/lkml/2012/12/23/9
commit
Исправлено в kernel 3.8-rc4
L0081 Утечка mmc: vub300: отсутствует usb_put_dev() на ошибочном пути в vub300_probe() 2012-11-27 https://lkml.org/lkml/2012/12/10/692
commit
Исправлено в kernel 3.8-rc1
L0079 Падение extcon: arizona: отсутствие разблокировки мьютекса на ошибочном пути в arizona_micdet() 2012-11-05 https://lkml.org/lkml/2012/11/4/157
commit
Исправлено в kernel 3.8-rc1
F0002 Падение ext4: разыменование нулевого указателя в ext4_calculate_overhead() 2012-11-28 https://lkml.org/lkml/2012/11/28/354
commit
Исправлено в kernel 3.8-rc1
L0080 Падение uwb: пропуск uwb_dev_unlock() в ошибочном пути функции uwb_rc_cmd_async() 2012-11-26 https://lkml.org/lkml/2012/11/26/729
commit
Исправлено в kernel 3.8-rc1
L0041 Падение serqt_usb2: kmalloc(GFP_NOIO) вызывается при захваченном spinlock 2011-08-23 https://lkml.org/lkml/2011/8/9/23
commit
Исправлено в kernel 3.2-rc1
L0046 Падение staging: sep: вызов sep_ioctl() может привести драйвер в неиспользуемое состояние 2011-09-06 https://lkml.org/lkml/2011/8/30/391
commit
Исправлено в kernel 3.2-rc1
L0045 Падение mei: отсутствует освобождение мьютекса dev->device_lock при обработке ошибки в mei_open() 2011-09-06 https://lkml.org/lkml/2011/8/30/367
commit
Исправлено в kernel 3.2-rc1
L0043 Падение lirc: разблокировка незахваченного мьютекса в imon_probe 2011-09-06 https://lkml.org/lkml/2011/8/29/395
commit
Исправлено в kernel 3.2-rc1
L0042 Падение staging/easycap: отсутствие освобождения мьютекса на одном из путей в easycap_poll() 2011-08-29 https://lkml.org/lkml/2011/8/29/334
commit
Исправлено в kernel 3.2-rc1
L0047 Падение mpt2sas: Исправлено расхождение в mpt2sas_base_hard_reset_handler() мьютекса lock-unlock 2012-02-13 https://lkml.org/lkml/2011/8/25/577
commit
Исправлено в kernel 3.3-rc5
L0040 Падение carl9170: отсутствия блокировки мьютекса на одном из путей в carl9170_op_set_key 2011-08-23 https://lkml.org/lkml/2011/8/23/380
commit
Исправлено в kernel 3.1-rc5
L0038 Падение hfsplus: отсутствует обработка неуспешного выполнения hfs_find_init() 2011-06-24 https://lkml.org/lkml/2011/7/5/500
commit
Исправлено в kernel 3.1-rc1
L0039 Падение hfsplus: Двойной iput одного inode в hfsplus_fill_super() 2011-06-24 https://lkml.org/lkml/2011/6/23/675
commit
Исправлено в kernel 3.0
L0036 Утечка gigaset: отсутствие вызовы module_put перед перезапуском if_open() 2011-06-20 https://lkml.org/lkml/2011/6/17/321 commit 2f9381e Исправлено в kernel 3.0-rc4
L0035 Утечка drivers/net/wan/farsync.c: Вызов module_get() без module_put() на пути обработки ошибки в fst_open() 2011-06-20 https://lkml.org/lkml/2011/6/17/320 commit d0fd64c Исправлено в kernel 3.0-rc4
L0037 Утечка drivers/video/hecubafb.c: отсутствие вызова module_put на пути обработки ошибки в hecubafb_probe() 2011-06-20 https://lkml.org/lkml/2011/6/17/267
commit
Исправлено в kernel 3.0-rc6
L0031 Блокировка drivers/net/usb/catc.c: потенциальная блокировка в catc_ctrl_run() 2011-06-07 https://lkml.org/lkml/2011/5/31/504
commit
Исправлено в ядре 3.0-rc2
L0032 Утечка drivers/media/radio/si470x/radio-si470x-usb.c: утечка в si470x_usb_driver_probe() 2011-06-08 https://lkml.org/lkml/2011/5/31/483
commit
Исправлено в ядре 3.1-rc1
L0034 Падение drivers/usb/gadget/inode.c: пропущено освобождение data->lock mutex на одном из путей в ep_write() 2011-06-08 https://lkml.org/lkml/2011/5/26/58
commit
Исправлено в kernel 3.0-rc3
L0075 Блокировка mpt2sas: двойной захват мьютекса в состоянии NON_BLOCKING 2012-10-02 https://lkml.org/lkml/2011/4/18/331
commit
Исправлено в kernel 3.7-rc1
L0030 Падение drivers/media/dvb/dvb-usb/lmedm04.c: Если mutex_lock_interruptible не сработал, то мьютекс освобождать не нужно 2011-06-01 https://lkml.org/lkml/2011/4/15/306
commit
Исправлено в ядре 3.0-rc1
L0029 Падение drivers/usb/gadget/inode.c: пропущено освобождение data->lock mutex на одном из путей в ep_read() 2011-03-22 https://lkml.org/lkml/2011/3/9/37
commit
Исправлено в ядре 2.6.39-rc4
L0028 Падение drivers/input/tablet/wacom_sys.c: нет usb_free_urb на ошибочном пути 2011-02-09 https://lkml.org/lkml/2011/2/9/21
commit
Исправлено в ядре 2.6.38-rc5
L0044 Падение lirc_sasem: разыменование нулевого указателя в sasem_probe() 2011-09-06 https://lkml.org/lkml/2011/10/26/104
commit
Исправлено в kernel 3.2-rc1
L0026 Падение drivers/rtc/rtc-proc.c: отсутствует module_put после module_get on error path 2011-02-04 https://lkml.org/lkml/2011/1/28/103
commit
Исправлено в ядре 2.6.38-rc5
L0027 Падение drivers/media/video/tlg2300/pd-video.c: двойной mutex_unlock 2011-02-04 https://lkml.org/lkml/2011/1/25/478
commit
Исправлено в ядре 2.6.39-rc1
L0025 Падение drivers/media/radio/si470x/radio-si470x-common.c: двойной mutex_lock в si470x_fops_read() 2011-01-24 https://lkml.org/lkml/2011/1/23/11
commit
Исправлено в ядре 2.6.39-rc1
L0024 Падение pohmelfs/dir.c: ненужный mutex_unlock() в функции pohmelfs_rename() 2011-01-21 https://lkml.org/lkml/2011/1/19/334
commit
Исправлено в ядре 2.6.39-rc1
L0023 Падение Выход из функции без разблокировки мютекса в драйвере drivers/media/video/cx231xx/cx231xx-core.c 2010-12-13 https://lkml.org/lkml/2010/12/13/343
commit
Исправлено в kernel 2.6.37-rc1
L0022 Падение kernel/range.c: неправильная работа функции clean_sort_range() в случае полного массива 2010-12-10 https://lkml.org/lkml/2010/11/5/264
commit
Исправлено в kernel 2.6.37
L0021 Падение drivers/media/radio/radio-gemtek-pci.c: Двойной mutex_lock 2010-08-23 https://lkml.org/lkml/2009/10/8/179
commit
Исправлено в ядре 2.6.32
L0217 Падение mmc: mmc_spi: отсутствие проверки ошибок при dma mapping 2016-02-06 https://lkml.kernel.org/r/1454715395-9462-1-git-send-email-khoroshilov@ispras.ru
commit
Исправлено в ядре 4.5-rc4
L0218 Падение tty: synclinkmp: игнорирование сбоев в probe() 2016-02-06 https://lkml.kernel.org/r/1445642863-3805-1-git-send-email-khoroshilov@ispras.ru
commit
Исправлено в ядре v4.6-rc1
L0123 Падение drivers/media/usb/hdpvr/hdpvr-core.c: итерация по неинициализированным спискам в hdpvr_probe() 2013-09-03 https://linuxtv.org/patch/19152/
commit
Исправлено в ядре 3.11-rc3
L0126 Падение drivers/usb/gadget/mv_u3d_core.c: некорректная работа с блокировками в mv_u3d_ep_disable() 2013-09-17 https://groups.google.com/forum/#!topic/linux.kernel/4fDCBFQPjPA
commit
Исправлено в ядре 3.12-rc2
L0300 Утечка mfd: mxs-lradc: неотключенные часы на ошибочном пути в функции mxs_lradc_probe 2019-08-28 commit Исправлено в ядре v4.15-rc1
F0001 Падение ext4: падение в mount_fs() из-за нулевого вердикта ext4_fill_super() в случае ошибки 2012-11-08 https://bugzilla.kernel.org/show_bug.cgi?id=48431
commit
Исправлено в kernel 3.8-rc1
F0011 Падение ext4: Повреждение файловой системы, примонтированой с резервным суперблоком, при попытке изменения её размера 2014-12-27 http://www.spinics.net/lists/linux-ext4/msg46743.html
commit
Исправлено в 3.19-rc4
L0163 Утечка staging: gdm724x: утечка при обработке ошибок в init_usb() 2014-07-10 http://permalink.gmane.org/53550
commit
Исправлено в ядре 3.17-rc1
L0134 Блокировка [media] dvb_demux: исправление взаимной блокировки в dmx_section_feed_release_filter() 2013-11-29 http://lkml.org/lkml/2013/8/17/68
commit
Исправлено в ядре 3.13-rc4
L0054 Утечка drm/edid: Исправлена потенциальная утечка памяти в edid_load() 2012-08-10 http://lkml.org/lkml/2012/8/7/216
commit
Исправлено в kernel 3.6-rc2
L0019 Падение drivers/mtd/mtd_blkdevs.c: Небезопасный вызов функции module_put 2010-01-26 http://lkml.org/lkml/2010/1/12/246
commit
Исправлено в ядре 2.6.35
L0001 Падение drivers/media/video/cafe_ccic.c: Нарушен баланс блокировки mutex’ов в функции cafe_pci_probe 2009-09-10 http://lkml.org/lkml/2009/9/10/167
commit
Исправлено в ядре 2.6.34
L0002 Утечка fs/cifs/cifsencrypt.c: Утечка памяти 2009-09-14 http://lkml.org/lkml/2009/8/11/210
commit
Исправлено в ядре 2.6.32
L0004 Утечка security/selinux/hooks.c: В функции inode_doint_with_dentry() не освобождается память перед выходом 2009-09-14 http://lkml.org/lkml/2009/8/10/119
commit
Исправлено в ядре 2.6.31
L0003 Падение drivers/media/video/hdpvr/hdpvr-core.c(hdpvr-video.c): Нарушен баланс блокировки мютекса 2009-09-14 http://lkml.org/lkml/2009/6/19/274
commit
Исправлено в ядре 2.6.32
L0018 Падение drivers/net/hamradio/yam.c: Разыменование нулевого указателя 2009-12-23 http://lkml.org/lkml/2009/12/21/140
commit
Исправлено в kernel 2.6.35-rc1
L0017 Падение drivers/usb/misc/sisusbvga/sisusb.c: Разыменование нулевого указателя 2009-12-23 http://lkml.org/lkml/2009/12/21/135
commit
Исправлено в ядре 3.10-rc1
L0016 Падение drivers/usb/mos7840.c: Разыменование нулевого указателя 2009-12-23 http://lkml.org/lkml/2009/12/21/131
commit
Исправлено в kernel 2.6.35-rc2
L0014 Падение drivers/net/3c507.c: Разыменование нулевого указателя 2009-12-22 http://lkml.org/lkml/2009/12/21/120
commit
Исправлено в kernel 2.6.35-rc1
L0013 Падение drivers/ata/sata_mv.c: Разыменование нулевого указателя в драйвере 2009-12-22 http://lkml.org/lkml/2009/12/14/237
commit
Исправлено в ядре 2.6.33
L0010 Падение drivers/net/irda/ali-ircc.c: Двойная блокировка spin_lock_irqsave 2009-10-08 http://lkml.org/lkml/2009/10/8/113
https://lkml.org/lkml/2015/9/11/613
commit
Исправлено в ядре 4.3-rc3
L0009 Падение drivers/net/znet.c: Вызов функции might_sleep из контекста spin_lock_irqsave/spin_unlock_irqrestore 2009-10-08 http://lkml.org/lkml/2009/10/7/317
commit
Исправлено в ядре 2.6.32
L0007 Падение drivers/char/isicom.c: Вызов функции might_sleep из контекста spin_lock_irqsave/spin_unlock_irqrestore 2009-10-08 http://lkml.org/lkml/2009/10/7/246
commit
Исправлено в ядре 2.6.33-rc1
L0008 Падение drivers/media/video/usbvideo/koniacwc.c: Возможно переполнение cam->input_physname, при использовании strncat (неверно задан третий параметр) 2009-10-08 http://lkml.org/lkml/2009/10/7/218
commit
Исправлено в ядре 2.6.33-rc1
L0006 Падение drivers/media/video/usbvideo/quickcam_messenger.c: Возможно переполнение cam->input_physname, при использовании strncat (неверно задан третий параметр) 2009-10-07 http://lkml.org/lkml/2009/10/7/217
commit
Исправлено в ядре 2.6.33-rc1
L0012 Падение drivers/input/input.c: Возможен вызов mutex_lock без последующего mutex_unlock 2009-10-14 http://lkml.org/lkml/2009/10/13/353
commit
Исправлено в ядре 2.6.32
L0011 Падение drivers/hid/hidraw.c: Двойной mutex_lock 2009-10-13 http://lkml.org/lkml/2009/10/12/101
commit
Исправлено в ядре 2.6.35
L0198 Утечка [media] sh_vou: Утечка памяти при обработке ошибок в sh_vou_open() 2015-07-21 http://lkml.iu.edu/hypermail/linux/kernel/1502.1/03560.html
commit
Исправлено в ядре 4.2-rc8
F0006 Блокировка f2fs: взаимная блокировка в mkdir при активированном ACL 2013-10-28 https://lkml.org/lkml/2013/10/26/163
commit
Исправлено в kernel 3.12-rc3
L0177 Падение ath6kl: двойное освобождение памяти из-за ath6kl_usb_pm_reset_resume() 2014-11-29 http://lists.openwall.net/netdev/2014/10/24/102
commit
Исправлено в ядре 3.19-rc1
L0188 Падение staging: vt6656: успешный код возврата в случае ошибки в vt6656_probe() 2015-03-20 http://lists.openwall.net/linux-kernel/2015/03/13/908
commit
Исправлено в ядре 4.1-rc1
L0286 Падение hwmon:(stts751) выход за границы буфера в результате некорректной информации предоставленной устройством 2017-08-15 http://linuxtesting.org/pipermail/ldv-project/2017-August/000894.html
commit
Исправлено в ядре 4.14-rc1
L0242 Падение USB: serial: mos7840: выделение памяти с флагом GFP_KERNEL в атомарном контексте 2016-08-15 http://linuxtesting.org/pipermail/ldv-project/2016-August/000677.html
commit
Исправлено в ядре 4.8-rc5
L0241 Падение USB: serial: mos7720: выделение памяти с флагом GFP_KERNEL в атомарном контексте 2016-08-15 http://linuxtesting.org/pipermail/ldv-project/2016-August/000676.html
commit
Исправлено в ядре 4.8-rc5
L0211 Падение USB: whci-hcd: отсутствие проверок ошибки при dma mapping 2015-12-01 http://linuxtesting.org/pipermail/ldv-project/2015-November/000558.html
commit
Исправлено в ядре 4.4-rc5
L0200 Утечка [media] usbvision: Утечка usb_dev при обработке ошибок в usbvision_probe() 2015-07-21 http://linuxtesting.org/pipermail/ldv-project/2015-March/000482.html
commit
Исправлено в ядре 4.2-rc8
L0170 Утечка dm log userspace: утечка памяти при обработке ошибок в dm_ulog_tfr_init() 2014-10-01 http://linuxtesting.org/pipermail/ldv-project/2014-October/000370.html
commit
Исправлено в ядре 3.18-rc1
L0165 Падение NFS: add checks for returned value of try_module_get() 2014-08-03 https://lkml.org/lkml/2014/7/17/688
commit
Исправлено в ядре 3.17-rc1
L0166 Падение usb: dbgp gadget: использование после освобождения в dbgp_unbind() 2014-08-19 http://linuxtesting.org/pipermail/ldv-project/2014-August/000359.html
commit
Исправлено в ядре 3.17-rc3
L0015 Падение drivers/net/hamradio/bpqether.c: Разыменование нулевого указателя 2009-12-23 http://kerneltrap.org/mailarchive/linux-netdev/2009/12/15/6264106
commit
Исправлено в kernel 2.6.33-rc4
L0005 Падение drivers/gpu/drm/drm_gem.c: Возможно падение на assert’е BUG_ON(!mutex_is_locked(&dev->struct_mutex)) в drm_gem_object_free 2009-09-18 http://bugzilla.kernel.org/show_bug.cgi?id=13227
commit
Исправлено в kernel 2.6.34-rc1
S0842 Несоответствие стандарту Функция readlink() устанавливает errno в EINVAL вместо ENOENT 2011-08-21 Исправлено в kernel 3.2-rc1

Copyright © 2005-2023
Институт системного программирования им. В.П. Иванникова Российской Академии Наук
All Rights Reserved

Hw cdcacm sys как удалить

Основные технические характеристики
Процессор STi7105
Оперативная память 256 Мбайт
Флэш-память 128 Мбайт
Операционная система linux 2.6.35
Файловые системы FAT16/32, NFS, Ext2, Ext3
Видео режимы 1080i, 1080p, 720p, 576p, 480р, PAL, NTSC
Поддерживаемые Middleware SmartLabs; CTI TVE; IPTV Portal; Cubiware CubiTV
Поддерживаемые VoD Espial-Kasenna, Bitband, ARRIS (C-COR), Live555
Источники контента
Телевизионные потоки HTTP, UDP/RTP уникаст/мультикаст
Цифровые носители информации внешний HDD, USB флэш-накопитель, USB-кард-ридер и т.д.
Видеопотоки полученные из локальной домашней сети
Потоки из глобальной сети SMB, NFS, UPnP, HTTP
Поддержка форматов контента
Видео форматы MKV, MPEG-TS, MPEG-PS, M2TS, VOB, AVI, MOV, MP4, ASF, QT
Видео кодеки MPEG-1 layer I/II, MPEG-2 layer II, MPEG-2 layer III (mp3), MPEG-2 AAC, MPEG-4 AAC, MPEG-4 AAC+SBR
Аудио форматы MP3, MPA, M4A, OGG, WAV, AC3, AAC
Форматы изображений JPEG, PNG, BMP, GIF
Субтитры DVB, встроенные текстовые
Форматы плейлистов M3U
Протоколы медиа-потоков RTSP, RTP, UDP, IGMP,HTTP
Интерфейсы
1 х HDMI 1.3а
1 х USB 2.0
1 х A/V выход Jack 3.5 mm
1 х RJ-45/Fast Ethernet
Поддерживаемые движки браузера
WebKit, Opera, Ekioh
Поддерживаемый DRM/CAS
Verimatrix
Источник питания
5VDC/2А

Прикрепленное изображение

Прикрепленное изображение

Драйвера и утилиты

Драйвер: PL2303_Prolific_AllInOne_1013.exe
Терминал: putty.exe
Терминал UDP firmware: RTnorm v1.30 от APK2013
Импорт плейлистов: M3U2 SMLBOX.NET Утилита для портала SMLBOX.NET

Официальные прошивки

WINK 7.15.28New!

Rostelecom
Кастомные прошивки
OBOX не работает

Прекращена работа с 15.04.2022 года.
OBOX 5.24246.191016

— предназначен для EDEM TV

SmlBox не работает

Прекращена работа с 15.04.2022 года.
SMLBOX 5.24246.191016 — Актуальная

Серым цветом помечены неработоспособные версии

Итоги голосования

Прикрепленное изображение

Инструкция прошивки MODRT
Инструкция прошивки MODRT

1. Приобретаем конвертер USB-RS232 UART TTL . Устанавливаем драйвер PL2303_Prolific_AllInOne_1013.exe.
2. разбираем приставку, припаиваем ноги конвертера к приставке: gnd -> gnd, tx -> rx, rx -> tx
3. подключаем конвертер в USB, в диспетчере устройств в пункте Порты (COM и LTP) появится устройство «Prolific USB-To-Serial Comm Port«, смотрим к какому COM порту он привязался.
3.1. Диспетчер устройств => Порты (COM и LTP). Смотрим какой порт назначен на TTL.
4. Запускаем Putty.com, выбираем «Serial», вписываем COM-порт конвертера и скорость 115200. Сохраняем и соединяемся.
5. Включаем в сеть приставку и зажимаем «0», в черном окне должны побежать данные и появиться

Hit any key to stop autoboot: 0
ST7105>

отжимаем «0».
6. Вводим команды:
Для того чтобы в дальнейшем автоматически не обновлялась прошивка из сети Ростелекома

setenv firmware_version 5.24302.99 (указываем номер актуальной версии)
saveenv
usb reset
fatload usb 0:1 80000000 kernel.bin
ждём сообщения:
8388608 byte read
ST7105>
bootm 80000000

Ждём когда покажет сообщение:

1. Boot from NFS share
2. Boot from FLASH memory
3. Force upgrade with any firmware
4. Erase «env» partition and reboot
0. Stop booting
R. Reboot

7. Жмем «0»
Приставка чуть прогрузится и запросит данные ROOT:
Логин: root ; пароль: len42?enjoy

8. Теперь монтируем флешку командой:

mkdir /tmp/sda; mount `ls -t /dev/sd* | tail -n1` /tmp/sda; cd /tmp/sda; ls

9. Проверяем таблицу разделов:
cat /proc/mtd

10. Прошиваем
X.XXXXX.XXXXXАктуальная версия прошивки
Приставка ревизии С4

flashcp -v rootfs_mod.jffs2 /dev/mtd6
flashcp -v rootfs_mod.bin /dev/mtd6
fw_setenv firmware_version 5.24302.99

Приставка ревизии 2.2

dd if=rootfs_mod.jffs2 of=/dev/mtd5
dd if=rootfs_mod.bin of=/dev/mtd5
fw_setenv firmware_version 5.24302.99 (указываем номер актуальной версии)

Строго следовать, инструкции прошивки приставок с REV.C4 или REV.2.2 между собой не совместимы и могут вызвать фатальные ошибки .
Внимательно смотрим на плату и ищем крупные надписи rev 2.2 и PS105- C4 , и скачиваем соответствующию ревизии прошивку.
Для приставок с ревизией 3.2 прошиваете на свой страх и риск.

У кого не прошивается попробуйте эти команды.


Затираем раздел командой и не забываем пользоваться командой cat /proc/mtd для определения где располагается «rootfs«

Для rev. 2.2
flash_eraseall /dev/mtd5
или
Для rev. C4
flash_eraseall /dev/mtd6

Прошиваем альтернативными командами.

dd if=rootfs_mod.bin of=/dev/mtdblock5
или
dd if=rootfs_mod.bin of=/dev/mtdblock6

flashcp -v rootfs_mod.bin /dev/mtd5
или
flashcp -v rootfs_mod.bin /dev/mtd6

Инструкция прошивки SMLBOX
Инструкция прошивки SMLBOX

1. Приобретаем конвертер USB-RS232 UART TTL . Устанавливаем драйвер PL2303_Prolific_AllInOne_1013.exe.
2. разбираем приставку, припаиваем ноги конвертера к приставке: gnd -> gnd, tx -> rx, rx -> tx
3. подключаем конвертер в USB, в диспетчере устройств появится устройство «Prolific USB-To-Serial Comm Port», смотрим к какому COM порту он привязался.
4. Запускаем Putty.com, выбираем «Serial», вписываем COM-порт конвертера и скорость 115200. Соединяемся.
5. Включаем в сеть приставку и зажимаем «0», в черном окне должны побежать данные и появиться

Hit any key to stop autoboot: 0
ST7105>

отжимаем «0».
6. Вводим команды:
Для того чтобы в дальнейшем автоматически не обновлялась прошивка из сети Ростелекома

setenv firmware_version 5.24302.99 (указываем номер актуальной версии)
saveenv
usb reset
fatload usb 0:1 80000000 kernel.bin
ждём сообщения:
8388608 byte read
ST7105>
bootm 80000000

Ждём когда покажет сообщение:

1. Boot from NFS share
2. Boot from FLASH memory
3. Force upgrade with any firmware
4. Erase «env» partition and reboot
0. Stop booting
R. Reboot

7. Жмем «0»
Приставка чуть прогрузится и запросит данные ROOT:
Логин: root ; пароль: len42?enjoy

8. Теперь монтируем флешку командой:

mkdir /tmp/sda; mount `ls -t /dev/sd* | tail -n1` /tmp/sda; cd /tmp/sda

9. Обязательно смотрим таблицу разделов под каким номером блок rootfs:
cat /proc/mtd

10. Прошиваем
Приставка ревизий 2.2, 3.2, С4

flashcp -v rootfs_smlbox-ps7105.bin /dev/mtd6
flashcp -v rootfs_smlbox-ps7105.jffs2 /dev/mtd6

или в зависимости от разметки вашей ревизии приставки

dd if=rootfs_smlbox-ps7105.bin of=/dev/mtdblock5
dd if=rootfs_smlbox-ps7105.jffs2 of=/dev/mtdblock5

fw_setenv firmware_version 5.24302.99 (указываем номер актуальной версии)

Строго следовать, инструкции прошивки приставок с REV.C4 или REV.2.2 между собой не совместимы и могут вызвать фатальные ошибки .
Внимательно смотрим на плату и ищем крупные надписи rev 2.2 и 3.2 и PS105- C4 , и скачиваем соответствующий ревизии прошивку.

У кого не прошивается попробуйте эти команды.


Затираем раздел командой и не забываем пользоваться командой cat /proc/mtd для определения где располагается «rootfs«

flash_eraseall /dev/mtd5
или
flash_eraseall /dev/mtd6

Прошиваем альтернативными командами.

dd if=rootfs_smlbox-ps7105.bin of=/dev/mtdblock5
или
dd if=rootfs_smlbox-ps7105.bin of=/dev/mtdblock6

flashcp -v rootfs_smlbox-ps7105.bin /dev/mtd5
или
flashcp -v rootfs_smlbox-ps7105.bin /dev/mtd6

Инструкция прошивки OBOX
Инструкция прошивки OBOX

1. Приобретаем конвертер USB-RS232 UART TTL . Устанавливаем драйвер PL2303_Prolific_AllInOne_1013.exe.
2. разбираем приставку, припаиваем ноги конвертера к приставке: gnd -> gnd, tx -> rx, rx -> tx
3. подключаем конвертер в USB, в диспетчере устройств появится устройство «Prolific USB-To-Serial Comm Port», смотрим к какому COM порту он привязался.
4. Запускаем Putty.com, выбираем «Serial», вписываем COM-порт конвертера и скорость 115200. Соединяемся.
5. Включаем в сеть приставку и зажимаем «0», в черном окне должны побежать данные и появиться

Hit any key to stop autoboot: 0
ST7105>

отжимаем «0».
6. Вводим команды:
Для того чтобы в дальнейшем автоматически не обновлялась прошивка из сети Ростелекома

setenv firmware_version 5.24302.99 (указываем номер актуальной версии)
saveenv
usb reset
fatload usb 0:1 80000000 kernel.bin
ждём сообщения:
8388608 byte read
ST7105>
bootm 80000000

Ждём когда покажет сообщение:

1. Boot from NFS share
2. Boot from FLASH memory
3. Force upgrade with any firmware
4. Erase «env» partition and reboot
0. Stop booting
R. Reboot

7. Жмем «0»
Приставка чуть прогрузится и запросит данные ROOT:
Логин: root ; пароль: len42?enjoy

8. Теперь монтируем флешку командой:

mkdir /tmp/sda; mount `ls -t /dev/sd* | tail -n1` /tmp/sda; cd /tmp/sda

9. Обязательно смотрим таблицу разделов под каким номером блок rootfs:
cat /proc/mtd

10. Прошиваем
Приставка ревизий 2.2, 3.2, С4

flashcp -v rootfs_obox-ps7105.bin /dev/mtd6
flashcp -v rootfs_obox-ps7105.jffs2 /dev/mtd6

или в зависимости от разметки вашей ревизии приставки

dd if=rootfs_obox-ps7105.bin of=/dev/mtdblock5
dd if=rootfs_obox-ps7105.jffs2 of=/dev/mtdblock5

fw_setenv firmware_version 5.24302.99 (указываем номер актуальной версии)

Строго следовать, инструкции прошивки приставок с REV.C4 или REV.2.2 между собой не совместимы и могут вызвать фатальные ошибки .
Внимательно смотрим на плату и ищем крупные надписи rev 2.2 и 3.2 и PS105- C4 , и скачиваем соответствующий ревизии прошивку.

У кого не прошивается попробуйте эти команды.


Затираем раздел командой и не забываем пользоваться командой cat /proc/mtd для определения где располагается «rootfs«

flash_eraseall /dev/mtd5
или
flash_eraseall /dev/mtd6

Прошиваем альтернативными командами.

dd if=rootfs_obox-ps7105.bin of=/dev/mtdblock5
или
dd if=rootfs_obox-ps7105.bin of=/dev/mtdblock6

flashcp -v rootfs_obox-ps7105.bin /dev/mtd5
или
flashcp -v rootfs_obox-ps7105.bin /dev/mtd6

Инструкция прошивки 4DUK
Инструкция прошивки 4DUK

1. Приобретаем конвертер USB-RS232 UART TTL . Устанавливаем драйвер PL2303_Prolific_AllInOne_1013.exe.
2. разбираем приставку, припаиваем ноги конвертера к приставке: gnd -> gnd, tx -> rx, rx -> tx
3. подключаем конвертер в USB, в диспетчере устройств появится устройство «Prolific USB-To-Serial Comm Port», смотрим к какому COM порту он привязался.
4. Запускаем Putty.com, выбираем «Serial», вписываем COM-порт конвертера и скорость 115200. Соединяемся.
5. Включаем в сеть приставку и зажимаем «0», в черном окне должны побежать данные и появиться

Hit any key to stop autoboot: 0
ST7105>

отжимаем «0».
6. Вводим команды:
Для того чтобы в дальнейшем автоматически не обновлялась прошивка из сети Ростелекома

setenv firmware_version 5.24302.99 (указываем номер актуальной версии)
saveenv
usb reset
fatload usb 0:1 80000000 kernel.bin
ждём сообщения:
8388608 byte read
ST7105>
bootm 80000000

Ждём когда покажет сообщение:

1. Boot from NFS share
2. Boot from FLASH memory
3. Force upgrade with any firmware
4. Erase «env» partition and reboot
0. Stop booting
R. Reboot

7. Жмем «0»
Приставка чуть прогрузится и запросит данные ROOT:
Логин: root ; пароль: len42?enjoy

8. Теперь монтируем флешку командой:

mkdir /tmp/sda; mount `ls -t /dev/sd* | tail -n1` /tmp/sda; cd /tmp/sda

9. Обязательно смотрим таблицу разделов под каким номером блок rootfs:
cat /proc/mtd

10. Прошиваем
Приставка ревизий 2.2, 3.2, С4

flashcp -v rootfs_4duk-ps7105.bin /dev/mtd6
flashcp -v rootfs_4duk-ps7105.jffs2 /dev/mtd6

или в зависимости от разметки вашей ревизии приставки

dd if=rootfs_4duk-ps7105.bin of=/dev/mtdblock5
dd if=rootfs_4duk-ps7105.jffs2 of=/dev/mtdblock5

fw_setenv firmware_version 5.24302.99 (указываем номер актуальной версии)

Строго следовать, инструкции прошивки приставок с REV.C4 или REV.2.2 между собой не совместимы и могут вызвать фатальные ошибки .
Внимательно смотрим на плату и ищем крупные надписи rev 2.2 и 3.2 и PS105- C4 , и скачиваем соответствующий ревизии прошивку.

У кого не прошивается попробуйте эти команды.


Затираем раздел командой и не забываем пользоваться командой cat /proc/mtd для определения где располагается «rootfs«

flash_eraseall /dev/mtd5
или
flash_eraseall /dev/mtd6

Прошиваем альтернативными командами.

dd if=rootfs_4duk-ps7105.bin of=/dev/mtdblock5
или
dd if=rootfs_4duk-ps7105.bin of=/dev/mtdblock6

flashcp -v rootfs_4duk-ps7105.bin /dev/mtd5
или
flashcp -v rootfs_4duk-ps7105.bin /dev/mtd6

Инструкция возврата на заводскую прошивку

Для начала скачиваем официальную прошивку и firmware.bin.config, firmware_5.XXXXX.XXX.bin переименуем в firmware.bin
Для приставок производителя Промсвязь имеется возможность первичного обновления прошивки по USB

Подготовка

1. приставка из Ростелекома с ПО SmartLabs (Промсвязь).
2. USB-накопитель объемом не менее 128 MB. Это может быть как USB флеш-накопитель, так и HDD с USB-интерфейсом.
3. Файл прошивки для данной модели приставки.
4. Поместить в корень накопителя файл firmware.bin и firmware.bin.config. Например, если
накопитель подключился как диск «G:», тогда файл firmware.bin должен быть доступен по пути «G:\firmware.bin».

Обновление прошивки

5. Выключите приставку.
6. Подключите USB-накопитель с файлом firmware.bin в корне. Можно подключать в любой USB-порт, если их несколько.
7. Включите приставку.
7.1. Водим команды для обновления на заводскую прошивку:

setenv firmware_version
saveenv
boot

8. Приставка начнет обновление, если новая прошивка имеет версию выше текущей. В процессе обновления на экране отображается сообщение:
«Подождите, идет запись прошивки». Во время обновления нельзя отключать питание или извлекать USB-накопитель.
9. После успешного обновления приставка перезагрузится и запустит приложение.
10. USB-накопитель можно извлечь из приставки.
PS: Если у Вас подключено тв от Ростелекома, прошивку автоматически обновите.

По вопросам наполнения шапки обращайтесь к модераторам раздела, отправив «Жалобу» на сообщениях, ссылки на которые необходимо добавить.

Сообщение отредактировал Volkodav. — 11.03.24, 08:51

Причина редактирования: Стоковые прошивки
Скрыть опрос и шапку
14.02.18, 15:43 | #3302


Постоянный
Реп: ( 8 )
Подскажите что может быть, не выходить прошить.

Board: STx7105-PDK [32-bit mode]

U-Boot 1.3.1 (Jul 29 2013 — 15:06:15) — stm23_0046

DRAM: 256 MiB
NAND: Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x01920000
128 MiB
In: serial
Out: serial
Err: serial
Device 0: NAND 128MiB 3,3V 8-bit. is now current device
Board is not supported
MAC: *************
S/N: *************

Hit any key to stop autoboot: 0
PS7105> usb reset
(Re)start USB.
USB: scanning bus for devices. 2 USB Device(s) found
scanning bus for storage devices. 1 Storage Device(s) found
PS7105> fatload usb 0:1 80000000 kernel.bin
reading kernel.bin
.

8388608 bytes read
PS7105> bootm 80000000
## Booting image at 80000000 .
Image Name: Linux-2.6.23.17_stm23_A27-PS7105
Image Type: SuperH Linux Kernel Image (gzip compressed)
Data Size: 3314469 Bytes = 3.2 MiB
Load Address: 80800000
Entry Point: 80801000
Verifying Checksum . OK
Uncompressing Kernel Image . OK

Starting kernel hardware_version=1 — 0x00000000 — 0 .

Linux version 2.6.23.17_stm23_A27-PS7105 (jenkins@qtbuild03) (gcc version 4.2.4 (snapshot) (STMicroelectronics/Linux Base 4.2.4-52)) #6 PREEMPT Tue Sep 24 21:01:05 MSK 2013
Booting machvec: ps7105
Node 0: start_pfn = 0x40000, low = 0x48000
Zone PFN ranges:
Normal 262144 -> 294912
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 262144 -> 294912
Promsvyaz PS7105 board initialisation
STx7105 version 4.x
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: hardware_version=1 bigphysarea=4000 console=ttyAS0,115200 panic=5
PS7105 HW version 1
bpa2: partition ‘bigphysarea’ created at 0x40dfd000, size 16000 kB (0x00fa0000 B)
PID hash table entries: 512 (order: 9, 2048 bytes)
Using tmu for system timer
Using 25.000 MHz high precision timer.
Console: colour dummy device 80×25
console [ttyAS0] enabled
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 100608k/131072k available (2920k kernel code, 892k data, 1100k init)
PVR=04909200 CVR=60880000 PRR=00009e40
I-cache : n_ways=2 n_sets=512 way_incr=16384
I-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
D-cache : n_ways=2 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
SH4 450.00 BogoMIPS PRESET (lpj=225000)
Mount-cache hash table entries: 512
CPU: STx7105
NET: Registered protocol family 16
Configuring FLASH for boot-from-NAND
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pms_init: pms initialization
Time: SuperH clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
platform_add_pm_devices:
squashfs: version 3.4 (2008/08/26) Phillip Lougher
NTFS driver 2.1.28 [Flags: R/O].
JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
lirc_dev: IR Remote Control driver registered, major 61
lirc_stm: probe found data for platform device lirc
lirc_stm: STM LIRC plugin has IRQ 244 using IR-RX mode
lirc_stm: lirc_stm_calc_rx_clocks: IR clock is 100000000
lirc_stm: SCD not available in IR-RX mode. Not armed
lirc_dev: lirc_register_plugin: sample_rate: 0
STMicroelectronics LIRC driver initialized.
STMicroelectronics ASC driver initialized
stasc.0: ttyAS0 at MMIO 0xfd032000 (irq = 121) is a stasc
stasc.1: ttyAS1 at MMIO 0xfd033000 (irq = 120) is a stasc
SMSC LAN83C185: Registered new driver
SMSC LAN8187: Registered new driver
SMSC LAN8700: Registered new driver
SMSC LAN911x Internal PHY: Registered new driver
SMSC LAN8710/LAN8720: Registered new driver
platform registration. done!
GMAC — user ID: 0x10, Synopsys ID: 0x33
no valid MAC address; please, set using ifconfig or nwhwconfig!
eth0 — (dev. name: stmmaceth — id: 0, IRQ #134
IO base addr: 0xfd110000)
STMMAC MII Bus: probed
eth0: PHY ID 00221560 at 0 IRQ -1 (0:00) active
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
NET: Registered protocol family 24
PPPoL2TP kernel driver, V1.0
pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new interface driver pegasus
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver net1080
usbcore: registered new interface driver zaurus
usbcore: registered new interface driver zd1211rw
usbcore: registered new interface driver usb8xxx
usbcore: registered new interface driver rtl8187
scsi0 : sata_stm
ata1: SATA max UDMA/133 cmd 0xfe209000 ctl 0xfe209820 bmdma 0x00000000 irq 72
ata1: SATA link down (SStatus 0 SControl 300)
physmap platform flash device: 02000000 at 04000000
physmap-flash physmap-flash: map_probe failed
NAND device: Manufacturer ID: 0xc2, Chip ID: 0xf1 (Unknown NAND 128MiB 3,3V 8-bit)
stm-nand-flex: Using boot partition name [bootldr] (from kernel config)
Creating 8 MTD partitions on «stm-nand-flex.0»:
0x00000000-0x00060000 : «bootldr»
0x00060000-0x00080000 : «ethaddr»
0x00080000-0x000c0000 : «env»
0x000c0000-0x00120000 : «branding»
0x00120000-0x00920000 : «kernel»
0x00920000-0x01120000 : «backup_kernel»
0x01120000-0x07120000 : «rootfs»
0x07120000-0x08000000 : «persistentfs»
stm-nand-flex: Found BOOT parition[bootldr], updating ECC paramters
spi_stm_ssc: SSC SPI Driver
stm-ehci stm-ehci.0: st-ehci
stm-ehci stm-ehci.0: new USB bus registered, assigned bus number 1
stm-ehci stm-ehci.0: irq 169, io mem 0xfe1ffe00
stm-ehci stm-ehci.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
stm-ohci stm-ohci.0: stm-ohci
stm-ohci stm-ohci.0: new USB bus registered, assigned bus number 2
stm-ohci stm-ohci.0: irq 168, io mem 0xfe1ffc00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
stm-ehci stm-ehci.1: st-ehci
stm-ehci stm-ehci.1: new USB bus registered, assigned bus number 3
stm-ehci stm-ehci.1: irq 143, io mem 0xfeaffe00
usb 1-1: new high speed USB device using stm-ehci and address 2
stm-ehci stm-ehci.1: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 1 port detected
stm-ohci stm-ohci.1: stm-ohci
stm-ohci stm-ohci.1: new USB bus registered, assigned bus number 4
stm-ohci stm-ohci.1: irq 142, io mem 0xfeaffc00
usb 1-1: configuration #1 chosen from 1 choice
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 1 port detected
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver.
scsi1 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
input: tm1668 as /devices/platform/tm1668/input/input0
i2c /dev entries driver
Registered led device: red
Registered led device: green
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
STMicroelectronics — Coprocessors st231 Init
st-coprocessor-0: No RAM reserved
st231.0 Coprocessor ——————————————-
not configured!
—————————————————————
st-coprocessor-1: No RAM reserved
st231.1 Coprocessor ——————————————-
not configured!
—————————————————————
stm_rng hardware driver 1.0 configured
stlpc_init:
stlpc_probe:
stlpc_probe: Looking for clk: CLKB_LPC
stlpc_probe: Using clock CLKB_LPC @ 46875 Hz
stlpc device driver registered
heartbeat: version 0.1.1 loaded
Netfilter messages via NETLINK v0.30.
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation
sh4 suspend support registered
Freeing unused kernel memoryzFri Jan 1 00:00:00 UTC 2010
Found brandingfs mtd device: /dev/mtdblock3. Mounting.
mtd device mount successful
BRANDING=rt
BRANDING_DEFAULT_UPGRADE_URL=norm://239.83.77.75:9999
BRANDING_ETH0_WAIT_DHCP=
BRANDING_DHCP_CLASSID_SUFFIX=rt
BRANDING_CHECK_ROOTFS=once
SmartSDK version: ps7105_sdk-1.5.54.3_stapi-0.30.0_qt-4.7.3
Generating fw_env.config file for SML7105, PS7105
Quirks BEGIN BOARD:ps7105————————————————————-
Quirks END ———————————————————————
RESTORE_FIRMWARE=0
stmcore-display: using HDMI hotplug
stmcore-display: STi7105 display: probed
device probe found 2 display pipelines
requesting frm: ‘component.fw’, c10f1f00/87d95d68
frm ‘component.fw’ successfully loaded
stmfb: fb0 parameters = «720×576-16@50::0:PAL:YUV:YUV»
stmfb: fb1 parameters = «720×576-16@50::0:PAL:CVBS»
fbsplash: daemonizingfbsplash: daemonizingnand_correct_data: uncorrectable error: nand_correct_data: uncorrectable error: nand_correct_data: uncorrectable error: nand_correct_data: uncorrectable error: nand_correct_data: uncorrectable error: nand_correct_data: uncorrectable error: nand_correct_data: uncorrectable error: nand_correct_data: uncorrectable error: hostname is ps7105-1CBBA81C6590
Splash message: Configuring network interfaces .
Setting MAC address 1C:BB:A8:1C:65:90
stmmac_init_phy: trying to attach to 0:00
IGMP version:
eth0 V2
lo V2
## fw_printenv: Warning: «rootfs_nfs_ip» not defined
## fw_printenv: Warning: «rootfs_nfs_path» not defined
## fw_printenv: Warning: «rootfs_mode» not defined
==================================================
1. Boot from NFS share
2. Boot from FLASH memory
3. Force upgrade with any firmware
4. Erase «env» partition and reboot
0. Stop booting
R. Reboot
Press [012] to change rootfs source: 20
Do not boot rootfs.
Boot failed
Splash message: Failed to load root file system
Setting MAC address 1C:BB:A8:1C:65:90
ADDRCONF(NETDEV_UP): eth0: link is not ready
scsi 1:0:0:0: Direct-Access General USB Flash Disk 1100 PQ: 0 ANSI: 4
sd 1:0:0:0: [sda] 15728640 512-byte hardware sectors (8053 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Assuming drive cache: write through
sd 1:0:0:0: [sda] 15728640 512-byte hardware sectors (8053 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 1:0:0:0: [sda] Attached SCSI removable disk
Using «ps7105-rt» as DHCP Vendor Class .
DHCP client options: -n -q -V ps7105-rt
Splash message: Warning: Missing network connection!
udhcpc (v1.16.0) started
Sending discover.
Sending discover.
Sending discover.
Sending discover.
Sending discover.
No lease, failing
Starting telnet .

ps7105-1CBBA81C6590 login: root
Password:
Jan 1 00:00:25 login[537]: root login on ‘ttyAS0’
# mkdir /tmp/sda; mount `ls -t /dev/sd* | tail -n1` /tmp/sda; cd /tmp/sda
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00020000 «bootldr»
mtd1: 00020000 00020000 «ethaddr»
mtd2: 00040000 00020000 «env»
mtd3: 00060000 00020000 «branding»
mtd4: 00800000 00020000 «kernel»
mtd5: 00800000 00020000 «backup_kernel»
mtd6: 06000000 00020000 «rootfs»
mtd7: 00ee0000 00020000 «persistentfs»
# flash_eraseall /dev/mtd6
Erasing 128 Kibyte @ 7e0000 — 8% complete.
Skipping bad block at 0x00800000
Erasing 128 Kibyte @ 6000000 — 100% complete.
# flashcp -v AllCan+VOD_5.20007.13052_57.5Mb.jffs2 /dev/mtd6
Erasing block: 65/460 (14%) flashcp:
Skipping bad block at 0x00800000
Erasing block: 402/460 (87%) sd 1:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 244080
sd 1:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 244320
sd 1:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 244080
Erasing block: 460/460 (100%)
Writing kb: 0/58880 (0%) flashcp: short read
# usb 2-1: new full speed USB device using stm-ohci and address 2
usb 2-1: not running at top speed; connect to a high speed hub
usb 2-1: configuration #1 chosen from 1 choice
scsi2 : SCSI emulation for USB Mass Storage devices
usb 1-1: USB disconnect, address 2
Buffer I/O error on device sda1, logical block 32768
lost page write due to I/O error on sda1
scsi 2:0:0:0: Direct-Access General USB Flash Disk 1100 PQ: 0 ANSI: 4
sd 2:0:0:0: [sdb] 15728640 512-byte hardware sectors (8053 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] 15728640 512-byte hardware sectors (8053 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 2:0:0:0: [sdb] Attached SCSI removable disk

Hw cdcacm sys как удалить

Пример usb-device-cdc-serial-project (IAR) хорошо подходит для встраивания в свое разрабатываемое устройство. Это позволит реализовать удобную текстовую консоль управления, производить отладочный ввод/вывод (для чего обычно используют DBGU), просто реализовать передачу данных без необходимости писать дополнительный софт.

USB-COM.jpg

На рисунке показан обычный, всем известный переходник USB-COM, и пример usb-device-cdc-serial-project изначально ведет себя точно так же, как этот переходник. При подключении по USB переходника (или макетной платы, запрограммированной скомпилированным примером usb-device-cdc-serial-project) к компьютеру в операционной системе Windows появляется USB-устройство класса USB CDC, видимое в системе как обычный COM-порт, к которому можно подключиться простой терминальной программой (HyperTerminal, TerraTerm, SecureCRT, putty и проч.) для передачи данных или управления. Причем необязательно, что в устройстве USB CDC должен быть 9-штырьковый разъем DB9 male (у устройства USB CDC может быть только разъем USB) — обмен данными в этом случае будет происходить с программой, находящейся внутри разработанного устройства USB CDC.

Пример, о котором идет речь (в этой статье рассматривается проект для микроконтроллера AT91SAM7X128, AT91SAM7X256 или AT91SAM7X512, однако все что написано, вполне подходит для любого микроконтроллера Atmel серий ARM7 и ARM9), находится в папке C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\examples\Atmel\at91sam7x-ek\usb-device-cdc-serial-project, а все библиотеки в папке C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\examples\Atmel\at91lib. Далее для краткости эти папки я буду называть просто как usb-device-cdc-serial-project и at91lib.

Примечание: Вы можете столкнуться с зависанием при перетыкании кабеля USB — в файле at91lib\usb\device\core\USBD_UDP.c, подпрограмма USBD_Write, зависание в макросе SET_CSR — бесконечный цикл while ((AT91C_BASE_UDP -> UDP_CSR[endpoint] & (flags)) != (flags) );. Проблему можно решить, заменив макрос SET_CSR подпрограммой, где обрабатывается таймаут ожидания.

[Старый код USBD_UDP.c, который вызывал зависание]

#define SET_CSR(endpoint, flags)  volatile unsigned int reg; reg = AT91C_BASE_UDP->UDP_CSR[endpoint] ; reg |= REG_NO_EFFECT_1_ALL; reg |= (flags); AT91C_BASE_UDP->UDP_CSR[endpoint] = reg; while ( (AT91C_BASE_UDP->UDP_CSR[endpoint] & (flags)) != (flags)); > 

[Новый код, заменяющий макрос SET_CSR, в котором баг исправлен, зависания нет]

//http://www.keil.com/forum/15376/ #define SET_CSR USBD_setCSR boolean USBD_setCSR(unsigned char endpoint, unsigned int flags)  volatile unsigned int reg; volatile unsigned int cnt = 100000; reg = AT91C_BASE_UDP->UDP_CSR[endpoint] ; reg |= REG_NO_EFFECT_1_ALL; reg |= (flags); AT91C_BASE_UDP->UDP_CSR[endpoint] = reg; while ( cnt > 0)  if ((AT91C_BASE_UDP->UDP_CSR[endpoint] & (flags)) == flags)  break; > cnt--; > if (cnt > 0) return 1; else return 0; >

Проект примера usb-device-cdc-serial-project представляет собой простой мост USB CDC USART. После того, как скомпилируете пример и запишете его в микроконтроллер, можно подключать порт USB к компьютеру. Внимание: чтобы работала подсистема USB, частота кварца должна быть равна 18.432 МГц. После первого подключения к компьютеру на системе Windows мастер установки оборудования запросит драйвер для нового устройства, и ему нужно просто скормить информационный файл at91lib\usb\device\cdc-serial\drv\6119.inf. Теперь в системе обнаружится устройство AT91 USB to Serial Converter (COM5), и с ним можно работать как с обычным COM-портом.

usb-device-cdc-serial-project_AT91_USB_to_Serial_Converter_device.PNG

В этом примере в системе Windows XP виртуальный порт появился как COM5, но цифра 5 может быть и любой другой, в зависимости от наличия незадействованных портов в Вашей системе.

Это устройство ничего особенного не делает, просто тупо и прозрачно передает все данные, полученные от USB CDC, в физическое устройство USART микроконтроллера, и наоборот — все, что приходит на USART, прозрачно передается в виртуальный COM-порт USB CDC. Вы можете убедиться в этом сами, если подключитесь к порту COM5 программой — терминальным клиентом (TerraTerm, SecureCRT, putty и проч.), и замкнете друг на друга ножки PIN_USART0_RXD и PIN_USART0_TXD (порт PA0 и PA1, ножки 81 и 82 микроконтроллера AT91SAM7512 в корпусе LQFP100). Все, что вы введете на клавиатуре в окошке программы терминального клиента, при замыкании PIN_USART0_RXD на PIN_USART0_TXD будет возвращаться обратно.

Для того, чтобы использовать пример usb-device-cdc-serial-project в своей программе как управляющую консоль или для передачи данных, весь код настройки и использования USART нужно отключить (см. исходники по ссылке [1]). После этого поток данных через USB CDC можно использовать по своему усмотрению. Общая структура программного обеспечения firmware чипа выглядит примерно так:

ARM7_CDC_USB_IAR_library.png

Техника использования порта CDC состоит из инициализация драйвера, передачи и приема данных.

[Инициализация CDCDSerialDriver]

Запуск драйвера USB CDC (CDCDSerialDriver) в firmware микроконтроллера целесообразно делать в момент подключения Вашего устройства к USB (если Ваше устройство уже запитано и делает какую-то работу помимо обработки USB). В этом случае для определения момента подключения к хосту USB для микроконтроллера должен быть предоставлен специальный сигнал, оповещающий о моменте подключения. Пример организации такого сигнала можно увидеть на схеме макетной платы AT91SAM7X (см. [2]), резисторы R10 и R12 формируют сигнал оповещения подключения к хосту USB_PR (заведен на порт микроконтроллера, настроенный как вход). Кроме того, необходимо управление нагрузочным резистором USB R11, сигнал USB_PUP (подключенный к порту микроконтроллера, настроенному как выход). При подключении USB код должен запустить драйвер USB CDC, и подключить R11 к +3.3 вольтам, чтобы дать хосту USB сигнал о подключении устройства USB.

На схемах представлены варианты физической организации подключения порта USB. На схеме справа сигнал «5V Bus Monitoring» соответствует сигналу USB_PR, а сигнал «Pullup Control» соответствует USB_PUP (для управления транзистором требуется программная инверсия активного логического уровня).

Вот простейший пример в виде кусков кода (без анализа — что подключено, зарядное устройство или хост USB), который анализирует состояние сигнала USB_PR, запускает инициализацию USB CDC и управляет сигналом USB_PUP (код для примера с макетной платой AT91SAM7X, см. [2]).

//[Начальная настройка ножек при подаче питания]
PIO_Configure(&inINT_USB, 1);
PIO_Configure(&pinPullUp, 1);

//[Ожидание инициализации подключения в главном цикле]
usbsta = USBD_GetState();
if (usbsta >= USBD_STATE_CONFIGURED)
//подключение успешно завершено, инициализация работы
// буферов ввода/вывода USB CDC и запуск подсистем,
// работающих с USB CDC на прием и передачу
inRXCDC = 0;
outRXCDC = 0;
inTXCDC = 0;
outTXCDC = 0;
TXCDCdone = true ;
NeedInitCDCDSerialDriver_Read = true ;
.
>

На диаграмме показан рекомендуемый общий принцип процедуры инициализации USB CDC. Участок кода от НАЧАЛО до КОНЕЦ должен прокручиваться в основном цикле main программы firmware пользователя.

CDCDSerialDriver_Initialize.png

Если код поддержки USB должен работать всегда, сразу после включения питания (например, когда Ваше устройство питается от USB, и работает всегда при включении питания), то тогда сигналы USB_PR и USB_PUP могут совсем не использоваться. Процедура инициализации драйвера USB должна запускаться сразу перед главным циклом main, анализ сигнала USB_PR не нужен. Нагрузочный резистор R11 может быть навсегда подключен к шине +3.3 вольт — тогда порт для управления USB_PUP также не нужен.

[Передача через USB CDC]

Неблокирующая передача осуществляется вызовом функции CDCDSerialDriver_Write (когда появились новые данные для передачи в главном кольцевом буфере, в нашем примере кода это TXCDC), после чего завершение передачи целесообразно отслеживать по функции обратного вызова (callback), в нашем примере это TXCDCcompleted. Адрес callback TXCDCcompleted передается как один из параметров функции CDCDSerialDriver_Write. Назначение остальных параметров очевидно. Как только передача завершится, TXCDCcompleted будет запущена и взведет флаг TXCDCdone, сигнализирующий о завершении передачи. Внимание! Флажок TXCDCdone должен быть обязательно сброшен до вызова CDCDSerialDriver_Write, иначе, если сделать наоборот, то это может стать причиной трудноуловимой ошибки — обработчик прерывания конечной точки (callback TXCDCcompleted) может сработать до сброса флажка TXCDCdone, и новая передача больше никогда не начнется. Чтобы не было путаницы: «прерывание» в этом контексте не относится к терминам USB (например, когда говорят о передачах Control, Interrupt, Isochronous, Bulk, то имеют в виду совсем другое), имеется в виду прерывание выполнения хода основной программы микроконтроллера. На диаграмме показан алгоритм передачи данных. Код между метками НАЧАЛО и конец должен вызываться в главном цикле main программы firmware пользователя.

CDCDSerialDriver_Write.png

Упрощенный пример кода передачи:

//размер главного буфера передачи
#define TXCDC_BUF_SIZE 1024
#define TXCDC_BUF_MASK (TXCDC_BUF_SIZE-1)
//временные переменные
u16 txbytes_to_send, txbufcnt;
//временный буфер для передачи данных CDCDSerialDriver_Write
u8 txcdcbuf[TXCDC_BUF_SIZE];
//главный кольцевой буфер передачи
u8 TXCDC[TXCDC_BUF_SIZE];
//индексы буфера TXCDC на ввод и вывод
u16 inTXCDC, outTXCDC;
//флажок завершения передачи
bool TXCDCdone;

//——————————————————————————
/// Callback для CDCDSerialDriver_Write,
/// запускается при завершении передачи
//——————————————————————————
static void TXCDCcompleted ( void *pArg,
unsigned char status,
unsigned int transferred,
unsigned int remaining)
//trace_LOG(trace_INFO, «TXCDCcompleted: %u\n\r», transferred);
TXCDCdone = true ;
>

//[Обработка передачи, прокручивается всегда из главного цикла]
//узнаем, сколько есть байт для передачи в главном
// кольцевом буфере. Код для подпрограммы idxDiff см. в [3].
txbytes_to_send = idxDiff (inTXCDC, outTXCDC, TXCDC_BUF_SIZE);
//ограничиваем размер блока передаваемых данных
// размером конечной точки (хотя, как ни странно,
// все работает нормально и без этого)
if (txbytes_to_send > BOARD_USB_ENDPOINTS_MAXPACKETSIZE(CDCDSerialDriverDescriptors_DATAIN))
txbytes_to_send = BOARD_USB_ENDPOINTS_MAXPACKETSIZE(CDCDSerialDriverDescriptors_DATAIN);
//если можно передавать (TXCDCdone), и есть что передавать (txbytes_to_send),
// скопируем данные из кольцевого буфера TXCDC в txcdcbuf и запустим передачу
if (TXCDCdone && (0 != txbytes_to_send))
for (txbufcnt = 0; txbufcnt txcdcbuf[txbufcnt] = TXCDC[outTXCDC++];
outTXCDC &= TXCDC_BUF_MASK;
>
TXCDCdone = false ; //запоминаем, что передача запущена
CDCDSerialDriver_Write(( void *)txcdcbuf, txbytes_to_send, TXCDCcompleted, 0);
>

Чтобы что-то передать в любое время, нужно просто положить данные побайтно в кольцевой буфер передачи TXCDC по индексу outTXCDC (подробнее про технику работы с кольцевым буфером см. в [3]):

TXCDC[outTXCDC++] = ‘A’ ; //будет передана A
outTXCDC &= TXCDC_BUF_MASK;
TXCDC[outTXCDC++] = ‘B’ ; //будет передана B
outTXCDC &= TXCDC_BUF_MASK;

[Прием через USB CDC]

Техника неблокирующего приема через CDC очень напоминает технику передачи. Для этого также есть функция запуска приема CDCDSerialDriver_Read, и запускаемый по окончании приема блока данных callback UsbCDCDataReceived. Адрес callback UsbCDCDataReceived точно так же передается в качестве параметра функции CDCDSerialDriver_Read. В нашем примере функция CDCDSerialDriver_Read запускается сразу после инициализации подключения интерфейса USB, а по завершении приема в вызове UsbCDCDataReceived заполняется кольцевой буфер приема RXCDC. В процессе запуска участвует флаг NeedInitCDCDSerialDriver_Read, установка которого сигнализирует о том, что текущий прием завершен и пора делать новый запуск приема. На диаграмме показан алгоритм приема данных. Код между метками НАЧАЛО и конец должен вызываться в главном цикле main программы firmware пользователя.

CDCDSerialDriver_Read.png

Упрощенный пример кода приема:

#define CDCDATABUFFERSIZE \ BOARD_USB_ENDPOINTS_MAXPACKETSIZE(CDCDSerialDriverDescriptors_DATAIN)
//размер главного буфера приема
#define RXCDC_BUF_SIZE 256
#define RXCDC_BUF_MASK (RXCDC_BUF_SIZE-1)

//временный буфер для приема данных CDCDSerialDriver_Read
unsigned char usbCDCBuffer[CDCDATABUFFERSIZE];
//главный кольцевой буфер приема
u8 RXCDC[RXCDC_BUF_SIZE];
//индексы буфера RXCDC на ввод и вывод
u8 inRXCDC, outRXCDC;
//флажок завершения приема
bool NeedInitCDCDSerialDriver_Read;

//——————————————————————————
/// Callback, автоматически запускаемый по завершении приема
/// блока данных USB CDC. Принятые данные тупо копируются
/// в главный кольцевой буфер приема по индексу inRXCDC,
/// откуда потом данные могут быть легко прочитаны по индексу
/// outRXCDC.
//——————————————————————————
static void UsbCDCDataReceived(unsigned int unused,
unsigned char status,
unsigned int received,
unsigned int remaining)
char *bufpnt;
// Check that data has been received successfully
if (status == USBD_STATUS_SUCCESS)
bufpnt = ( char *)usbCDCBuffer;
//trace_LOG(trace_INFO, «UsbDataReceived: %u\n\r», received);
while (received)
RXCDC[inRXCDC++] = *bufpnt;
inRXCDC &= RXCDC_BUF_SIZE;
bufpnt++;
received—;
>
// Check if bytes have been discarded
if ((received == CDCDATABUFFERSIZE) && (remaining > 0))
trace_LOG(trace_INFO,
«UsbDataReceived: %u bytes discarded\n\r» ,
remaining);
>
NeedInitCDCDSerialDriver_Read = true ;
>
else
trace_LOG(trace_INFO, «UsbDataReceived: Transfer error\n\r» );
>
>

//[Обработка приема, прокручивается всегда из главного цикла]
if (NeedInitCDCDSerialDriver_Read)
NeedInitCDCDSerialDriver_Read = false ;
CDCDSerialDriver_Read(usbCDCBuffer,
CDCDATABUFFERSIZE,
(TransferCallback) UsbCDCDataReceived,
0);
>

Принимаемые данные могут быть прочитаны из кольцевого буфера RXCDC в любой момент по индексу outRXCDC, когда это удобно (подробнее про технику работы с кольцевым буфером см. в [3]). Внимание! Как и в случае передачи, флажок NeedInitCDCDSerialDriver_Read должен быть обязательно сброшен до вызова CDCDSerialDriver_Read, иначе, если сделать наоборот, то это может стать причиной трудноуловимой ошибки — обработчик прерывания конечной точки (callback UsbCDCDataReceived) может сработать до сброса флажка NeedInitCDCDSerialDriver_Read, и новый прием больше никогда не начнется.

[Отслеживание подключения и отключения терминала к виртуальному COM-порту]

Когда к виртуальному COM-порту подключается программа терминала (HyperTerminal, SecureCRT, TerraTerm, putty или аналогичная), то хост передает устройству USB запрос SETUP с установленным младшим битом (D0) в поле запроса wValue. Когда программа отключается (при этом COM-порт освобождается), то передается тот же самый запрос, но при этом младший бит в поле wValue сброшен. Подключение и отключение терминального клиента полезно отслеживать например для того, чтобы выдавать приветствие в консоли пользователя, или чтобы активизировать какую-либо аппаратуру (например, включать внешний модем).

Запросы SETUP обрабатываются в модуле CDCDSerialDriver.c подпрограммой CDCDSerialDriver_RequestHandler. Состояние бита D0 в поле wValue (бит D0 показывает, подключился или отключился терминал). Туда можно добавить нужный код, который будет запускаться при событиях подключения или отключения терминала, пример:

//------------------------------------------------------------------------------ /// Обрабатывает специфические для класса CDC запросы SETUP. Должен /// вызываться из новой реализации метода USBDCallbacks_RequestReceived(). /// param указатель на экземпляр USBGenericRequest. //------------------------------------------------------------------------------ void CDCDSerialDriver_RequestHandler(const USBGenericRequest *request)  TRACE_INFO_WP("NewReq "); // Handle the request switch (USBGenericRequest_GetRequest(request))  case CDCGenericRequest_SETLINECODING: CDCDSerialDriver_SetLineCoding(); break; case CDCGenericRequest_GETLINECODING: CDCDSerialDriver_GetLineCoding(); break; case CDCGenericRequest_SETCONTROLLINESTATE: CDCDSerialDriver_SetControlLineState( CDCSetControlLineStateRequest_ActivateCarrier(request), CDCSetControlLineStateRequest_IsDtePresent(request)); //НАЧАЛО добавленного кода if (CDCSetControlLineStateRequest_IsDtePresent(request))  //Произошло подключение к виртуальному COM-порту программой // терминального клиента (putty). ModemON(); Greeting(); > else  //Терминальный клиент отключился. ModemOFF(); > //КОНЕЦ добавленного кода break; default: USBDDriver_RequestHandler(&(cdcdSerialDriver.usbdDriver), request); break; > >

[Тестирование]

В примере кода usb-device-cdc-serial-project-looped по ссылке [1] прием программно закольцован на передачу с целью тестирования. Максимальная скорость передачи и приема, которую показала программа [4], составила 11.26 килобайта/сек при настройке COM-порта USB CDC на скорость 115200 бод, 8 бит данных, без четности, 1 стоп-бит (реальная скорость составила примерно 92240 бит/сек). Получилась меньше 115200 бит/сек из-за накладных расходов при перезапуске приема и передачи, а так же из-за наличия стартового и стопового битов в физическом потоке данных. Можно за один раз передавать порцию данных блоком любого размера до 4096 байт.

COM-Port-Stress-Test01.PNG

AT91 USB CDC Driver Implementation (перевод даташита Atmel doc6269.pdf)

[1. Введение]

Класс USB Communication Device Class (CDC) предназначен главным образом для осуществления всех типов сетевых коммуникаций по шине Universal Serial Bus (USB). Этот класс делает возможным подключить телекоммуникационные устройства наподобие телефонов и аналоговых модемов, а также сетевые устройства типа кабельных или ADSL модемов.

В то время как устройство CDC включает реализацию довольно сложных устройств, класс CDC может использоваться в качестве очень простого метода для передачи данных через USB. Например, устройство CDC может появиться на компьютере как virtual COM port (VCP, виртуальный COM-порт), который значительно упрощает написание программ для компьютера (ПО хоста).

В этом документе показано, как реализовать CDC на платформе AT91 ARM® Thumb® микроконтроллеров с использованием AT91 USB Framework компании Atmel. Для этой цели будет предоставлена пошаговая реализация примера конвертера USB-to-Serial.

[2. Документы, которые упомянуты в статье]

1. Universal Serial Bus Class Definitions for Communication Devices, Version 1.1, January 19, 1999.
2. Atmel Corp., AT91 USB Framework, 2006.

[3. Основы Communication Device Class]

Эта секция предоставляет базовую информацию о Communication Device Class — когда он используется, какие для него имеются драйверы. Дается также описание архитектуры.

3.1 Назначение CDC

CDC используется для подключения коммуникационных устройств — модемов (цифровых и аналоговых), телефонов или сетевых устройств (сетевые адаптеры NIC). CDC является стандартной средой, поддерживающей широкий диапазон физических слоев (xDSL, ATM, и т. п.) и протоколов.

В этом документе CDC используется для реализации конвертера USB в последовательный порт. Традиционные последовательные порты (также известные как COM или RS-232) все еще используются очень широко, однако современные компьютеры PC (особенно ноутбуки) сейчас поставляются без последовательных портов. Преобразователь USB-to-serial может использоваться в этом случае как мост между традиционным RS-232 и портом USB.

[3.2 Архитектура]

3.2.1 Интерфейсы

Стандартом CDC (CDC specification 1.1) определено два интерфейса. Первый из них, Communication Class Interface, используется для управления устройством. Он включает в себя запросы для управления состоянием устройства, его ответы, а также оповещения о событиях. Этот интерфейс может иногда использоваться для управления вызовами, например установкой и завершением соединений, а также для настройки их параметров.

Другой интерфейс определен для простой передачи данных. Он носит название Data Class Interface. Этот интерфейс предоставляет способ обмена данными между коммуникационным устройством и хостом (компьютером). Дополнительно этот интерфейс разрешает мультиплицирование данных и команд поверх одного канала, путем использования оберток (wrappers).

3.2.2 Конечные точки (endpoints)

Communication Class Interface требует для себя как минимум одну конечную точку, которая задействована для управления устройством. Для этого используется конечная точка по умолчанию номер 0 (default control endpoint). Дополнительно (что необязательно) может выделена другая конечная точка для оповещения о событиях (events notification). Обычно это конечная точка типа Interrupt IN. Чтобы не было путаницы: термин interrupt (прерывание) в данном контексте означает просто некую сущность протокола USB (это не прерывание микроконтроллера).

Для Data Class Interface должна быть конечные точки в парах одного и того же типа. Это нужно для обмена в обе стороны — Data IN (от устройства к хосту) и Data OUT (от хоста к устройству). Для этой цели могут использоваться только конечные точки типа Bulk и Isochronous.

Рис. 3-1. Архитектура драйвера класса CDC

AT91-CDC-Class-Driver-Architecture-fig-3-1

Под Host подразумевается хост USB (компьютер). На голубом фоне в схеме показаны части драйвера, реализованные в firmware микроконтроллера AT91. Под Device подразумевается устройство USB класса CDC. Data Class Interface (Data IN, Data OUT) и Communication Class Interface (Control 0, Interrupt IN) — логическая абстракция интерфейсов, реализованная программно в firmware микроконтроллера поверх конечных точек UDP. Control 0 — управляющая конечная точка 0 (default control endpoint), Data IN, Data OUT, Interrupt IN — конечные точки UDP соответствующего типа. Communication peripheral — аппаратура микроконтроллера (для программиста это регистры UDP), которая осуществляет поддержку протокола USB.

3.2.3 Модели

Чтобы учесть все разнообразие коммуникационных устройств, определено несколько моделей. Они описывают требования в терминах интерфейсов, конечные точки и запросы, которым устройство должно удовлетворять для выполнения свой определенной роли. Здесь приведен список моделей из CDC specification 1.1, сгруппированный по их функциональности (назначению устройств):

POTS (Plain Old Telephone Service, традиционная аналоговая телефонная служба)
— Direct Line Control Model (модель прямого управления линией связи)
— Datapump Model (модель передачи данных)
— Abstract Control Model (абстрактная модель управления)
Telephone (телефония)
— Telephone Control Model (модель управления телефоном)
ISDN (стандарт цифровой телефонии)
— Multi-Channel Model (многоканальная модель)
— USB CAPI Model
Networking (сетевые коммуникации)
– Ethernet Networking Model (сетевая модель Ethernet)
— ATM Networking Control Model (сетевая модель управления ATM)

Некоторые из этих моделей и их использование будет детально рассмотрены в этом документе, как и вопросы их соответствующей реализации.

3.2.4 Class-Specific Descriptors (специфические дескрипторы класса CDC)

Информация, касающаяся класса CDC, описана в Functional Descriptors (дескрипторы функции). Они задают различные параметры интерфейса — как устройство поддерживает управление вызовами, различные атрибуты, специфичные для модели.

Так как стандарт CDC определяет множество функциональных дескрипторов, они здесь не рассматриваются. Вместо этого предоставлены различные аспекты использования класса CDC.

3.3 Host Drivers (драйверы хоста)

Большинство операционных систем (Operating Systems, OS) сегодня включают в себя драйверы для широкого спектра классов USB. Это упрощает разработку устройства USB, поскольку половину сложной работы выполняет системное программное обеспечение OS хоста. Производители могут сконцентрироваться только на реализации устройства USB, и им не нужно разрабатывать специальные драйвера для хоста.

Здесь приведен список различных реализаций CDC, поддерживаемых некоторыми OS:

• Windows®
– Abstract Control Model
– Remote NDIS

• Linux®
– Abstract Control Model
– Ethernet Model

[4. USB to Serial Converter (конвертер USB — последовательный порт)]

Эта секция описывает реализацию конвертера USB-to-serial, с использованием класса CDC и библиотеки AT91 USB Framework. За подробностями обращайтесь к документу Atmel № 6263 для информации по фреймворку USB framework, и к стандарту CDC Specification 1.1 и USB Specification 2.0 для получения информации, связанной с USB/CDC.

4.1 Предназначение

Несмотря на то, что USB все больше используется в новых продуктах, много старых устройств все еще используют традиционный RS-232 (который также называют COM-порт) для соединения с PC. Этот старый интерфейс все еще широко распространен, однако большинство производителей компьютеров и материнских плат начали поставлять свои машины без COM-порта. Конвертер USB-to-serial может быть использован для добавления к компьютеру виртуального COM-порта (virtual COM port), работающего поверх USB, что позволить подключить устройства по традиционному интерфейсу RS-232.

Виртуальный COM-порт может также использоваться для обеспечения подключения к USB-устройству старыми программами PC. Это также простой метод для коммуникаций через USB, при котором не нужно писать собственные драйвера (и иногда не нужно даже писать ПО хоста).

Рис. 4-1. Мост между традиционным (Legacy Device, в котором стоит RS-232) устройством и компьютером с конвертером USB-to-Serial

AT91-CDC-bridging-fig-4-1

4.2 Архитектура

Среда разработки AT91 USB Framework предоставляет API, которое упрощает разработку драйверов класса USB со стороны устройства USB. В этом апноуте приведен пример программы на основе AT91 USB Framework. На рис. 4-2 показана архитектура программы на основе этого фреймворка.

Рис. 4-2. Архитектура программного обеспечения с использованием AT91 USB Framework

AT91-CDC-Software-Architecture-fig-4-2

4.3 Модель

Стандарт CDC задает модель, которая отлично подходит для нашего приложения: Abstract Control Model (ACM). Она реализует запросы и оповещения, необходимые для коммуникации с интерфейсом RS-232.

Abstract Control Model требует двух интерфейсов, Communication Class Interface и Data Class Interface. Каждый из них должен иметь две привязанные конечные точки. Поэтому нужно выделить одну конечную точку, выделенную для управления устройством (default Control endpoint 0) и одну для уведомлений о событиях (дополнительная конечная точка типа Interrupt IN).

Data Class Interface также нуждается в двух конечных точках, через которые будут переноситься данные к хосту и от хоста. В зависимости от приложения, эти конечные точки могут быть либо типа Bulk, либо типа Isochronous. В случае конвертера USB-to-serial использование конечных точек Bulk может быть более подходящим, поскольку важна надежность передачи данных, и передача данных не критична по времени.

4.4 Дескрипторы

Для конвертера USB-to-serial используются стандартные дескрипторы, такие как например используются в USB Specification 2.0. Следующие примеры кода используют эти структуры, описанные в апноуте AT91 USB Framework.

Для дескрипторов, специфичных для CDC, нужны новые типы данных. Однако их реализация тривиальна, поскольку они полностью описаны в спецификации CDC. Детализированы (указаны конкретные параметры) только значения, находящиеся в каждом дескрипторе, список необходимых структур для этого примера следующий:

• CDCHeaderDescriptor
• CDCCallManagementDescriptor
• CDCAbstractControlManagementDescriptor
• CDCUnionDescriptor

4.4.1 Device Descriptor (дескриптор устройства)

The Device Descriptor должен указать значение 02h в своем поле bDeviceClass, соответствующие классу Communication Device Class. Это нужно, чтобы драйвер хоста корректно провел энумерацию устройства: поскольку устройство CDC часто показывает больше одного интерфейса, они должны быть логически сгруппированы друг с другом, чтобы они функционально не рассматривались как раздельные.

Для CDC не определены коды подкласса (subclass codes) или коды протокола (protocol codes).

Так будет выглядеть дескриптор устройства при использовании структуры S_usb_device_descriptor structure библиотеки AT91 USB Framework:

const USBDeviceDescriptor deviceDescriptor =  sizeof(USBDeviceDescriptor), USBGenericDescriptor_DEVICE, USBDeviceDescriptor_USB2_00, CDCDeviceDescriptor_CLASS, CDCDeviceDescriptor_SUBCLASS, CDCDeviceDescriptor_PROTOCOL, BOARD_USB_ENDPOINTS_MAXPACKETSIZE(0), CDCDSerialDriverDescriptors_VENDORID, CDCDSerialDriverDescriptors_PRODUCTID, CDCDSerialDriverDescriptors_RELEASE, 0, // нет строкового дескриптора для производителя 1, // индекс строки продукта равен 1 0, // нет строкового дескриптора для серийного номера 1 // устройство имеет только 1 возможную конфигурацию >;

Поля Vendor ID (идентификатор вендора) и Product ID (идентификатор продукта) используются драйвером для процесса энумерации устройства. Значение Vendor ID предоставляется производителю организацией USB-IF; значение Product ID производитель назначает сам. В нашем примере реализации используется Atmel vendor ID (03EBh) вместе с отдельным product ID (6119h).

4.4.2 Configuration Descriptor (дескриптор конфигурации)

По запросу хоста устройство configuration descriptor, за которыми идут дескрипторы интерфейса, конечных точек и дескрипторы, специфичные для класса (interface, endpoint и class-specific descriptors). В то время как стандарт CDC не определяет специальных значений для дескриптора конфигурации, ряд специфичных для класса дескрипторов указан. Они упомянуты как Functional Descriptors (функциональные дескрипторы), и некоторые из них должны быть реализованы.

// Стандартный дескриптор конфигурации  sizeof(USBConfigurationDescriptor), USBGenericDescriptor_CONFIGURATION, sizeof(CDCDSerialDriverConfigurationDescriptors), 2, // В этой конфигурации есть два интерфейса 1, // Это конфигурация №1 0, // Для этой конфигурации нет строкового дескриптора BOARD_USB_BMATTRIBUTES, USBConfigurationDescriptor_POWER(100) >,

4.4.3 Communication Class Interface Descriptor (дескриптор интерфейса коммуникационного класса)

Первый дескриптор интерфейса, который идет за дескриптором конфигурации, должен быть Communication Class Interface descriptor. Он должен указать код Communication Class Interface (02h) в своем поле bInterfaceClass.

Значение bInterfaceSubClass выбирает модель CDC, используемую интерфейсом. В этом случае будет код 02h, соответствующий Abstract Control Model.

И наконец, нужен предоставленный код протокола. Поскольку он не требуется для конвертера USB-to-serial, то он может быть оставлен в значении 0x00.

// Стандартный дескриптор Communication class interface  sizeof(USBInterfaceDescriptor), USBGenericDescriptor_INTERFACE, 0, // это интерфейс №0 0, // это альтернативная настройка №0 для этого интерфейса 1, // этот интерфейс использует конечную точку 1 CDCCommunicationInterfaceDescriptor_CLASS, CDCCommunicationInterfaceDescriptor_ABSTRACTCONTROLMODEL, CDCCommunicationInterfaceDescriptor_NOPROTOCOL, 0 // для этого интерфейса нет строкового дескриптора >,

В то время как Communication Class Interface использует две конечные точки (одну для управления устройством, и другую для оповещения о событиях), дескриптор интерфейса должен иметь свое поле bNumEndpoints установленным в 0x01: default control endpoint 0 не считается.

4.4.4 Functional Descriptors (функциональные дескрипторы)

За дескриптором интерфейса коммуникационного класса (Communication Class Interface Descriptor) должны идти несколько функциональных дескрипторов (Functional Descriptors). Они нужны для определения некоторых атрибутов устройства. Структура функционального дескриптора содержит длину дескриптора, тип и подтип, за которыми идет функциональная информация.

Значение bDescriptorType всегда равно CS_INTERFACE (24h), поскольку CDC-специфичные дескрипторы прикладываются только к интерфейсам. Значения для двух других полей, bFunctionLength и bDescriptorSubType, зависят от функций.

4.4.4.1 Header (заголовок)

Первый функциональный дескриптор должен всегда быть типа Header Functional Descriptor (функциональный дескриптор с заголовком). Он используется для указания версии CDC, на которой базируется устройство (текущая версия 1.1):

// Class-specific header functional descriptor  sizeof(CDCHeaderDescriptor), CDCGenericDescriptor_INTERFACE, CDCGenericDescriptor_HEADER, CDCGenericDescriptor_CDC1_10 >,

4.4.4.2 Call Management (управление вызовами)

Далее идет Call Management Functional Descriptor. Он показывает, как устройство обрабатывает вызовы. Если устройство само обрабатывает вызовы, то первый бит поля bmCapabilities должен быть установлен в 1. В дополнение запросы о вызовах могут быть мультиплицированы поверх data class interface вместо отправки их через Control endpoint 0, путем установки второго бита. В соответствии со стандартом CDC устройство, использующее Abstract Control
Model, должно обрабатывать вызовы само, так что бит D0 будет установлен. Последний байт (bDataInterface) не будет ничего обозначать, поскольку очищен бит D1 в поле bmCapabilities.

// Class-specific call management functional descriptor  sizeof(CDCCallManagementDescriptor), CDCGenericDescriptor_INTERFACE, CDCGenericDescriptor_CALLMANAGEMENT, CDCCallManagementDescriptor_SELFCALLMANAGEMENT, 0 // нет связанного интерфейса данных >,

4.4.4.3 Abstract Control Management (ACM, абстрактная модель управления)

Поскольку конвертер USB-to-serial использует Abstract Control Model, должен быть передан соответствующий функциональный дескриптор (Abstract Control Management Functional Descriptor) для предоставления дополнительной информации — на каких запросах/оповещениях реализовано устройство. Для этого примера, драйвер делает поддержку всех дополнительных запросов/оповещений (requests/notification) за исключением NetworkConnection; таким образом, поле bmCapabilities должно быть установлено в значение 07h.

// Class-specific abstract control management functional descriptor  sizeof(CDCAbstractControlManagementDescriptor), CDCGenericDescriptor_INTERFACE, CDCGenericDescriptor_ABSTRACTCONTROLMANAGEMENT, CDCAbstractControlManagementDescriptor_LINE >,

4.4.4.4 Union (объединение)

И наконец, Union Functional Descriptor делает возможным сгруппировать несколько интерфейсов в одну глобальную функцию. В этом случае Communication Class Interface будет установлен как главный интерфейс в группе, а Data Class Interface будет подчиненным как slave 0:

// Class-specific union functional descriptor с одним подчиненным интерфейсом  sizeof(CDCUnionDescriptor), CDCGenericDescriptor_INTERFACE, CDCGenericDescriptor_UNION, 0, // номер главного интерфейса (master interface) =0 1 // первый подчиненный интерфейс (slave interface) =1 >,

4.4.5 Notification Endpoint Descriptor (дескриптор конечной точки оповещения)

Как было сказано ранее, в модели Abstract Control Model используется элемент оповещения о событиях (notification) на конечной точке Interrupt IN. Атрибуты пользователя для неё — адрес конечной точки и интервал опроса.

Когда выбирается адрес конечной точки, должна быть учтена специфика контроллера USB. Например, для чипов AT91SAM7S контроллер UDP имеет только 4 конечные точки, одна из которых используется для default Control endpoint 0. Поскольку только 2 и 3 конечная точки имеют двойные банки FIFO, более мудро будет использовать их для Data Class Interface и последнюю использовать для оповещения о событиях.

В заключение должна быть установлена скорость опроса (polling rate) на источнике прерываний. Для нашего случая будет использоваться USART. Поскольку это не очень быстрый интерфейс, то скорость опроса может быть быть относительно низкой, т. е. значение bInterval может быть большим.

Так будет выглядеть notification endpoint descriptor, заданный в нашем примере firmware:

// Стандартный Notification endpoint descriptor  sizeof(USBEndpointDescriptor), USBGenericDescriptor_ENDPOINT, USBEndpointDescriptor_ADDRESS(USBEndpointDescriptor_IN, CDCDSerialDriverDescriptors_NOTIFICATION), USBEndpointDescriptor_INTERRUPT, MIN( BOARD_USB_ENDPOINTS_MAXPACKETSIZE(CDCDSerialDriverDescriptors_NOTIFICATION), USBEndpointDescriptor_MAXINTERRUPTSIZE_FS ), 10 // конечная точка будет опрашиваться на наличие события каждые 10 мс >,

4.4.6 Data Class Interface Descriptor (дескриптор интерфейса класса данных)

За дескриптором Communication Class Interface и связанными функциональными дескрипторами и дескрипторами конечных точек идет Data Class Interface Descriptor. Сам по себе Data Class Interface имеет идущие за ним два дескриптора конечной точки.

Код Data Class Interface равен 0Ah, и здесь нет кода подкласса (subclass code). Доступны некоторые коды протоколов, но в нашем примере они не используются. Однако мог использоваться v.42bis протокол для сжатия данных, если поддерживается устаревшее устройство.

// Стандартный дескриптор Data class interface  sizeof(USBInterfaceDescriptor), USBGenericDescriptor_INTERFACE, 1, // это интерфейс 1 0, // это альтернативная установка 0 для этого интерфейса 2, // этот интерфейс использует 2 конечные точки CDCDataInterfaceDescriptor_CLASS, CDCDataInterfaceDescriptor_SUBCLASS, CDCDataInterfaceDescriptor_NOPROTOCOL, 0 // для этого интерфейса нет строкового дескриптора >,

4.4.7 Data IN & OUT Endpoint Descriptors (дескрипторы для конечных точек данных IN и OUT)

Data Class Interface требует две дополнительные конечные точки, так что далее должны идти дескрипторы конечных точек (Endpoint Descriptors). Мы ранее решили, что это будут конечные точки Bulk IN/OUT, поскольку они больше подходят для этого частного приложения.

Так как адреса 00h и 03h уже заняты для default Control endpoint 0 и Interrupt IN notification endpoint соответственно, то data OUT и IN endpoints получат адреса 01h и 02h.

Вот два дескриптора Data IN & OUT Endpoint:

// Стандартный дескриптор Bulk-OUT endpoint  sizeof(USBEndpointDescriptor), USBGenericDescriptor_ENDPOINT, USBEndpointDescriptor_ADDRESS(USBEndpointDescriptor_OUT, CDCDSerialDriverDescriptors_DATAOUT), USBEndpointDescriptor_BULK, MIN(BOARD_USB_ENDPOINTS_MAXPACKETSIZE(CDCDSerialDriverDescriptors_DATAOUT), USBEndpointDescriptor_MAXBULKSIZE_FS), 0 // должен быть 0 для полноскоростных (full-speed) bulk endpoints >, // Стандартный дескриптор Bulk-IN endpoint  sizeof(USBEndpointDescriptor), USBGenericDescriptor_ENDPOINT, USBEndpointDescriptor_ADDRESS(USBEndpointDescriptor_IN, CDCDSerialDriverDescriptors_DATAIN), USBEndpointDescriptor_BULK, MIN(BOARD_USB_ENDPOINTS_MAXPACKETSIZE(CDCDSerialDriverDescriptors_DATAIN), USBEndpointDescriptor_MAXBULKSIZE_FS), 0 // должен быть 0 для полноскоростных (full-speed) bulk endpoints >,

4.4.8 String Descriptors (строковые дескрипторы)

Некоторые дескрипторы (устройства, конфигурации, интерфейса и т. п.) могут указать индекс строкового дескриптора для комментариев по их использованию. Эти строки полностью определяются пользователем (программистом firmware устройства USB), и они никак не влияют на работу драйвера (на выбор настроек при энумерации, к примеру) в операционной системе для этого USB-устройства.

4.5 Class-specific Requests (запросы, специфичные для класса)

Стандарт CDC задает набор специальных запросов этого класса для устройств, реализующих Abstract Control Model. В этой секции описываются детально эти запросы, включая их использование и реализацию. Для дополнительно информации по Abstract Control Model Serial Emulation и соответствующим запросам и оповещениям см. секцию 3.6.2.1 CDC specification 1.1.

4.5.1 SendEncapsulatedCommand, GetEncapsulatedResponse

Эти два запроса используются когда применяется частный протокол управления с communication class interface. Для virtual COM port это не тот случай, так что они не должны быть реализованы, даже при том, что они предположительно обязательны. Практически эти запросы никогда не будут приняты.

4.5.2 SetCommFeature, GetCommFeature, ClearCommFeature

Запросы Set/Get/ClearCommFeature используются для модификации некоторых атрибутов коммуникации, а также для получения их значений.

Первый атрибут, использующийся в настоящее время, это код страны Country Code. Некоторые устройства работают по-разному, или имеют разные законные ограничения в зависимости от страны, где они работают. Таким образом, код страны нужен для идентификации соответствующих параметров. Однако, это не нужно для конвертера USB-to-serial, поскольку он не соединяется в национальной или зависящей от страны сетью.

Abstract State (абстрактное состояние) устройства можно также изменить через использование этого запроса. Первая особенность, которую можно поменять — нужно ли мультиплицировать данные и вызовы через data class interface. Поскольку это уже указано в функциональном дескрипторе управления вызовом (см. секцию 4.4.4.2), то в нашем примере это не поддерживается, так как не имеет никакого смысла.

Idle state (состояние ожидания) устройства можно также переключить через этот запрос. В состоянии ожидания (idle) устройство не должно принимать или отправлять данные от хоста и к хосту.

4.5.3 SetLineCoding, GetLineCoding

Эти два запроса отправляются хостом, чтобы изменить или прочитать конфигурацию последовательной линии связи, которая включает в себя:

• Baudrate (скорость передачи данных)
• Number of stop bits (количество стоп-битов)
• Parity check (наличие бита контроля четности)
• Number of data bits (количество бит данных)

Когда программа терминала (ПО хоста наподобие HyperTerminal) меняет установки COM-порта, то отправляется запрос SetLineCoding с новыми параметрами. Хост может также запросить текущие настройки запросом GetLineCoding, и не менять их, если настройки корректны.

Когда принят запрос SET_LINE_CODING, то устройство должно сначала прочитать новые параметры, которые находятся в структуре из 7 байт (эта структура описана в CDC specification 1.1, секция 6.2.13). Затем устройство должно запрограммировать эти новые параметры в порт USART. Для функции USBD_Read должна быть предоставлена функция обратного вызова (callback) с указателем для доступа к принятым данным.

Код поддержки запроса GET_LINE_CODING просто вызывает функцию USBD_Write для отправки хосту текущих установок USART.

Есть две возможности для сохранения текущих установок. Наиболее очевидная возможность — сохранять установки непосредственно в регистры USART, и также получать их оттуда. Этот способ экономит место в оперативной памяти. Однако из-за того, что параметры сохраняются не так, как они представлены в структуре стандарта CDC, то они должны составляться заново в нужном формате для каждого запроса GET_LINE_CODING. Другой вариант — для упрощения доступа сохранять принятые значения в выделенном экземпляре структуры (переменная в памяти), соответствующей драйверу класса.

4.5.4 SetControlLineState

Этот запрос отправляется хостом для оповещения о двух изменениях состояния. Первый бит (D0) поля wValue в запросе показывает, подключен или нет терминал к виртуальному COM-порту. Бит D1 показывает, должен ли USART разрешить/запретить сигнал несущей для начала/завершения приема и передачи данных.

На практике конвертер USB-to-serial должен работать только тогда, когда эти два бита установлены ы 1. Иначе, он не должен передавать или принимать данные.

Поскольку запрос SET_CONTROL_LINE_STATE не имеет полезной нагрузки (data payload), устройство должно просто подтвердить этот запрос оправкой ZLP (zero-length packet, пакет нулевой длины), используя функцию USBD_Write с нулевой длиной данных.

Перед этим поле wValue должно быть проанализировано для получения нового состояния линии управления. Одиночная переменная типа boolean может использоваться для отслеживания состояния соединения. Если оба бита, и D0, и D1, установлены в 1, то конвертер должен работать нормально, т. е. должен пересылать данные между USART и хостом USB. Иначе конвертер должен перестать работать.

4.5.5 SendBreak

Запрос SendBreak используется для инструктирования устройства, что нужно послать сигнал break указанной длины по линии RS-232. Этот сигнал иногда используется для привлечения внимания подключенной машины (обычно хоста на противоположном конце соединения).

4.6 Notifications (оповещения)

Оповещения отправляются устройством, когда наступает событие наподобие изменения состояния последовательной линии. В нашем примере эти оповещения передаются через выделенную отдельно конечную точку типа Interrupt IN. Для каждого оповещения должен присутствовать специальный заголовок перед полезной нагрузкой. Заголовок имеет тот же формат, что и запрос SETUP, так что может использоваться структура USBGenericRequest, заданная в AT91 USB framework.

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

4.6.1 NetworkConnection (соединение с сетью)

Оповещение NetworkConnection используется, чтобы сказать хосту, подключен или нет коннектор на стороне RS-232. В случае использования USART нет возможности получить такую информацию, за исключением применения для этого отдельного сигнала. Таким образом, это оповещение не поддерживается конвертером USB-to-serial.

4.6.2 ResponseAvailable (доступен ответ)

Это оповещение позволяет устройству сообщить хосту, что имеется ответ. Однако, как это уже было указано ранее, запрос GetEncapsulatedResponse не относится к нашему примеру (см. секцию 4.5.1.1), так что это оповещение не имеет смысла (и не поддерживается).

4.6.3 SerialState (состояние последовательной линии)

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

• Buffer overrun (переполнение буфера)
• Parity error (ошибка четности)
• Framing error (ошибка фрейма)
• Ring signal detection mechanism state (состояние механизма детектирования сигнала вызова)
• Break detection mechanism state (состояние механизма детектирования сигнала Break)
• Transmission carrier state (состояние несущей передачи)
• Receiver carrier detection mechanism state (состояние механизма детектирования несущей приема)

Некоторые из этих значений относятся только к модему — ring signal detection, transmission carrier state и receiver carrier detection.

Это оповещение может быть напрямую привязано к состоянию регистра статуса USART. И действительно, он содержит всю необходимую информацию. Для оповещения о изменения статусе USART может использоваться прерывание, и в этот момент может быть отправлено хосту соответствующее оповещение.

Чтобы отправить оповещение SERIAL_STATE, устройство должно сначала передать соответствующий заголовок оповещения. Как было указано ранее, формат этого заголовка идентичен запросу SETUP, так что может использоваться экземпляр USBGenericRequest для сохранения необходимой информации. В следующем примере задан typedef для переименования USBGenericRequest в CDCNotificationHeader:

CDCNotificationHeader cdcNotificationHeader =  CDC_NOTIFICATION_TYPE, CDC_NOTIFICATION_SERIAL_STATE, 0, 0, 0 >;

Информация об актуальном состоянии передается в двух байтах. Имеют значение только первые 7 бит первого байта, все другие биты могут быть установлены в 0. Устройство должно установить биты в соответствии с текущим состоянием USART, и затем отправить данные с помощью функции USBD_Write.

В зависимости от размера interrupt endpoint заголовок и данные могут быть переданы либо одним куском (размер больше 8 байт), либо раздельно. В первом случае может быть проще определить структуру CDCSerialState, которая содержит сразу и заголовок, и полезную нагрузку (данные).

Во втором случае передача может быть осуществлена двумя последовательными вызовами USBD_Write (поскольку заголовок имеет длину 8 байт). Однако, что может оказаться неудобным, первая часть передачи должна завершиться, перед тем как вторая часть может начать передаваться. Это означает, что второй вызов должен либо быть сделан в функции callback (функция обратного вызова), которая будет вызвана по завершении первой передачи, или в цикле проверки, что принят код возврата USB_STATUS_SUCCESS (он показывает, что конечная точка больше не заблокирована).

4.7 Main Application (основная программа)

Работа функции main приложения состоит в том, чтобы осуществить мост (bridge) между USART и USB. Это означает, что данные, прочитанные от USART, должны быть переданы в USB, и наоборот.

4.7.1 USB Operation (работа USB)

Чтение данных, которые поступают от хоста, осуществляется вызовом функции USBD_Read для корректной конечной точки. Поскольку это асинхронная функция, то она не блокирует поток выполнения. Это значит, что другие действия (типа чтения данных из USART) могут быть выполнены в то время, когда происходит трансфер. Каждый раз, когда некоторые данные были отправлены хостом, трансфер завершается и запускается связанная с этим вызовом функция callback. Этот callback может быть запрограммирован для перенаправления принятых данных в USART.

Похожим образом может быть вызвана функция USBD_Write, как только имеются данные для передачи, также без блокирования потока выполнения программы. Однако нельзя осуществлять сразу две операции записи в одно и то же время, так что программа должна проверять — завершена ли предыдущая передача. Это можно сделать путем анализа кода возврата метода USBD_Write. Если вернулось значение USB_STATUS_LOCKED, то пока еще активна предыдущая операция передачи. Устройство должно иметь буфер для хранения данных, полученных от USART, пока конечная точка не освободится снова.

4.7.2 USART Operation (работа USART)

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

Более мощный метод доступен для чипов AT91SAM, путем использования встроенного контроллера прямого доступа к памяти (DMA Controller, PDC). Аппаратура PDC заботится о перемещении данных между процессором, памятью и периферией, что освобождает ядро микроконтроллера для выполнения других задач.

Поскольку цель этого application note только компонент USB, использование USART здесь не описано.

4.8 Пример использования программы

4.8.1 Файловая архитектура

В примере программы, предоставленной для этого application note, код драйвера делится на три файла:

• at91lib\usb\common\cdc: папка, содержащая все определения и методы стандартного CDC.
• CDCAbstractControlManagementDescriptor.h: хедер для определений CDC ACM.
• CDCCallManagementDescriptor.h: хедер для определений CDC Call Management (управление вызовами CDC).
• CDCCommunicationInterfaceDescriptor.h: хедер для определений Communication Interface.
• CDCDataInterfaceDescriptor.h: хедер для определений Data Interface.
• CDCDeviceDescriptor.h: определения для дескриптора устройства CDC.
• CDCGenericDescriptor.h: определения для дескрипторов CDC.
• CDCGenericRequest.h: определения, используемые для поддержки запросов CDC.
• CDCHeaderDescriptor.h: определения для дескриптора заголовка CDC.
• CDCUnionDescriptor.h: определения для дескриптора объединения CDC.
• CDCLineCoding.h: определения для запросов кодирования линии CDC.
• CDCLineCoding.c: методы для поддержки запросов кодирования линии CDC.
• CDCSetControlLineStateRequest.h: определения для запроса CDC SetControlLineState.
• CDCSetControlLineStateRequest.c: методы для запроса CDC SetControlLineState.
• at91lib\usb\device\cdc-serial: папка со всеми файлами, используемыми для драйвера CDC serial.
• CDCSerialDriver.h: хедер для определений драйвера конвертера USB-to-serial.
• CDCSerialDriver.c: исходный код для драйвера конвертера USB-to-serial.
• CDCSerialDriverDescriptors.h: хедер для определений дескрипторов драйвера конвертера USB-to-serial.
• CDCSerialDriverDescriptors.c: исходный код дескрипторов драйвера конвертера USB-to-serial.
• usb-device-cdc-serial-project: папка для кода основного алгоритма приложения (main application code).
• main.c: исходный код главного приложения.

Пример программного обеспечения поставляется вместе с Makefile, применяемым для сборки. Для сборки нужна утилита GNU make, которая доступна на www.GNU.org. Для получения информации по параметрам и опциям Makefile см. AT91 USB Device Framework application note.

Чтобы собрать пример конвертера USB-to-serial просто введите «make» в командной строке директории usb-device-cdcserial-project, при этом в командной строке можно добавить два параметра: CHIP= и BOARD=, значение по умолчанию для этих параметров “at91sam7s256” и “at91sam7s-ek”, например:

make CHIP=at91sam7se512 BOARD=at91sam7se-ek

В этом случае результирующий двоичный код будет называться usb-device-cdc-serial-project-at91sam7se-ekat91sam7se512-flash.bin, и он будет находится в папке usb-device-cdc-serial-project/bin.

4.9 Использование Generic Host Driver (стандартный драйвер хоста)

И Microsoft® Windows, и Linux поставляются со встроенным драйвером для использования с USB-устройством конвертера USB-to-serial. В этой секции описываются шаги, необходимые для использования этого драйвера.

4.9.1 Windows

В операционной системе Microsoft Windows стандартный USB serial driver называется usbser.sys, и он является частью стандартного набора драйверов. Этот драйвер стал доступен начиная с Windows 98SE. Однако, в отличие от других стандартных драйверов наподобие Mass Storage Devices (MSD), драйвер usbser.sys не загружается автоматически, когда устройство CDC подключено в первый раз.

4.9.1.1 Writing a Windows Driver File (написание информационного файла драйвера для Windows)

Чтобы Windows корректно распознало устройство, необходимо написать для него .inf файл. Windows Driver Development Kit (DDK) содержит информацию по этой теме. Для нашего примера драйвера поставляется базовый драйвер, который называется 6119.inf, и этот файл рассматривается здесь подробно.

Первая секция файла .inf должна быть секцией [Version]. Она содержит информацию о версии драйвера, провайдере, дате релиза и т. п.

Атрибут Signature является обязательным и может быть либо “$Windows 95$”, “$Windows NT$” или “$Chicago$”, в зависимости от той версии (версий) операционной системы, которую драйвер поддерживает. Значение “$Chicago$” используется для случая, когда поддерживаются все версии операционных систем Windows. Поскольку в этом примере конвертер USB-to-serial используется как virtual COM port, то атрибут Class должен быть «Ports». Значение ClassGuid зависит от класса, который использует устройство. Значение Provider показывает, что строковый дескриптор для поставщика драйвера (провайдера) будет задан в будущем, помеченный тэгом ATMEL. И в заключении последний тег показывает версию драйвера и дату релиза. Для номера версии каждая цифра является необязательной, за исключением первой цифры, однако если этот тег присутствует, то он не должен быть пустым.

Следующими идут две секции, [SourceDisksNames] и [SourceDisksFiles]. Они используются для указания необходимых дисков для инсталляции, и размещения каждого необходимого файла на этих дисках.

[SourceDisksNames]
1=»Windows Install CD»

Первая секция дает список имен исходных дисков, на которых пользователь может найти недостающие для установки драйвера файлы. Поскольку драйверу нужен файл usbser.sys, который есть на инсталляционном Windows CD, то этот диск здесь и указан. Идентификатор диска должен быть уникальным, в виде ненулевой цифры (ID = 1). Вторая секция показывает, на каком диске можно найти каждый файл. В нашем случае, usbser.sys может быть найден на диске 1 (который «Windows Install CD»). Может быть указан полный путь (что необязательно) до файла на CD.

Теперь файл драйвера должен указать путь, куда нужно записать скопированные файлы, используя секцию [DestinationDirs].

Целевая директория должна быть идентифицирована по своему ID, который определен для системы. ID для директории drivers равен 12.

Секция [Manufacturer] перечисляет возможных производителей для всех устройств, поддерживаемых этим драйвером. В нашем случае поддерживается только устройство производства ATMEL, так что тут будет только это значение.

Атрибут должен быть строковым тегом; его значение должно быть именем секции Models, в которой перечислены все поддерживаемые устройства от этого производителя. В нашем случае строка будет AtmelMfg, которая указана в следующей секции.

Каждая секция Models должна перечислить hardware ID каждого из поддерживаемых устройств. Для устройств USB hardware ID составляется из Vendor ID, Product ID и (что необязательно) из Device Release Number (номер релиза устройства). Эти значения вычитываются из дескриптора устройства, который предоставляется хосту на фазе энумерации устройства USB.

Имя атрибута снова представлено в виде строкового тэга, который используется для описания устройства. Значение состоит из имени секции инсталляции устройства (USBtoSer.Install) и из hardware ID. Значение hardware ID то же самое, как указано в секции 4.4.1ю

Теперь файл .inf должен детализировать секцию инсталляции для каждого ранее перечисленного устройства. В нашем примере будет только одна секция инсталляции, которая носит имя USBtoSer.Install:

[USBtoSer.Install]
CopyFiles=USBtoSer.CopyFiles
AddReg=USBtoSer.AddReg

[USBtoSer.CopyFiles]
usbser.sys. 0x00000002

[USBtoSer.AddReg]
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,usbser.sys

[USBtoSer.AddService]
DisplayName=%USBSer%
ServiceType=1r
StartType=3
ServiceBinary=%12%\usbser.sys

Секция инсталляции состоит из 5 частей. В первой секции указаны имена двух других секций: одна списка файлов для копирования, другая для ключей, которые нужно добавить в реестр Windows. Для копирования здесь имеется только один файл, usbser.sys; флаг (0x00000002) используется, чтобы указать, что пользователь не может пропустить его копирование. Ключи реестра нужны нужны для установки драйвера в старых версиях Windows (как например Windows 98). Для новых версий нужны регистры [USBtoSer.Install.Services] для сервисов ядра; каждый сервис реально перечислены в своей собственной секции.

И наконец, последняя секция [Strings], задает все строковые константы используемые в этом файле:

[Strings]
ATMEL=»ATMEL Corp.»
USBtoSerialConverter=»AT91 USB to Serial Converter»
USBSer=»USB Serial Driver»

4.9.1.2 Использование драйвера.

Когда новое устройство подключается в первый раз, Windows ищет подходящий специфический драйвер для его использования. И если не находит, то выдает пользователю запрос — что делать? Это как раз случай конвертера USB-to-serial, поскольку он не использует generic драйвер. Для установки специального драйвера, указанного в предыдущей секции, для Windows нужно указать, где его искать. Это можно сделать путем выбора второй опции, “Install from a list or specific location”, когда запустится мастер установки драйвера. Он запросит директорию, где находится драйвер. Укажите ему папку, где находится файл 6119.inf. После этого, Windows распознает драйвер “AT91 USB to Serial Converter” и отобразит его в списке Диспетчера Устройств.

Во время инсталляции мастер также запросит размещение файла usbser.sys. Обычно он уже установлен в системе, и находится в папке «C:\Windows\System32\Drivers\». В противном случае, его можно найти на Windows installation CD — инсталляционном диске Windows.

Как только драйвер правильно установился, в системе появится новый COM порт, и его можно использовать, к примеру, в программе HyperTerminal.

4.9.2 Linux

Linux имеет два различных стандартных (generic) драйвера, которые подходят для нашего конвертера USB-to-serial. Первый из них — драйвер Abstract Control Model, разработанный для устройств модема, и он просто называется acm. Другой драйвер — простой драйвер «USB to serial», он называется usbserial.

Если поддержка драйвера acm скомпилирована в ядре, Linux будет автоматически загружать его. Новое терминальное устройство будет создано под именем /dev/ttyACMx.

Драйвер usbserial должен быть загружен вручную с помощью команды modprobe, с указанием vendor ID и product ID, которые используются в устройстве USB:

modprobe usbserial vendor=0x03EB product=0x6119

Как только драйвер загружен, появится новая терминальная запись, которая будет называться /dev/ttyUSBx.

[Ссылки]

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *