>
>On Sun, Sep 04, 2022 at 02:37:32PM +0000, Czerwacki, Eial wrote:
>> Greetings,
>>
>> while working on a driver, I've found a bug that I'm unable to understand.
>> I assume that I'm doing something wrong. here is my reduced c file:
>
><snip>
>
>I'll provide a better review after my coffee, but just one comment
>first. Ok, two:
>
>> #ifndef sysfs_emit
>> #define sysfs_emit sprintf
>> #endif // sysfs_emit
>
>Wait what? You mention at the end that you do nto have sysfs_emit in
>your kernel tree, but all activly maintained kernels does have this
>function. You should NEVER be working on a kernel tree that is not
>actually supported, and for new code like you are wanting to submit, you
>should always work on Linus's tree, or the last release, or something
>newer.
>
>Please move to 5.19 now, it will save you so much time later on...
well, I'm kinda binded to this kernel version buy you are right.
I'll move to newer kernel.
I'll worry about backports later
>
>> static int vsmp_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)
>> {
>> struct data *d;
>> int ret_val = 0;
>>
>> d = devm_kzalloc(&pci->dev, sizeof(*d), GFP_KERNEL);
>> if (IS_ERR(d))
>> return PTR_ERR(d);
>>
>> d->pdev = pci;
>> pci_set_drvdata(pci, d);
>> d->kobj = kobject_create_and_add(ROOT_SYFS_FOLDER, &d->pdev->dev.kobj);
>
>This is the issue, no driver should ever be calling any kobject_*() or
>sysfs_*() calls, unless something went very very wrong.
>
>Drivers and devices have their own tree in sysfs, with 'struct device'
>to use. You have a device here, use that, don't try to create a whole
>new sysfs tree somewhere else in the heiarchy which does not reflect the
>actual device you are using here.
>
>You then try to tie a device as a child to a kobject, which breaks the
>whole logical chain here, and then confuses your callback as you really
>don't have the device pointer anymore, it's some other random thing.
>
>So step back and try to describe first what you want to see in sysfs,
>and then maybe it will be more obvious as to what you need to do here.
>
>Write the Documentation/ABI/ entries first, what do they look like for
>your new sysfs files?
I thought that is my issue but wasn't sure.
what I'm looking for is this tree:
- vsmp
-- version
-- summery
--- data#1
...
--- data#n
-- boards
--- 0
---- data#1
...
---- data#k
--- 1
...
--- l
each board has a predefine set of attributes when I need to add another depending on the type.
also there are shared attributes between summery folder and the boards. that I was able to implement based on the name of the entry
that I'd like to see under /sys/hypervisor
I have no problems using link from the device's path to /sys/hypervisor
Thanks,
Eial
