search for: devres

On Tue, Dec 12, 2017 at 10:26:24PM +0800, weiping zhang wrote: > 2017-12-12 21:45 GMT+08:00 Mark Rutland <mark.rutland at arm.com>: > Hi Mark, Hi, > thanks your patch, I dig into these three devm_xxx funciton, > all of them represented by a struct devres as following, > > struct devres_node { > struct list_head entry; > dr_release_t release; > #ifdef CONFIG_DEBUG_DEVRES > const char *name; > size_t size; > #endif...

On Tue, Dec 12, 2017 at 10:26:24PM +0800, weiping zhang wrote: > 2017-12-12 21:45 GMT+08:00 Mark Rutland <mark.rutland at arm.com>: > Hi Mark, Hi, > thanks your patch, I dig into these three devm_xxx funciton, > all of them represented by a struct devres as following, > > struct devres_node { > struct list_head entry; > dr_release_t release; > #ifdef CONFIG_DEBUG_DEVRES > const char *name; > size_t size; > #endif...

Hi everyone, I have two questions: I would like to get confidence intervals on the coefficients derived from the optim() function. I apply optim() to a given function f > res <- optim(c(0.08,0.04,1.),f,NULL,method="L-BFGS-B",lower=c(0.,0.,0.)) And I would like to get the p-value and confidence intervals associated with > res$par My second question deals with error message. I

Make use of the devm_drm_dev_alloc() API to bind the lifetime of nouveau_drm structure to the drm_device. This is important because a reference to nouveau_drm is accessible from drm_device, which is provided to a number of DRM layer callbacks that can run after the deallocation of nouveau_drm currently occurs. Signed-off-by: Jeremy Cline <jcline at redhat.com> ---

...1c/0x218 [ 3.613430] do_debug_exception+0xe8/0x318 [ 3.627370] el1_dbg+0x18/0x78 [ 3.634037] __vunmap+0x1b8/0x220 [ 3.648747] vunmap+0x6c/0xc0 [ 3.653864] __iounmap+0x44/0x58 [ 3.659771] devm_ioremap_release+0x34/0x68 [ 3.672983] release_nodes+0x404/0x880 [ 3.683543] devres_release_all+0x6c/0xe8 [ 3.695692] driver_probe_device+0x250/0x828 [ 3.706187] __driver_attach+0x190/0x210 [ 3.717645] bus_for_each_dev+0x14c/0x1f0 [ 3.728633] driver_attach+0x48/0x78 [ 3.740249] bus_add_driver+0x26c/0x5b8 [ 3.752248] driver_register+0x16c/0x398 [ 3.757211...

...1c/0x218 [ 3.613430] do_debug_exception+0xe8/0x318 [ 3.627370] el1_dbg+0x18/0x78 [ 3.634037] __vunmap+0x1b8/0x220 [ 3.648747] vunmap+0x6c/0xc0 [ 3.653864] __iounmap+0x44/0x58 [ 3.659771] devm_ioremap_release+0x34/0x68 [ 3.672983] release_nodes+0x404/0x880 [ 3.683543] devres_release_all+0x6c/0xe8 [ 3.695692] driver_probe_device+0x250/0x828 [ 3.706187] __driver_attach+0x190/0x210 [ 3.717645] bus_for_each_dev+0x14c/0x1f0 [ 3.728633] driver_attach+0x48/0x78 [ 3.740249] bus_add_driver+0x26c/0x5b8 [ 3.752248] driver_register+0x16c/0x398 [ 3.757211...

...ro, it's a simple way of allowing one of several types. (Some drivers now need to be cleaned up to compile, previous patch). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- include/linux/interrupt.h | 17 +++++++++++++++-- include/linux/kernel.h | 7 +++++++ kernel/irq/devres.c | 10 +++++----- kernel/irq/manage.c | 6 +++--- 4 files changed, 30 insertions(+), 10 deletions(-) diff -r 0fe1a980708b include/linux/interrupt.h --- a/include/linux/interrupt.h Thu Jan 17 14:48:56 2008 +1100 +++ b/include/linux/interrupt.h Thu Jan 17 15:42:01 2008 +1100 @@ -69...

...ro, it's a simple way of allowing one of several types. (Some drivers now need to be cleaned up to compile, previous patch). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- include/linux/interrupt.h | 17 +++++++++++++++-- include/linux/kernel.h | 7 +++++++ kernel/irq/devres.c | 10 +++++----- kernel/irq/manage.c | 6 +++--- 4 files changed, 30 insertions(+), 10 deletions(-) diff -r 0fe1a980708b include/linux/interrupt.h --- a/include/linux/interrupt.h Thu Jan 17 14:48:56 2008 +1100 +++ b/include/linux/interrupt.h Thu Jan 17 15:42:01 2008 +1100 @@ -69...

...ason Gunthorpe wrote: > I think we're on the same page with all that. As clarified in [1], that's not a > big concern, I was referring to the changes required to integrate the auxbus > stuff. Well, I see this thread having the realization that things are not setup proeprly to use devres. To be fair devres creates almost as many bugs as it solves :\ cleanup.h is possibly a better option for most simple things and harder to misuse... > > normal (though most subsystems would call that unregister, not put) > > A DRM device is reference counted and can out-live the driver...

Dear R-users, I haven't found a way in the searchable archive to overplot a contour (lines) over a surface. I have a (n,m) matrix that represents sea surface temperature that I have plotted using image.plot(), filled.contour() or image(). I would like to overplot this image with some contour lines of mixed layer depth values(same size matrix). How can I do this? Any help is appreciated,

...i device) and continue to use aux > otherwise for discovery, probing and tying subsystems together. > > Obviously you have to be careful about the difference between the > sysfs parent (for owning a subordinate struct device, sysfs files, > etc) and the probe time parent (for owning devres, and other tasks) I think we're on the same page with all that. As clarified in [1], that's not a big concern, I was referring to the changes required to integrate the auxbus stuff. [1] https://lore.kernel.org/nouveau/ZqRTY1GjPE6CZqL3 at pollux.localdomain/ > > We've been fort...

Compared to todays PDAs the GameBoy Advance (GBA) is low spec. it has a 16MHz ARM7tdmi RISC processor. 32-bit but it can handle 16-bit instructions in a mode that resembles "bytecode" (a 32-bit instruction is executed using a 16-bit instruction). I got a feeling that the GBA would need a FPU. For more information on the GBA visit this info page:

...0714d0dc PCI/P2PDMA: track pgmap references per resource, not globally > af37085de906 lib/genalloc: introduce chunk owners > e0047ff8aa77 PCI/P2PDMA: fix the gen_pool_add_virt() failure path > 0315d47d6ae9 mm/devm_memremap_pages: introduce devm_memunmap_pages > 216475c7eaa8 drivers/base/devres: introduce devm_release_action() > > CONFLICT (content): Merge conflict in tools/testing/nvdimm/test/iomap.c > CONFLICT (content): Merge conflict in mm/hmm.c > CONFLICT (content): Merge conflict in kernel/memremap.c > CONFLICT (content): Merge conflict in include/linux/memremap.h &g...

On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline <jcline at redhat.com> wrote: > > Make use of the devm_drm_dev_alloc() API to bind the lifetime of > nouveau_drm structure to the drm_device. This is important because a > reference to nouveau_drm is accessible from drm_device, which is > provided to a number of DRM layer callbacks that can run after the > deallocation of

On Thu, 29 Jun 2023 14:05:26 +0200, Wolfram Sang <wsa+renesas at sang-engineering.com> wrote: > vm_dev has a separate lifecycle because it has a 'struct device' > embedded. Thus, having a release callback for it is correct. > > Allocating the vm_dev struct with devres totally breaks this protection, device? or driver? And why? > though. Instead of waiting for the vm_dev release callback, the memory > is freed when the platform_device is removed. Resulting in a > use-after-free when finally the callback is to be called. Can we have the break stack?...

...cepted, and we can move forward from > there to "real" things like a USB or PCI or even platform device and > driver binding stuff. In order to continue I propose to send out the following series: 1) minimal device and firmware abstractions only 2) v2 of all other device / driver, devres and PCI driver abstractions 3) v2 of basic DRM driver abstractions and Nova The v2 series would contain static driver allocation (in case of DRM even const) and quite a few more simplifications around `driver::Registration` and `device::Data`. Does that make sense? - Danilo > > thanks, &...

I think not. In virtio_pci_common, vp_dev is allocated by kzalloc so a kfree is needed. Here vm_dev is allocated by devm_kmalloc which is "automatically freed on driver detach" from the comment (drivers/base/devres.c:769). On Thu, Nov 24, 2016 at 6:37 PM, Jason Wang <jasowang at redhat.com> wrote: > > > On 2016?11?24? 08:31, Yuan Liu wrote: > >> From: Yuan Liu <liuyuan at google.com> >> >> Fix a warning thrown from virtio_mmio_remove(): >> Device 'virtio0&...

I think not. In virtio_pci_common, vp_dev is allocated by kzalloc so a kfree is needed. Here vm_dev is allocated by devm_kmalloc which is "automatically freed on driver detach" from the comment (drivers/base/devres.c:769). On Thu, Nov 24, 2016 at 6:37 PM, Jason Wang <jasowang at redhat.com> wrote: > > > On 2016?11?24? 08:31, Yuan Liu wrote: > >> From: Yuan Liu <liuyuan at google.com> >> >> Fix a warning thrown from virtio_mmio_remove(): >> Device 'virtio0&...

...o much... Trying to prevent things from diverging was one of my main objectives when I started those efforts a couple of month ago (I also sent you a mail for that purpose back then). I am maintaining a couple of branches: In the RfL repository [1]: - staging/rust-device [2] (Device / driver, devres infrastructure) - staging/dev [3] (common branch containing all the Rust infrastructure I'm currently upstreaming, including PCI and firmware abstractions) In the drm-misc repository [4]: - topic/rust-drm [5] (all the DRM abstractions) In the Nova repository [6] - nova-next [7] (the...

...e(struct drm_device *dev, > + int encoder_type, > + const char *name, ...) > +{ > + char *namestr = NULL; > + struct drm_encoder *encoder; > + int ret; > + > + encoder = devm_kzalloc(dev->dev, sizeof(*encoder), GFP_KERNEL); The encoder can outlive the devres if the device is unbound when userspace has open fds, so you can't use devm_ here. Noralf. > + if (!encoder) > + return ERR_PTR(-ENOMEM); > + > + if (name) { > + va_list ap; > + > + va_start(ap, name); > + namestr = kvasprintf(GFP_KERNEL, name, ap); > + va_end(...