I work with cpu management in big.LITTLE boards and the board on which I am developing on has some ina231 power sensors. Which I believe are handled by the ina2xx_driver (this would make sense to me). My knowledge of drivers is still in development so I am unsure about how I should get the information I need to my CPU module out of the driver/devices, in a way that wont make the Linux gods angry.
The board has 4 sensors which I believe are then stored in the struct i2c_driver in the linked list struct list_head clients. If I have understood this correctly, then my initial idea was to export a pointer to the driver
static struct i2c_driver ina2xx_driver = {
.driver = {
.name = "ina2xx",
},
.probe = ina2xx_probe,
.remove = ina2xx_remove,
.id_table = ina2xx_id,
};
+struct i2c_driver *ina2xx_driver_p = &ina2xx_driver;
+EXPORT_SYMBOL(ina2xx_driver_p);
to my module which could then step through the linked list of i2c clients allowing me to access individual device information by doing something like this
struct i2c_client *tmp
struct list_head *pos;
struct list_head *clients_head = &ina2xx_driver_p->clients;
list_for_each(pos, clients_head){
tmp = list_entry(pos, struct i2c_client, detected)
struct ina2xx_data *data = ina2xx_update_device(tmp.dev);
ina2xx_get_value(data, $(attribute));
}
I haven't actually tried this, it's just how I imagine one solution being after reading the header files. Given my lack of knowledge on the recommended practice I thought it would be best to ask before wasting a day or two trying to implement something that is destined to fail.
Is there a more standardized way that is used in the kernel to get device driver or device pointers to access information or way to get device information without reading it from files?
I hope my question makes sense and thanks.
The ina231 sensor on your board is most likely instantiated from DeviceTree. If that is the case, and your driver is also instantiated from DT, then it would be natural to store a phandle to ina231 sensor as a property in your DT node. Then you can use of_find_node_by_phandle() to get a struct device_node and then use of_find_i2c_device_by_node to turn it into struct i2c_client.
An alternative approach would be to use bus_find_device() with &i2c_bus_type as a first argument and using your custom match function. See the of_find_i2c_device_by_node implementation as an example on how this could be used.
Note that none of that will be pretty since you are planning on using driver private internal data which itself isn't a nice practice.
Related
I implemented a generic driver, in the driver I just want to go over each registered device and do something.
my driver is generic so I don't want to know anything in advance about the devices.
I have some device tree nodes:
uart0: uart#1000000 {
compatible = "generic-driver";
reg = <0x1000000 0x1000>,<0x1001000 0x1000>,<0x1002000 0x1000>;
};
uart1: uart#2000000 {
compatible = "generic-driver";
reg = <0x2000000 0x1000>,<0x2001000 0x1000>,<0x2002000 0x1000>;
};
in the driver I know how to get first offset and size with platform_get_resource, but what if I have multiple ranges?
I saw an option to get it by add reg-names:
reg = <0x2000000 0x1000>,<0x2001000 0x1000>,<0x2002000 0x1000>;
reg-names = "uart0_0","urat0_1","uart0_2";
so in the driver I can use platform_get_resource_byname, but there I need to know in the driver the regs names in advance - but it'll be no more generic - unwanted!!
so my question is, is there a way to loop over these regs without early information in the driver?
Thanks in advance!!
If you go through the definition for platform_get_resource you will find that the last parameter is the resource number. So, for the example you gave resource numbers will range from 0 to 2.
In case you don't know the number of resource then you can run an loop till you get a NULL as response to platform_get_resource.
long time listener, first time caller.
I've been backporting features from upstream code as recent as 4.12-rc-whatever to a 3.4-base kernel for an older Qualcomm SoC board (apq8064, ridiculous undertaking I know).
Thus far I've been successful in almost every core api, with any compatibility issues solved by creative shims and ducttape, with the exception of cpufreq.
Keep in mind that I'm still using legacy platform drivers and clocking, no dt's or common clock frame work.
My issue begins with the inclusion of stuct cpufreq_frequency_table into struct cpufreq_policy, as part of the move from percpu to per-policy in the api. In 3.13, registering a platform's freq_table becomes more difficult for unique cases, as using cpufreq_frequency_table_get_attr is no longer an option.
In my case, the cpufreq_driver's init is generic, and relies on my platform's scaling driver (acpuclock-krait) to register the freq_table, which is fine for the older api, but becomes incompatible with the per-policy setup. The upstream so I requires the driver to manually initialize policy->freq_table and mine uses both a cpu, and an array of 35 representing the tables in the platform code. As well, it accounts for the 6 different speedbin/pvs values when choosing a table. I'm considering either dropping the "cpu" param from it and using cpumask_copy, and perhaps even combining the two drivers into one and making the clock driver a probe, but yeah, thus far init is a mystery for me. Here is the snippet of my table registration, if anyone can think of something hackable, I'd be eternally grateful...
ifdef CONFIG_CPU_FREQ_MSM
static struct cpufreq_frequency_table.freq_table[NR_CPUS][35];
extern int console_batt_stat;
static void __init cpufreq_table_init(void)
{
int cpu;
int freq_cnt = 0;
for_each_possible_cpu(cpu) {
int i;
/* Construct the freq_table tables from acpu_freq_tbl. */
for (i = 0, freq_cnt = 0; drv.acpu_freq_tbl[i].speed.khz != 0
&& freq_cnt < ARRAY_SIZE(*freq_table)-1; i++) {
if (drv.acpu_freq_tbl[i].use_for_scaling) {
freq_table[cpu][freq_cnt].index = freq_cnt;
freq_table[cpu][freq_cnt].frequency
= drv.acpu_freq_tbl[i].speed.khz;
freq_cnt++;
}
}
/* freq_table not big enough to store all usable freqs. */
BUG_ON(drv.acpu_freq_tbl[i].speed.khz != 0);
freq_table[cpu][freq_cnt].index = freq_cnt;
freq_table[cpu][freq_cnt].frequency = CPUFREQ_TABLE_END;
/* Register table with CPUFreq. */
cpufreq_frequency_table_get_attr(freq_table[cpu], cpu);
}
dev_info(drv.dev, "CPU Frequencies Supported: %d\n", freq_cnt);
}
UPDATE!!! I wanted to update the initial registration BEFORE merging all the core changes back in, and am pretty certain that I've done so. Previously, the array in question referenced a percpu dummy array that looked like this: freq_table[NR_CPUS][35] that required the cpu parameter to be listed as part of the table. I've made some changes here that allows me a percpu setup AND the platform-specific freq management( which cpufreq doesn't need to see), but with a dummy table representing the "index," which cpufreq does need to see. Commit is here, next one fixed obvious mistakes: https://github.com/robcore/machinex/commit/59d7e5307104c2396a2e4c2a5e0b07f950dea10f
This is my work but not home work. I am trying to come up decide how best to represent a data I have using a native data structure(By native i mean I cannot use STL in C++, its a C++ code. Its our design decision not to use STL and have no way to change it or violate it)
Data is as follows:
There is a variable say int to denote ipaddr say e.g. 192.168.10.77(lets say this is stored in a int which is uniquely obtained from the 192.168.10.77 ) which lets call deviceId.
Now for each such deviceId there are other fields multiple services associated to it say service 1, service2, etc... Number of services associated with each device is variable from one deviceId to another.
So a sample of data could look like:
192.168.10.77
service1
service2
service3
service4
192.168.10.98
service1
service2
192.168.10.97
service1
Right now I store it in a inefficient data structure as below.
I have a struct as:
typedef struct
{
deviceId d;
serviceId s;
}mystr;
And then I use an array of a struct which holds
mystr mylist[64];
so entries of this array look like
mylist[0].d = 192.168.10.77
mylist[0].s = service1
mylist[1].d = 192.168.10.77
mylist[1].s = service2
mylist[2].d = 192.168.10.77
mylist[2].s = service3
mylist[3].d = 192.168.10.77
mylist[3].s = service4
mylist[4].d = 192.168.10.98
mylist[4].s = service1
mylist[5].d = 192.168.10.98
mylist[5].s = service2
... ... and so on ....
Essentially the deviceId value is duplicated as many times as there are services associated to it.
I need some thing more efficient because later I have to group all the services associated with a device.
So to do that I might have to search for deviceId and club the services for it together. I don't know how I am going to search by deviceId as it can have any value.
What is a better way to represent this data using some optimal data structure ?
[ I can see it as linked list but could not come up with the struct Node{ } for it ]
typedef struct
{
deviceId d;
serviceId s[100]; more than 1 service for 1 device is required
`}mystr;
mystr mylist[64];`
or you can have a linked list like
` struct device
{
device id;
*service;
}
typedef struct serviceid{
{
*service;
}service;
`
point to null by last service id
Consider using gethostbyname and gethostbyaddr. First try one, if it fails, try the other. Then you only have to store one string.
How about this library to store it as a basic hash table?
http://troydhanson.github.com/uthash/
Disclaimer: I'm only vaguely familiar with C
You can have link list of devices with link list of services
typedef Service{
serviceId s;//store service id
Service *nextService;//link to the different services supported by the device, end by null
}*deviceServiceList;
typedef struct Device{
deviceId d;//store the device id
Service *s;//store the list of service available for this device
}myDevices;
the devices can be stored in a array of devices or u can create a link list of devices
Is there any benefit in having never-defined structures in C ?
Example in SQLite source code :
/* struct sqlite3_stmt is never defined */
typedef struct sqlite3_stmt sqlite3_stmt;
And the object is manipulated like so :
typedef struct Vdbe Vdbe;
struct Vdbe {
/* lots of members */
};
int sqlite3_step(sqlite3_stmt *pStmt) {
Vdbe *v = (Vdbe*) pStmt;
/* do stuff with v... */
}
So why not just use a usual abstract type, with the actual structure privately defined in foo.c source and a public typedef in foo.h header ?
It is defined like this to hide the implementation detail of sqlite3_stmt from the user, thus avoiding the internal states from being messed around. See Opaque pointer.
(This also forces the user only to use the type as a pointer since the structure sqlite3_stmt itself has incomplete implementation.)
Edit: VDBE (virtual database engine) is just "a" back-end of the SQLite3 API. I believe the back-end is changeable, thus a sqlite3_stmt* is not necessarily a Vdbe*. Not exposing Vdbe* in the API because the back-end detail should not be exposed.
To clarify: What you're asking is why SQLite does the above instead of doing this:
Header file:
typedef struct sqlite3_stmt sqlite3_stmt;
C file:
struct sqlite3_stmt {
/* lots of members */
};
int sqlite3_step(sqlite3_stmt *pStmt) {
/* do stuff with pStmt... */
}
(This is the canonical form of the "opaque pointer" pattern linked to in KennyTM's answer.)
The only good reason I can think of why SQLite does what it does is the following:
The backend code, I'm speculating, came before the API and used the name Vdbe -- the name probably means something related to the implementation along the lines of "virtual database entry" (guessing wildly here).
When time came to create the API, someone realized that the parameter required by sqlite3_step was a Vdbe but that this was not exactly a name that would convey a lot to the user of the API. Hence, from the user's point of view, a Vdbe is referred to as an sqlite3_stmt.
The point here, then, is to differentiate between two views of the same item: The backend thinks in terms of Vdbes (whatever they are) because that's a name that makes sense in the context of the implementation. The API talks about sqlite3_stmts because that's a name that makes sense in the context of the interface.
Edit: As Amarghosh points out, why not just do this to achieve the same effect?
typedef struct Vdbe sqlite3_stmt;
KennyTM points out a good possible reason (please vote him up, I don't want to siphon off his rep here): VDBE is only one of several possible backends; the interface uses a "generic" sqlite3_stmt, and this is then cast to whatever the backend uses to implement it.
I'm a bit confused about how to implement my state machine.
I already know it's hierarchical since some states share the same action.
I determine what I need to do by these parameters:
Class (Values are: Base, Derived, Specific)
OpCode
Parameter 1 - optional
Parameter 2 - optional
My hierarchy is determined by the Class and the OpCode represents the action.
Derived can use the OpCodes of Base and Specific can use OpCodes of both Base and Derived.
The naive implementation is the following:
void (*const state_table [MAX_CLASSES][MAX_OPCODES]) (state *) {
{base_state1, base_state2, NULL, NULL},
{base_state1, base_state2, derived_state1, NULL},
{base_state1,base_state2, derived_state1, specific_state3},
};
void dispatch(state *s)
{
if (state_table[s->Class][s->OpCode] != NULL)
state_table[s->Class][s->OpCode](s);
}
This will turn unmaintainable really quick.
Is there another way to map the state to a superclass?
EDIT:
Further calcualtion leads me to think that I'll probably use most if not all OpCodes but I will not use all of the Classes available to me.
Another clarification:
Some OpCodes might be shared through multiple derived and base Classes.
For example:
I have a Class called Any
which is a Base class. It has the
OpCodes: STATE_ON, STATE_OFF, STATE_SET.
I have another Class called
MyGroup which is a Derived class. It has the OpCodes:
STATE_FLIP, STATE_FLOP.
The third Class is a Specific
class called ThingInMyGroup which
has the OpCode:
STATE_FLIP_FLOP_AND_FLOOP.
So a message with class Any is sent from the server, recieved in all clients and processed.
A message with class MyGroup is sent from the server, recieved in all clients and processed only on clients that belong to MyGroup, any OpCodes that are valid for the Any class are valid for the MyGroup class.
A message with class ThingInMyGroup is sent from the server, recieved in all clients and processed only on clients that belong to MyGroup and are a ThingInMyGroup*, any **OpCodes that are valid for the Any class and MyGroup class are valid for the ThingInMyGroup class.
After a message is received the client will ACK/NACK accordingly.
I prefer not to use switch cases or const arrays as they will become unmaintainable when they get bigger.
I need a flexible design that allows me:
To specify which OpCodes are available
for each Class.
To specify a superclass for each Class and through that specification to allow me to call the function pointer that is represented by the current OpCode.
There are several ways to deal with this. Here is one:
edit -- with general purpose hierarchy added
typedef unsigned op_code_type;
typedef void (*dispatch_type)(op_code_type);
typedef struct hierarchy_stack hierarchy_stack;
struct hierarchy_stack {
dispatch_type func;
hierarchy_stack *tail;
};
void dispatch(state *s, hierarchy_stack *stk) {
if (!stk) {
printf("this shouldn't have happened");
} else {
stk->func(s, stk->tail);
}
}
void Base(state *s, hierarchy_stack *stk ) {
switch (s->OpCode) {
case bstate1:
base_state1(s);
break;
case bstate2:
base_state(2);
break;
default:
dispatch(s, stk);
}
}
void Derived(state *s, hierarchy_stack *stk ) {
switch(s->opcode) {
case dstate1:
deriveds_state1(s);
break;
default:
dispatch(s, stk);
}
}
...
NOTE : All function calls are tail calls.
This localizes your "class"es a good bit so that if you decide that Derived needs 100 more methods/opcodes then you only have to edit methods and the enum (or whatever) that you use to define opcodes.
Another, more dynamic way, to deal with this would be to have a parent pointer within each "class" that pointed to the "class" that would handle anything that it could not handle.
The 2D table approach is fast and flexible (Derived could have a different handler than Base for opcode 0), but it grows fast.
I wrote a little tool that generates code similar to your naive implementation based on a mini-language. The language just specified the state-opcode-action relationships, all of the actions were just C functions conforming to a typedef.
It didn't handle the HSM aspect, but this would be relatively easy to add to a language.
I'd recommend taking this approach -- create a little language that gives you a clean way to describe the state machine, and then generate code based on that machine description. That way when you need to insert a new state a month from now, the whole thing isn't a tangled mess to edit.
Let me know if you want the code and I'll make sure it's still available somewhere.