Dear all,
would you mind helping me understand how workers and workqueues act in a
seemingly simple scenario? I'm calling
queue_work(my_queue, my_worker)
to add a worker to a queue that was created by calling
create_singlethread_workqueue().
This goes into
queue_work
queue_work_on
Hi Greg and all,
Thus wrote Greg KH (g...@kroah.com):
> Not at all, this is what you should be done, and is what many misc
> devices do, that's why the parent pointer is there :)
thanks for the confirmation.
> What in-kernel misc drivers do not do that that you feel should?
My
Hi all,
I have a driver that is bound to a platform device. It creates a
miscdevice to interact with user space. And it has a "global" structure
that stores info which are used throughout the driver.
This works ok as far as I can see. The only issue is how to make the
"global" struct available
Thus wrote 김찬 (c...@etri.re.kr):
> I read here
> (https://www.kernel.org/doc/Documentation/arm64/booting.txt
> https://www.kernel.org/doc/Documentation/arm64/booting.txt) the device
> tree blob location should be passed to the kernel during arm64
> booting through x0 register. But I see many .dts
Hello Greg and all,
Thus wrote Greg KH (g...@kroah.com):
> Please do not do that. There are valid kernel apis to grant access to
> registers easily,
the most simple case would be a "reset reason" register within the
chip's address space. A hand-crafted driver would ioremap the region and
Hi Greg,
Thus wrote Greg KH (g...@kroah.com):
> That is because you have created a driver attribute, not a device
> attribute. Create device attributes and you should be fine, they bind
> to the device your driver is passed.
could you point me to an example in the kernel tree where this is
Thus wrote Greg KH (g...@kroah.com):
> That's odd, what did you ask to be included that caused that?
I called gcc with -I $KERNEL_ROOT/include/uapi. This is the chain of
files that were included.
my_app.c
$GCC_SYSROOT/usr/include/netinet/in.h
$GCC_SYSROOT/usr/include/sys/socket.h
Dear all,
is it correct that the files under include/uapi/ can be included by a
user space application?
I just ran into an error where my application ended up including
include/uapi/linux/stddef.h (with a number of intermediate steps).
This fails because the kernel's stddef.h includes
Thus wrote Martin Kaiser (li...@kaiser.cx):
> Thus wrote rpj...@crashcourse.ca (rpj...@crashcourse.ca):
> > i'll need to access that device tree entry and effectively ioremap()
> > slave0's physical address to a usable virtual address.
> > is there a canonical
Thus wrote rpj...@crashcourse.ca (rpj...@crashcourse.ca):
> i'll need to access that device tree entry and effectively ioremap()
> slave0's physical address to a usable virtual address.
> is there a canonical way to do this? short of manually extracting
> the appropriate device tree node and
Thus wrote Greg KH (g...@kroah.com):
> So I've now queued this up to 4.14.y and 4.9.y, does it need to go any
> further back?
No, it seems that the fsl-imx25-tsadc driver was added after the 4.4
release.
Thanks,
Martin
___
Kernelnewbies mailing
Hello Greg,
Thus wrote Greg KH (g...@kroah.com):
> You did? Was this on December 12:
> Subject: [PATCH] mfd: fsl-imx25: Clean up irq settings during removal
> ?
yes, that was what I submitted.
> If so, I totally missed it (just now dug in my archives to find it.)
> > Is there anything
I've just had another look at this.
Thus wrote Martin Kaiser (li...@kaiser.cx):
> static ssize_t
> my_read_reg(struct device *pdev, struct device_attribute *attr, char *buf)
> {
> u32 __iomem *reg;
> reg = devm_ioremap(pdev, 0x581018C4, 4);
> return scnprintf(buf,
Dear all,
I'm trying to create a simple sysfs node that prints the content of a
register. The code looks like this
static ssize_t
my_read_reg(struct device *pdev, struct device_attribute *attr, char *buf)
{
u32 __iomem *reg;
reg = devm_ioremap(pdev, 0x581018C4, 4);
return
14 matches
Mail list logo
