Даже после выведения международных сил из Афганистана более чем 500 квадратных километров территории страны все еще усеяны почти 10 миллионами наземных мин.

Из-за них умирают и калечатся около 400 человек в год, большинство из них – дети.

К сожалению, ситуация в Афганистане далеко не уникальна. С подобным несчастьем столкнулись также Ангола, Ирак, Камбоджа и Босния, чьи жители до сих пор страдают от последствий военных действий, однажды происходивших на территории их стран.
 

Идея из прошлого

Массуд Хассани, голландский дизайнер, который первые 10 лет своей жизни провел в Афганистане, поставил перед собой цель исправить эту ужасающую ситуацию.
 

«Я вырос в районе Квасаба, Кабул, – вспоминает он. – Моя семья переехала туда, когда мне было 5 лет; в тот момент в стране уже шло несколько войн. Каждый день мы с моим братом Махмудом играли в поле, окруженном высокими холмами. У нас было не особо много игрушек, но мы научились делать свои. Одной из любимых моих игрушек была небольшая штуковина, которая вращалась за счет силы ветра. Мы устраивали состязания с другими ребятами: чью игрушку ветер унесет дальше в поле, тот и победил. Ветер в нашем поле был всегда сильным, и наши игрушки он уносил очень быстро и очень далеко. Каждый раз они оказывались на тех участках, куда нам заходить строго запрещалось, ведь там были мины. Я до сих пор вспоминаю, сколько же наших игрушек там осталось. Вот так у меня и родилась идея».

Уничтожать мины поможет ветер

У Массуда появилась амбициозная цель – избавить мир от мин в течение десятилетия.

«В 2011 году я занимался дипломным проектом в Академии дизайна в Эйндховене. Для работы мне понадобилось вернуться домой, где я планировал дать новую жизнь нашим игрушкам. Но только в этот раз моя «игрушка» должна была быть в 20 раз больше, тяжелее и сильнее. Называлась она Mine Kafon, что в переводе с местного наречия, языка дари, означает «Детонатор мин». Когда устройство наталкивается на мину, оно, как и мина, взрывается. Mine Kafon имеет вид сферы, сделанной из биоразлагаемого пластика и бамбука. С одной стороны, она достаточно легкая, благодаря чему она и приводится в движение ветром. С другой – ее веса достаточно, чтобы мина сдетонировала. Когда снаряд взрывается, Mine Kafon теряет всего несколько ножек, так что каждое устройство может уничтожить три или даже четыре мины. Устройство оснащено навигаторами, благодаря которым его  местонахождение можно легко отслеживать. Это, в свою очередь, позволяет составить карту наиболее безопасных путей передвижений, а также подсчитать, сколько мин было уничтожено на определенном участке», – объясняет Массуд.

 
Глобальная статистика звучит весьма неутешительно. По данным ООН, начиная с 1960-х около 110 млн мин было установлено в 70 странах по всему миру. Каждый год из-за этого погибают от 15 000 до 20 000 человек.
 

«Если верить официальной статистике, в Афганистане сейчас около 10 млн мин. Но в действительности, как мне кажется, их намного больше. И если устройство Mine Kafon оказалось эффективным в Афганистане, я уверен в том, что его можно использовать и в любой другой стране, жители которой страдают от этой проблемы, ведь одна уничтоженная мина – это спасенная жизнь», — отметил Массуд.

Что нового: дрон, маркирующий мины

Во время Нидерландской недели технологий, которая проходила с 1 по 6 июня 2015 года в Эйндховене, Массуд продемонстрировал наработки по второму этапу своего проекта. Так, сотрудничая с несколькими партнерами, он продолжает работать над усовершенствованием конструкции своего устройства, пытаясь также снизить расходы на его производство. В данный момент исследователи экспериментируют с умными материалами, которые были разработаны в Нидерландах.

В определенный момент Массуд пришел к выводу, что для воплощения его замысла ему понадобятся дроны. Стоит упомянуть, что эти БПЛА пользуются достаточно плохой репутацией, в частности из-за того, что часто применяются в военных операциях. Как сообщается во многих газетах, в частности Washington Post, именно использование дронов стало причиной смерти нескольких мирных жителей в США.
 

«Мне всегда нравилась идея с дронами, – рассказывает Массуд, – но использовать я их хочу для того, чтобы спасать жизни, а не отнимать их. Мы пытаемся понять, как можно задействовать дроны для обнаружения точного местоположения мин, ведь командам по разминированию намного легче работать, если они располагают такой информацией. Разработанный нами дрон оснащен особой рукой, на которой расположен чувствительный мини-детектор. Устройство парит над территорией, которую нужно разминировать, и брызгает краской именно в то место, где, по его данным, находится мина, а мы при этом получаем ее точные координаты. Также для создания дронов приходится использовать лишь цветные металлы – в противном случае существует риск, что мина сдетонирует, если дрон к ней приблизится. Так что, хотя идея сама по себе достаточно проста, для ее воплощения требуются командные усилия. Я очень надеюсь, что благодаря презентации моего проекта во время Нидерландской недели технологий мне все-таки удалось привлечь внимание мировой общественности. В данный момент мы занимаемся поисками партнеров, которые помогли бы нам с разработкой карт, а также инвесторов, которые согласились бы профинансировать работу над вторым этапом проекта. Иными словами, мы стремимся начать коммерческое производство устройства Mine Kafon».

ссылка на оригинал статьи http://geektimes.ru/post/266686/

Здравствуй Хабр.

Сегодня мы расскажем о конкурсе IBM Bluemix Бизнес-Квест, который мы проводим совместно с сообществом разработчиков Apps4All. Проект рассчитан на команды разработчиков, студии разработки приложений и молодые стартапы, которые могут предложить свои решения для партнеров конкурса.

Чтобы принять участие, нужно выполнить одно из заданий партнеров, среди которых издательство «Вокруг Света», «Branch Metrics», онлайн-кинотеатр «ivi.ru» и HiveChat используя платформу IBM Bluemix.

Авторы лучших работ получат памятные призы и возможность сотрудничества с IBM и партнерами конкурса.

А теперь подробнее о заданиях:

API платформа для разработчиков от «Вокруг света»

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

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

Таким образом разработчики смогут использовать данные «Вокруг света» в своих веб или мобильных сервисах создавая новые яркие проекты с профессиональным контентом.

Команда, которая предложит наилучшее решение в дальнейшем сможет обсудить его реализацию на коммерческой основе с издательством.

Интеграция SDK от «Branch Metrics»

Платформа Branch Metrics предлагает разработчикам найти новые нестандартные способы использования глубинных ссылок и deep views в мобильных приложениях при помощи SDK Branch Metrics.

Для участия достаточно описать, какие методы API SDK Branch необходимо будет использовать, какие возможности операционных систем iOS, Android, Windows Phone для этого понадобятся и показать MVP с демонстрацией функционала.

3 самых креативных разработчика получат мобильный жесткий диск на 2 Тб., стартаперские толстовку и футболку, которые приносят удачу!

Telegram bot для онлайн-кинотеатра «ivi.ru»

Для участия в конкурсе ivi.ru необходимо разработать Telegram бота на базе API онлайн-кинотеатра, который поможет выбирать фильмы и сериалы для просмотра.

Возможные пути реализации:
— Опрос по простому дереву (фильм/сериал, жанр, год, страна)
— Ivi-рекомендации для зарегистрированных пользователей
— Поиск по каталогу
— Интеграция с внешними сервисами (КиноПоиск, Афиша, MovieLens, IMDB и т.д.).

Доступ к API будет предоставлен тем кто захочет принять участие.

Технические требования к боту:
— Написан на языках Python 2.7 или Golang
— Использует возможности API Telegram такие как: Custom Keyboards, Deep Linking
— Встроена либо самостоятельная, либо внешняя система аналитики, вроде Botan.io

В обмен на прототип автор получит мобильный жесткий диск на 2 Тб.

Активные коммуникации от HiveChat

HiveChat – это новый социальный мобильный мессенджер, а так же площадка для общения с друзьями, клиентами и коллегами. В рамках конкурса необходимо продемонстрировать решения, которые помогут бизнесу улучшить коммуникации со своими клиентами.

Для участия необходимо продемонстрировать интеграцию любого MVP продукта с HiveChat используя DeepLink. Оцениваться будет наиболее интересные сценарии внедрения функционала HiveChat в продукт разработчика, оригинальность идей, описание value для бизнеса.

ASUS Zenfon 2 достанется участнику, который продемонстрирует лучший бизнес-кейсы.

— Заявить свой проект можно по адресу bizquest.apps4all.ru пройдя регистрацию и выложив решение. Прием заявок закончится 10 декабря, а победителей жюри объявит 18 декабря на сайте конкурса.

Нужны подсказки? Примеры? Смотрите, что делают ваши коллеги на Bluemix Developers Community

Если возникнут вопросы, добро пожаловать в комментарии.

ссылка на оригинал статьи http://habrahabr.ru/post/271987/

В последнее время банковский троян Dridex был одним из самых обсуждаемых. Это не удивительно, поскольку он уже получил популярность сравнимую с известным банковским трояном Zeus. Dridex также является одной из наиболее серьезных угроз на текущий момент. Авторы постоянно развивают свое творение, чтобы сделать его более эффективным.

По механизмам своей работы, Dridex, который также известен как Bugat и Cridex, похож на банковские трояны типа Zeus, но представляет собой новый этап развития этого типа вредоносного ПО. Для компрометации пользователей злоумышленники используют вредоносные вложения для электронных писем, причем такой метод используется ими как в случае домашних пользователей, так и в случае корпоративных.

Это может показаться странным, но злоумышленники используют для распространения Dridex метод, который был весьма популярным в конце 90-х: вредоносные макросы в Word и Excel файлах. Такой вектор атаки не ушел в прошлое, а до сих пор используется авторами Dridex. После исполнения пользователем вредоносного файла, Dridex заражает систему пользователя и включает ее в ботнет, контролируемый злоумышленниками. После успешного заражения системы, злоумышленники могут укрсть личную информацию пользователя, такую как данные аккаунта онлайн-банкинга, а также отправлять боту нужные им команды.

Каждые несколько недель наша антивирусная лаборатория фиксирует методы, которыми очередная кибербанда запускает новую волну распространения трояна для пользователей в различных странах. Благодаря нашему сервису ESET Virus Radar, мы можем отслеживать те страны, на которые приходится наибольшее количество заражений трояном или те из них, на которые злоумышленники нацеливали кибератаку. Каждая такая вредоносная кампания может стоить пользователям онлайн-банкинга миллионы долларов, поэтому для нас является приоритетной задачей извещение пользователей о распространении новой модификации трояна как можно скорее.

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

Статистика распространения Dridex на Virus Radar позволяет нам увидеть, что он является одним из самых распространенных в мире троянов на сегодняшний день.

Dridex поднялся на третью строчку очень быстро, поскольку еще несколько дней назад он даже не присутствовал в списке. Наибольшего успеха в заражении пользователей злоумышленники добились в европейских странах, особенно, в Испании и Словакии, а также в Южной Африке.

Информация выше показывает нам количество тех пользователей, которые пытались открыть вредоносное вложение, но антивирусный продукт ESET обнаружил и заблокировал его. Поскольку злоумышленники имели успех в различных странах мира, это говорит нам о том, что электронное фишинговое письмо с трояном, скорее всего, было написано на английском языке. Можно задаться вопросом, почему, например, пользователи в Испании открывают вложения электронных писем на английском языке, хотя он не является для них родным. Возможно, что в данном случае речь может идти о компьютерной грамотности пользователей в различных странах мира. Некоторые пользователи открывают вложения фишинговых писем просто ради любопытства и вне зависимости от того, от кого они пришли или какие данные они содержат. К счастью, для некоторых таких пользователей, их антивирусный продукт смог успешно заблокировать угрозу прежде чем она нанесла какой-либо ущерб.

Временная шкала распространения Dridex, указанная ниже, показывает, что с момента значительного повышения своей активности, наблюдалось два пика активности: 13-го и 16-го ноября.

Каждая новая волна распространения угроз подобных Dridex привлекает внимание правоохранительных органов. Такие специальные и правоохранительные службы как NSA, FBI, Europol, GCHQ и др. уже не один раз осуществляли успешный демонтаж ботнетов и устраивали облавы на киберпреступников, которые получали прибыль за счет вредоносных программ.

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

ссылка на оригинал статьи http://habrahabr.ru/post/271981/

В японской префектуре Ибараки решили применять дронов для борьбы с несанкционированными мусорными свалками.

Как заявляет Кэндзи Судзуки, занимающий пост заместителя главы отдела утилизации промышленных отходов природоохранного управления префектуры, беспилотники — инновационная возможность для очистки среды и репутации префектуры. Использование дронов в качестве нового оружия слежения позволит находить источники незаконного сброса промышленного мусора. Администрация префектуры Ибараки еще в мае стала применять дронов для осуществления этой задачи. И уже в середине лета были готовы снимки 6 мест, в 5 из которых находились свалки промышленных отходов, а в 6-м образовалась свалка земельных излишков. Администрация в качестве основной задачи дронов видит их применение для наблюдения за выполнением работ по очистке загрязненных территорий. 

Кэндзи Судзуки подчеркивает высокую эффективность использования беспилотников. Так как съемка ведется с воздуха, это позволяет увидеть всю картину целиком. Рабочим приходится убирать тщательнее, очищая не только те участки, которые просматриваются с земли. 

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

Префектура Ибараки располагается неподалеку от столичного округа. Для нее характерно большое количество строек. Кроме того, в лесистой местности легко спрятать отходы. Поэтому незаконные свалки здесь — обычное явление.  

Своего пика количество мусорных свалок достигло в 2003 году. Экологи насчитали тогда 351 территорию, используемую для отходов. И хотя с того времени численность свалок сократилась, префектура долгое время оставалась лидером по их количеству. Сейчас в Ибараки скопилось порядка 522 тыс. т отходов. И дроны призваны на борьбу с огромным количеством незаконных свалок. 

Возможности улучшения показателей

Чтобы избавиться от свалок, администрация выбрала китайских дронов модели «Фантом-3». Их производит компания DJI. Для управления беспилотником используется джойстик, как если бы это был радиоуправляемый автомобиль. Пилотирование дроном очень простое. К каждому устройству прикреплена камера, позволяющая делать фото и осуществлять видеонаблюдение. За каждый беспилотник префектура заплатила 200 тыс. иен.

Все изображения в режиме реального времени передаются на смартфоны и планшеты оператора. Радиус работы беспилотника — 700 м. В случае если расстояние превысится, дрон самостоятельно вернется на место взлета.

В префектуре велик риск увеличения сбросов мусора. Это связано с возведением объектов для Олимпиады, которая состоится в Токио в 2020 году… За прошедший 2014 год в отдел утилизации промышленных отходов поступили данные о 235 незаконных свалках. Однако для эффективной борьбы с этой проблемой требуется выработка качественной системы контроля. 

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

Кроме префектуры Ибараки, использовать беспилотники планируют и в префектуре Аити, где также насчитывается большое количество отходов. В дальнейшем, если проект покажет себя удачно, к участию в нем будут подключены и другие префектуры.
 

Дроны для поиска неисправностей в световых панелях

Sohgo Security Services — компания, использующая дронов с лета текущего года. Тогда они применялись, чтобы проводить технический осмотр масштабных солнечных энергоустановок. Беспилотник, управляемый оператором, снимал солнечные панели в полете, а полученную информацию применяли для изучения и анализа состоянии панели. 

Компания работает в префектурах Ибараки и Окинава в общей сложности с десятью энергоустановками. Также заказы в Sohgo Security Services сделали еще 20 электростанций. Начальник рекламного отдела компании Кацуюки Миёси надеется, что с вскоре желающих сделать заказ станет еще больше. 

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

Используемые для наблюдения дроны Zion FH940 были произведены японским брендом enRoute, но претерпели некоторые усовершенствования. В частности, беспилотникам добавили инфракрасные камеры. Эти устройства понадобилось установить, чтобы распознавать «горячие точки» на панели. Такое название получили места, которые нагреваются сильнее других. Возникает перегрев, когда на панель падают листья. Это приводит к снижению вырабатываемого количества энергии и, соответственно, работоспособности панели. 

Дроны способны находиться в полете около 20 минут. Система GPS, которая установлена на беспилотнике, позволяет ему автоматически двигаться в заданном направлении и прибыть в нужное место. Оператор может выбирать угол наклона для разработки и необходимую высоту. Чтобы осмотреть солнечную энергоустановку в один мегаватт, дрону требуется 10 минут. 

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

Уменьшение расходов

На цену техосмотра всегда будет оказывать влияние размер энергоустановки. Если говорить о двухмегаваттных установках, придется отдать 168 тыс. иен. Техосмотр установки в 4-5 мегаватт обойдется дешевле, если проводить его нетрадиционным методом, предполагающим участие людей.

Сотрудниками компании даже было подготовлено специальное руководство для безопасных полетов. В нем отмечено, что при скорости ветра более 5 м/с беспилотник не должен взлетать, также как запрещается ему летать над человеком. Управлять дроном должны двое: оператор, контролирующий полет, и оператор для наблюдения за показаниями. 

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

Компания Sohgo Security Services собирается оказывать дополнительные услуги, среди которых охрана, ремонт установок, обучающие курсы управления беспилотниками. 

Беспилотники изменят инфраструктуру к лучшему

Старение таких построек, как тоннели, мосты и прочие объекты социальной инфраструктуры, представляют собой огромную опасность. За решение этой проблемы взялась компания Fujitsu. Они принялись внедрять технологию для техосмотра мостов, в которой используются дроны. На данный момент осмотром мостов занимаются инженеры при помощи специальной техники: исследуют визуальное состояние, постукивают по поверхности молотком для выявления неисправностей при помощи звука. 

Чтобы провести осмотр, дорогу перекрывают. Это очень неудобно из-за расхода средств и значительных временных затрат. Беспилотники позволят этот процесс ускорить, также это возможность сделать процесс безопаснее. 

Система, предлагаемая специалистами, собирает данные о постройке, на основе которых формируется 3D-модель моста. Ее осматривают и анализируют состояние. 

Все исследования реализуются по программе стратегических инноваций при поддержке Организации по развитию новой энергии и индустриальных технологий. Реализация проекта запланирована на 2019 год.

Беспилотник имеет две камеры. Одна предназначена для съемки объекта, другая — для позиционирования. Чтобы получить 3D-модель, требуется делать снимок с установленного расстояния. Важным остается вопрос стабилизации изображения. Сильный ветер не позволяет сделать четкий снимок, приходится тратить значительные усилия на стабилизацию изображения. Специально для решения этой задачи был разработан дрон с колесами. Они позволяют передвигаться, а также поддерживают необходимое расстояние до объекта. 

Информация, записанная дроном, отправляется в базу данных. Записанные в нее координаты и изображения используются для создания 3D-модели. Это позволяет увидеть даже те участки, которые остаются труднодоступными. Все получение фотоснимки имеют высокое качество, позволяющее рассмотреть любые микротрещины. 

Сегодня в Японии есть около 700 тыс. мостов. Спрос на услуги технического обслуживания может быть невероятно велик. Наоюки Савадзаки, один из сотрудников компании Fujitsu, дал название 3D-моделям — «электронные 3D-карты строений». 

Технологии осмотра в будущем позволят анализировать внутреннее состояние трещин. Кроме того, будет создана система, позволяющая наблюдать за возрастными изменениями. Для этого также будут применять 3D-модели, сравнивая их друг с другом. 

Применения дронов позволит развиться совершенно новой отрасли оказания услуг. Но пока еще существует ряд опасений по поводу безопасности.

Для решения этой проблемы готовятся соответствующие правила. Так, в правительстве некоторое время назад приняли закон, определяющий правила эксплуатации беспилотников. А в августе вышла директива Японской ассоциации промышленного развития UAS, специализирующейся на популяризации дронов. 

ссылка на оригинал статьи http://geektimes.ru/post/266684/

Сегодня я расскажу о неожиданных проблемах, которые возникли при подключении матричной клавиатуры к ARM-борде под управлением Linux. А конкретно о том, почему драйвер adp5589 не захотел получать прерывания и как мы смогли заставить его это делать.

Кому интересно — добро пожаловать под кат.

Оглавление статьи:

• Описание железной части
• Где у нас проблема?
• Пару слов о Device Tree
• Немного о регистрации устройств и драйверов
• Механизм отложенной загрузки драйверов
• Как заставить всё работать

Описание железа вокруг клавиатуры:

У самой клавиатуры контроллера нет — она подключена по шине I2C с помощью специального контроллера матричной клавиатуры — микросхемы adp5589. У микросхемы есть линия прерывания, заведённая на один из GPIO пинов ARM SoCа. В итоге схема подключения выглядит примерно так:

portb — это порт, на пин которого заведено прерывание от контроллера клавиатуры;
intc — главный контроллер прерываний;
i2c0 — контроллер шины i2c.

Драйвер adp5589 по каким-то причинам упорно не хочет получать номер прерывания. Что же может быть причиной такого поведения? Возможно, для загрузки драйвера клавиатуры не хватает каких-то ресурсов. Может быть не успели загрузиться устройства, от которых он зависит? Давайте посмотрим, от каких устройств он может зависеть:

Во-первых — от контроллера шины I2C, к которой он подключен.
Во-вторых — от контроллера порта, на пин которого у нас заведена линия прерывания.

Теперь посмотрим в каком порядке загружаются драйвера этих устройств:

gic
designware-i2c
adp5589
dw-apb-gpio-port

Ага! Вот и причина — когда загружается драйвер клавиатуры, его interrupt-parent ещё не загружен. Как результат — драйвер клавиатуры не получает номер прерывания. Стандартное решение этой проблемы — механизм отложенной загрузки драйверов.

Его суть в том, что драйвер может потребовать повторной загрузки, если какой-нибудь нужный ему ресурс ещё не доступен. А потребовать он это может, вернув значение -EPROBE_DEFER из своей функции probe. Тогда этот драйвер будет повторно загружен позже. К тому времени или нужный ресурс уже будет доступен, или загрузка драйвера снова будет отложена.

Добавляем проверку в функцию probe драйвера клавиатуры:

if (!client->irq) {     dev_err(&client->dev, "no IRQ boss?\n");     return  -EPROBE_DEFER; } 

В надежде смотрим на новый порядок загрузки:
gic
adp5589
designware-i2c
dw-apb-gpio-port
(deferred)adp5589
(deferred)adp5589
(deferred)adp5589

Что-то пошло не так — драйвер клавиатуры повторно загрузился после драйвера GPIO, но прерывания так и не получил. Похоже, придётся зарываться в исходный код глубже, чем ожидалось.

Напрашивается три возможных пути решения:

• Захардкодить номер прерывания прямо в драйвер
• Каким-либо способом задать порядок загрузки драйверов
• Разобраться с механизмом отложенной загрузки драйверов, который почему-то не заработал

Первый вариант:

Вариант рабочий, но не желательный. Подойдёт в качестве временного, но если что-нибудь поменять в аппаратной части (например выход прерывания подключить к другому порту GPIO), то изменения придётся вносить не только в Device Tree, но и в исходный код драйвера.

Второй вариант:

Явно задать порядок загрузки драйверов возможности нет. Так что этот вариант не подходит.

Третий вариант:

Самый правильный. Его и будем рассматривать.

Здесь, пожалуй, стоит кратко рассказать про такую вещь как Device Tree, так как далее будут отсылки к ней.

Device Tree — это одна из форм описания аппаратной части устройства, на котором мы хотим использовать Linux. Представляется в виде дерева узлов, в которых задаётся нужная информация. DT существует в виде текстовых человекочитаемых файлов (.dts; .dtsi) и собираемого из них бинарного файла (.dtb).

Для примера рассмотрим кусочек .dts файла описывающий структуру подключения нашего контроллера клавиатуры к другим устройствам SoCа.

i2c0: i2c@ffc04000 {      compatible = "snps,designware-i2c";           keybs@34 {           compatible = "adi,adp5589";          interrupts = <19 IRQ_TYPE_LEVEL_LOW>;           interrupt-parent = <&portb>;      };  }; intc: intc@fffed000 {      compatible = "arm,cortex-a9-gic";      #interrupt-cells = <3>;      interrupt-controller; }; portb: gpio-controller@0 {      compatible = "snps,dw-apb-gpio-port";      interrupt-controller;      #interrupt-cells = <2>;      interrupts = <0 165 4>;      interrupt-parent = <&intc>; }; 

(Не интересующие нас сейчас узлы и свойства вырезаны для облегчения понимания)

i2c0, keybs, inc и portb — узлы, всё остальное — их свойства. Из кода сразу становится видно что чип контроллера клавиатуры подключен к I2C шине. В свойстве compatible — строка, которая описывает производителя и модель устройства. Именно по этому свойству ОС понимает какой драйвер нужно связать с этим устройством.

interrupt-controller — свойство, указывающее, что это устройство может являться контроллером прерываний, а interrupt-parent указывает к кому подключено прерывание от текущего устройства.

#interrupt-cells — свойство, указывающее на количество параметров, которыми описываются прерывания данного контроллера прерываний, а interrupts — свойство, в котором задаются параметры для данного прерывания.

Например в portb указано: #interrupt-cells = <2> Это значит, что в узлах, для которых portb это interrupt-parent в свойстве interrupts нужно описать два параметра. portb это interrupt-parent для keybs. Смотрим в keybs. Там указано: interrupts = <19 IRQ_TYPE_LEVEL_LOW>. Что это значит?

Здесь описываются два параметра. Первый — это номер пина в порте portb, на который у нас заведена линия прерывания от контроллера клавиатуры. Второй — тип прерывания (по низкому или высокому уровню). Как узнать сколько для контроллера прерываний нужно описывать параметров, и что каждый из них значат? Обычно про это написано в документации. Так, про portb написано в этом файле: Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt.

&portb — ссылка на узел portb (в нашем случае ссылка на portb будет равна /soc/gpio@ff709000/gpio-controller@0)
Остальные свойства нам пока не понадобятся, про них, и вообще про Device Tree, подробно можно почитать здесь: devicetree.org/Device_Tree_Usage.

Ещё не лишним будет упомянуть про процесс регистрации устройств и драйверов (не беспокойтесь, к основной теме мы вернёмся уже в следующем абзаце). Согласно Linux Device Model:

Устройство — физический или виртуальный объект, который подключен к шине(возможно тоже виртуальной)
Драйвер — программный объект, который может быть связан с устройством и может выполнять какие-либо функции управления.
Шина — устройство, предназначенное быть “точкой крепления” других устройств. Базовая функциональность всех шин, поддерживаемых ядром, определяется структурой bus_type. В этой структуре объявлена вложенная структура subsys_private, в которой объявлены два списка: klist_devices и klist_drivers.
klist_devices — список устройств, которые подключены к шине.
klist_drivers — список драйверов, которые могут управлять устройствами на этой шине.
Устройства и драйвера добавляются в эти списки с помощью функций device_register и driver_register. Кроме того, device_register и driver_register связывают устройство с подходящим драйвером. device_register проходит по списку драйверов и пытается найти драйвер, подходящий для данного устройства. (driver_register проходит по списку устройств и пытается найти устройства, которыми он может управлять) Проверка подходит ли драйвер для устройства производится с помощью функции match(dev, drv), указатель на которую есть в структуре bus_type.

Теперь можно перейти и к основной теме — реализации механизма отложенной загрузки драйверов. Заглянем в файл drivers/base/dd.c Вот краткое описание того, что мы там увидим:

Для управления повторной загрузкой драйверов имеются два списка — deferred_probe_pending_list и deferred_probe_active_list.

deferred_probe_pending_list — список устройств, для загрузки драйвера которых не хватает каких-то ресурсов.
deferred_probe_active_list — список устройств, драйвер которых можно попробовать запустить повторно.

В функции really_probe вызывается функция probe для шины, на которой расположено устройство. В нашем случае это функция i2c_device_probe и выглядит это так dev->bus->probe(dev). Возвращаемое значение проверяется на ошибки, и, если оно равно -EPROBE_DEFER, то устройство добавляется в deferred_probe_pending_list.

Но самое интересное — как и когда драйвер вызывается заново. Пока драйверы возвращают -EPROBE_DEFER, устройства последовательно добавляются в deferred_probe_pending_list. Но как только для какого-либо драйвера функция probe завершилась успешно, все устройства из deferred_probe_pending_list переносятся в deferred_probe_active_list. Выглядит логично — возможно, того драйвера, который у нас последний был успешно загружен, и не хватало для нормальной загрузки отложенных драйверов. Повторная попытка запуска драйверов из deferred_probe_active_list производится функцией deferred_probe_work_func. В ней вызывается bus_probe_device для каждого устройства из списка.

Вызов bus_probe_device в конечном итоге снова приведёт нас к функции really_probe для пары из нашего устройства и его драйвера (см. выше).

Но подождите! Мы сейчас говорили о вызове функции probe для шины, на которой расположено устройство. То есть о i2c_device_probe. А как же функция probe драйвера клавиатуры? Нет, про неё мы не забыли, она как раз будет вызвана из i2c_device_probe. В этом можно убедиться, взглянув на её код в файле drivers/i2c/i2c-core.с:

static int i2c_device_probe(struct device *dev) { 	struct i2c_client	*client = i2c_verify_client(dev); 	struct i2c_driver	*driver; 	int status;  	if (!client) 		return 0;  	driver = to_i2c_driver(dev->driver); 	if (!driver->probe || !driver->id_table) 		return -ENODEV;  	if (!device_can_wakeup(&client->dev)) 		device_init_wakeup(&client->dev, 					client->flags & I2C_CLIENT_WAKE); 	dev_dbg(dev, "probe\n");  	status = of_clk_set_defaults(dev->of_node, false); 	if (status < 0) 		return status;  	status = dev_pm_domain_attach(&client->dev, true); 	if (status != -EPROBE_DEFER) { 	//Вот и вызов probe драйвера клавиатуры (в нашем случае) 		status = driver->probe(client, i2c_match_id(driver->id_table, 					client)); 		if (status) 			dev_pm_domain_detach(&client->dev, true); 	}  	return status; } 

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

В функцию adp5589_probe(struct i2c_client *client, const struct i2c_device_id *id) передаётся структура client, одно из полей которой — irq — номер прерывания, которое будет генерировать наше устройство (контроллер клавиатуры). adp5589_probe вызовется из функции i2c_device_probe(struct device * dev). В неё передаётся структура device, из указателя на которую вычисляется указатель на структуру i2c_client (с помощью магии макроса container_of).

Значит нужно найти где заполняется структура i2c_client. Заполняется она в функции i2c_new_device(struct i2c_adapter * adap, struct i2c_board_info const * info); Конкретно поле irq копируется из одноимённого поля структуры i2c_board_info.

struct i2c_client	*client; client->irq = info->irq; 

Структура i2c_board_info заполняется в функции of_i2c_register_devices(struct i2c_adapter * adap).

info.irq = irq_of_parse_and_map(node, 0);  

irq_of_parse_and_map — это обёртка для цепочки из двух функций — of_irq_parse_one и irq_create_of_mapping; функция of_irq_parse_one пытается найти узел, который заявлен в device tree как interrupt-controller для текущего устройства.
Помните эти несколько строчек в device tree?

expander: pca9535@20 {  	interrupt-parent = <&portb>;  };  

Именно portb и ищет of_irq_parse_one, а по результатам своей работы заполняет структуру of_phandle_args, которая передаётся функции irq_create_of_mapping. irq_create_of_mapping уже и возвращает искомый номер прерывания.

В первый раз of_irq_parse_one не находит порт GPIO, на что ругается в лог:

irq: no irq domain found for /soc/gpio@ff709000/gpio-controller@0!

А что происходит при повторной загрузке драйвера? А ничего. Вызываются то только i2c_device_probe и adp5589_probe.
Вот в чём и проблема. Прерывание устанавливается только в первый раз и остаётся таким навечно, сколько бы мы не выполняли повторную загрузку нашего драйвера.

Проблему нашли, но как её исправить?

Можно попробовать перенести код получения прерывания в i2c_device_probe. До этого нам номер прерывания нигде не требуется, так что проблем возникнуть не должно.

Но лучше давайте заглянем в исходники более свежей версии ядра (у нас установлена версия 3.18) Вот что мы там увидим:
Установку прерывания i2c клиента перенесли в функцию i2c_device_probe.

if (!client->irq && dev->of_node) {         int irq = of_irq_get(dev->of_node, 0);         if (irq == -EPROBE_DEFER)                 return irq;         if (irq < 0)                 irq = 0;         client->irq = irq; } 

В структуре i2c_board_info хоть и осталось поле irq но оно не используется. Так что в новых версиях ядра проблема исправлена.

Осталось всего лишь перенести изменения в нашу версию. Все изменения коснутся файла drivers/i2c/i2c-core.c
Добавим в нашу i2c_device_probe установку прерывания клиента i2c, что появилась в свежей версии, а в функции of_i2c_register_devices удаляем установку прерывания.

--- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -626,6 +626,17 @@ static int i2c_device_probe(struct device *dev)         if (!client)                 return 0;   +       if (!client->irq && dev->of_node) { +               int irq = of_irq_get(dev->of_node, 0); + +               if (irq == -EPROBE_DEFER) +                       return irq; +               if (irq < 0) +                       irq = 0; + +               client->irq = irq; +       } +         driver = to_i2c_driver(dev->driver);         if (!driver->probe || !driver->id_table)                 return -ENODEV; @@ -1407,7 +1418,12 @@ static void of_i2c_register_devices(struct i2c_adapter *adap)                         continue;                 }   -               info.irq = irq_of_parse_and_map(node, 0); +               /* +                * Now, we don't need to set interrupt here, because we set +                * it in i2c_device_probe function  +                * info.irq = irq_of_parse_and_map(node, 0); +                */ +                 info.of_node = of_node_get(node);                 info.archdata = &dev_ad; 

Проверяем — клавиатура работает. Смотрим в /proc/interrupt:

$ grep 'adp5589_keys' /proc/interrupts 305:          2         -  20  adp5589_keys 

Нажмём несколько кнопок:

$ grep 'adp5589_keys' /proc/interrupts 305:          6         -  20  adp5589_keys 

Проблема решена.

ссылка на оригинал статьи http://habrahabr.ru/post/271983/