platform_device and driver misunderstanding
I`m doing my embedded project with bf537 (on BF537-STAMP), with kernel 188.8.131.52.
Through digging over several drivers, LDD3 and other stuff, I realized that I`m totally confused.
The issue is that I`m writing network(ethernet) driver, using spi(existing spidev or over) driver. By now I have a driver, that is capable to create ethx interface and fill in information(all of these is fully described in LDD3). But what I can`t find, is the way, how I can use ANOTHER, existing spi driver. Probe() function gets struct platform_device, which(as i know) i fill in a special file, there rosources, devices and other staff is allocated and registerd, etc... So, if i have to get an access to spi(spi resources), i have to declare them, make a master....so to write a nes spi driver. But i want to use existing.
Also, looking at similar driver(bfin_mac) i found something useful, but still it creates MII master, it doesn`t take it from "somewhere in the kernel".
I understand, that what i wrote may be wrong, but that is what I found using a set of drivers from different versions of the kernel.
Could someone explain the mechanism driver ONE may use loaded in the kernel driver TWO?
Thank you very much!!
|Android Candy: Copay—the Next-Generation Bitcoin Wallet||Sep 03, 2015|
|The True Internet of Things||Sep 02, 2015|
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
- The True Internet of Things
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Firefox Security Exploit Targets Linux Users and Web Developers
- Concerning Containers' Connections: on Docker Networking
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- My Network Go-Bag
- Build a “Virtual SuperComputer” with Process Virtualization