I try to bring up Cortex A9 (Arria V) based board.
During the init the cadence-qspi driver complains that it cannot find the property of the correspondent node int he device tree and fails to initialize. When I look at the representation of the DT, and specifically at /sys/bus/patform/devices/ff705000.qspi/of_node/fifo-depth - I see that it keeps correct value.
What can be the reason for such behavior?
kernel 4.14.130-ltsi from linux-socfpga.git
Thanks,
Ilya
During the init the cadence-qspi driver complains that it cannot find the property of the correspondent node int he device tree
...
I see that it keeps correct value.
The value of the property is irrelevant when the issue is the driver "cannot find the property".
"Finding" a property relates to the name of that property, rather than its value.
What can be the reason for such behavior?
The likeliest reason is the property name (that you used) in your Device Tree does not match the required property name (specified by a character string) in the kernel driver.
The file Documentation/devicetree/bindings/mtd/cadence-quadspi.txt states that the actual name of the property in question is:
cdns,fifo-depth
whereas you report that your Device Tree uses just fifo-depth (and is obviously not a string match).
Beware that there are other required and optional properties for this node that utilize the cdns, prefix, so other lines in your Device Tree may need correction.
Related
In the nvmem.yml there is
properties:
$nodename:
pattern: "^(eeprom|efuse|nvram)(#.*|-[0-9a-f])*$"
I have a hard time finding the pattern in the source code itself.
Where can I find that the nvmem device tree nodename must be 'eeprom' or 'efuse' or 'nvram'.
The pattern doesn't exist in the code. The schema (nvmem.yaml) can be used to validate device trees but the kernel code doesn't enforce the node name.
I am writing an extension to my companies existing SNMP MIB. I have a whole list of objects, with the same properties on each. I want to be able to get and set these through SNMP.
So for example, consider my object has name, desc, arg0, arg1. What I want is to be able to refer to these as:
fullpath.objects.ObjectA.name
fullpath.objects.ObjectA.desc
fullpath.objects.ObjectA.arg0
fullpath.objects.ObjectB.name
fullpath.objects.ObjectB.desc
fullpath.objects.ObjectB.arg0
However the leaf nodes appear to have to have unique names, so I am unable to define this.
I can use a SNMP table to produce:
fullpath.objects.table.name.1
fullpath.objects.table.desc.1
fullpath.objects.table.arg0.1
fullpath.objects.table.name.2
fullpath.objects.table.desc.2
fullpath.objects.table.arg0.2
But there is nowhere to look up that 2 means ObjectB. This leaves it open to user error looking up the wrong value and setting the wrong thing.
At the moment the best solution I can see is:
fullpath.objects.ObjectAName
fullpath.objects.ObjectADesc
fullpath.objects.ObjectAArg0
fullpath.objects.ObjectBName
fullpath.objects.ObjectBDesc
fullpath.objects.ObjectBArg0
which involves defining name for every object (there are 20 or so of them). The set of objects is fixed, so this is ok...just not very tidy.
Is there some way to define names for index in the table?
Is there some way of defining a container type?
Is there some way of allowing leaf nodes to be non-unique?
Any other ideas?
You should definitely use SNMP tables to accomplish what is required. This is the only way.
MIB Object names must be unique within entire MIB file.
You can easily use object of OCTET STRING type as Table index. So each byte/symbol/char of OCTET STRING value will be translated to corresponding numeric ASCII code in OID.
I ended up just using a naming convention and adding each of the settings directly into the MIB.
Not really the answer I wanted, but it means that all of the settings show up in the MIB, and that reduces the chance of users setting the wrong setting.
I am trying to communicate with a USB printer using c-function CreateFile and therefore i need the device path. I know that i can get the device path by SetupDiEnumDeviceInterfaces and SetupDiGetDeviceInterfaceDetail, but for SetupDiEnumDeviceInterfaces i need to give an InterfaceClassGuid as third parameter which I don't know.
My current approach is:
OpenPrinter with the "user friendly" name of the Printer
GetPrinterDataEx with "PnpData" and "DeviceInstanceId" as parameters 2 and 3 which gives me the DeviceInstanceId
ClosePrinter
SetupDiCreateDeviceInfoList (with NULL-parameters)
SetupDiOpenDeviceInfo with the DeviceInstanceId obtained in step 2. Now I have the DeviceInfo of the printer
CM_Get_Parent with the DevInst of the printer (obtained in step 5).
CM_Get_Device_ID of the parent (obtained in step 6)
SetupDiOpenDeviceInfo with the device id obtained in step 7. Now I have the DeviceInfo of the USB-Interface (but not the interface itself) and am almost at the end.
The only missing thing is to get the device interface (SP_DEVICE_INTERFACE_DATA) when I have the SP_DEVINFO_DATA. The other way would be easy: Having the SP_DEVICE_INTERFACE_DATA, I could call SetupDiGetDeviceInterfaceDetail, so basically I am looking for the opposite function of SetupDiGetDeviceInterfaceDetail.
If it would be possible to enumerate ALL interfaces without having to know the InterfaceClassGuid, I could iterate through the list of interfaces and look for the one that is pointing to my device, but unfortunately, this is not possible.
The following articles were very helpful on my way:
Figuring which printer name corresponds to which device ID AND
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/51449be7-a4fa-476b-8cd2-b8933bfa3294/enumerate-multifunction-printer-in-vc?forum=wdk
Am I missing something?
It's been awhile, so I imagine you already found the answer. I'll answer it anyway for someone who may find this question later. I believe the answer is to call SetupDiEnumDeviceInterfaces passing in your SP_DEVINFO_DATA as the second parameter. From the documentation:
A pointer to an SP_DEVINFO_DATA
structure that specifies a device information element in
DeviceInfoSet.
This parameter is optional and can be NULL. If this parameter is
specified, SetupDiEnumDeviceInterfaces constrains the enumeration to
the interfaces that are supported by the specified device. If this
parameter is NULL, repeated calls to SetupDiEnumDeviceInterfaces
return information about the interfaces that are associated with all
the device information elements in DeviceInfoSet. This pointer is
typically returned by SetupDiEnumDeviceInfo.
I want to get the name of the field with which it was declared from GENERIC representation. I have a BIT_FIELD_REF tree and it's DECL_NAME is zero. For example,
struct {
int a;
unsigned b:1;
} s;
...
if (s.b)
...
For s.b I'll get a BIT_FIELD_REF and there's no obvious way to get the “b”, which is the original name of the field. How to do it?
Try call debug_c_tree (tree_var) or call debug_tree (tree_var) from GDB, and see if that knows the name. If it does, reverse engineer the pretty-printer.
What exactly did I do: investigating stuff in tree-dump.c I ended up understanding that names of the bit fields where they're known were coming from struct's DIEs and were hard to track.
Then I decided to get the name from the BIT_FIELD_REF argument 0 (reference to structure) type, which is RECORD_TYPE and it stores all the fields' sizes and offsets.
Problem was to understand that BIT_FIELD_REF doesn't reference the bits itself: it is used like BIT_FIELD_REF & INTEGER_CST, where constant acts like mask. After understanding this, I quickly computed the offsets and got the name from the type.
I am trying to animate an actor in Clutter, but when I enter a property that exists, something goes wrong.
actor.animate( AnimationMode.LINEAR, 400, scale_x:2);
gives me this error
Clutter-WARNING **: Cannot bind property '\x83\xec\u0014\x89\xc6e\xa1\u000c': objects of type 'ClutterTexture' do not have this property
Looks like Unicode-characters to me.
However, when I enter a property that does NOT exist
actor.animate( AnimationMode.LINEAR, 400, thisdoesntwork:2);
I get an error that makes much more sense
Clutter-WARNING **: Cannot bind property 'thisdoesntwork': objects of type 'ClutterTexture' do not have this property
I get the exact same problem when I try this alternative approach:
actor.animate( AnimationMode.LINEAR, 400, "scale-x", 2);
How come all properties that actually exist get converted to some mess, and what can I do to get this to work?
You should be using 2.0 for the value, not 2. 2 is an integer, 2.0 is a double. Vala can't provide type safety for variadic methods, so you have to be careful.
As for why you're seeing the behavior you are for properties which exist, my guess is it has to do with the fact that 2 is a (32-bit) integer and 2.0 is a (64-bit) double. This is simplifying things a bit, and I don't know how much experience you have with C (probably not a lot, since this is the sort of mistake someone coming from a dynamically typed language would make), however... Clutter (well, va_arg) expects a double so it parses 64 bits of data, but you only provided 32 bits, so the first 32-bits of the next argument (NULL) are included. Now, when it starts trying to parse the next argument it starts from the wrong location (32-bits into the argument), so you get the the remainder of NULL and part of whatever garbage happened to be on the stack... Unsuprisingly, that doesn't just so happen to be 32-bits of 0s so when Clutter tests to see if the value it just read == NULL it isn't and Clutter thinks it's been given a pointer to an null-terminated array of characters (which is how strings are represented in C). It reads the data at that location, which just so happens to be \x83\xec\u0014\x89\xc6e\xa1\u000c, and checks to see if there is a property with that name. There isn't, so it emits the error message you saw.
Now, if you switch to using a property which doesn't exist, Clutter will parse the argument (the name of the property), notice that it doesn't exist (just like it did with the second property above), and emit an error.