Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
openanolis
cloud-kernel
提交
9eccf1b3
cloud-kernel
项目概览
openanolis
/
cloud-kernel
大约 1 年 前同步成功
通知
158
Star
36
Fork
7
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
10
列表
看板
标记
里程碑
合并请求
2
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
cloud-kernel
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
10
Issue
10
列表
看板
标记
里程碑
合并请求
2
合并请求
2
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
9eccf1b3
编写于
6月 23, 2006
作者:
D
David S. Miller
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
[Documentation]: Update probing info in sbus_drivers.txt
Signed-off-by:
N
David S. Miller
<
davem@davemloft.net
>
上级
3d4253d9
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
65 addition
and
30 deletion
+65
-30
Documentation/sparc/sbus_drivers.txt
Documentation/sparc/sbus_drivers.txt
+65
-30
未找到文件。
Documentation/sparc/sbus_drivers.txt
浏览文件 @
9eccf1b3
...
@@ -25,42 +25,84 @@ the bits necessary to run your device. The most commonly
...
@@ -25,42 +25,84 @@ the bits necessary to run your device. The most commonly
used members of this structure, and their typical usage,
used members of this structure, and their typical usage,
will be detailed below.
will be detailed below.
Here is
how probing is performed by an SBUS driver
Here is
a piece of skeleton code for perofming a device
under Linux:
probe in an SBUS driver
under Linux:
static
void init_one_mydevic
e(struct sbus_dev *sdev)
static
int __devinit mydevice_probe_on
e(struct sbus_dev *sdev)
{
{
struct mysdevice *mp = kzalloc(sizeof(*mp), GFP_KERNEL);
if (!mp)
return -ENODEV;
...
dev_set_drvdata(&sdev->ofdev.dev, mp);
return 0;
...
...
}
}
static int mydevice_match(struct sbus_dev *sdev)
static int __devinit mydevice_probe(struct of_device *dev,
const struct of_device_id *match)
{
{
if (some_criteria(sdev))
struct sbus_dev *sdev = to_sbus_device(&dev->dev);
return 1;
return
0
;
return
mydevice_probe_one(sdev)
;
}
}
static
void mydevice_probe(void
)
static
int __devexit mydevice_remove(struct of_device *dev
)
{
{
struct sbus_
bus *sbus
;
struct sbus_
dev *sdev = to_sbus_device(&dev->dev)
;
struct
sbus_dev *sdev
;
struct
mydevice *mp = dev_get_drvdata(&dev->dev)
;
for_each_sbus(sbus) {
return mydevice_remove_one(sdev, mp);
for_each_sbusdev(sdev, sbus) {
if (mydevice_match(sdev))
init_one_mydevice(sdev);
}
}
}
}
All this does is walk through all SBUS devices in the
static struct of_device_id mydevice_match[] = {
system, checks each to see if it is of the type which
{
your driver is written for, and if so it calls the init
.name = "mydevice",
routine to attach the device and prepare to drive it.
},
{},
};
MODULE_DEVICE_TABLE(of, mydevice_match);
"init_one_mydevice" might do things like allocate software
static struct of_platform_driver mydevice_driver = {
state structures, map in I/O registers, place the hardware
.name = "mydevice",
into an initialized state, etc.
.match_table = mydevice_match,
.probe = mydevice_probe,
.remove = __devexit_p(mydevice_remove),
};
static int __init mydevice_init(void)
{
return of_register_driver(&mydevice_driver, &sbus_bus_type);
}
static void __exit mydevice_exit(void)
{
of_unregister_driver(&mydevice_driver);
}
module_init(mydevice_init);
module_exit(mydevice_exit);
The mydevice_match table is a series of entries which
describes what SBUS devices your driver is meant for. In the
simplest case you specify a string for the 'name' field. Every
SBUS device with a 'name' property matching your string will
be passed one-by-one to your .probe method.
You should store away your device private state structure
pointer in the drvdata area so that you can retrieve it later on
in your .remove method.
Any memory allocated, registers mapped, IRQs registered,
etc. must be undone by your .remove method so that all resources
of your device are relased by the time it returns.
You should _NOT_ use the for_each_sbus(), for_each_sbusdev(),
and for_all_sbusdev() interfaces. They are deprecated, will be
removed, and no new driver should reference them ever.
Mapping and Accessing I/O Registers
Mapping and Accessing I/O Registers
...
@@ -263,10 +305,3 @@ discussed above and plus it handles both PCI and SBUS boards.
...
@@ -263,10 +305,3 @@ discussed above and plus it handles both PCI and SBUS boards.
Lance driver abuses consistent mappings for data transfer.
Lance driver abuses consistent mappings for data transfer.
It is a nifty trick which we do not particularly recommend...
It is a nifty trick which we do not particularly recommend...
Just check it out and know that it's legal.
Just check it out and know that it's legal.
Bad examples, do NOT use
drivers/video/cgsix.c
This one uses result of sbus_ioremap as if it is an address.
This does NOT work on sparc64 and therefore is broken. We will
convert it at a later date.
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录