[PATCH 2/7] usb: fsl_udc_core: check return value of create_proc_read_entry()
create_proc_read_entry() may fail, if so return -ENOMEM.
Signed-off-by: Kulikov Vasiliy
---
drivers/usb/gadget/fsl_udc_core.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 08a9a62..c3d1545 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2128,7 +2128,7 @@ static int fsl_proc_read(char *page, char **start, off_t
off, int count,
#else /* !CONFIG_USB_GADGET_DEBUG_FILES */
-#define create_proc_file() do {} while (0)
+#define create_proc_file() ({ (void *)1; })
#define remove_proc_file() do {} while (0)
#endif /* CONFIG_USB_GADGET_DEBUG_FILES */
@@ -2373,9 +2373,14 @@ static int __init fsl_udc_probe(struct platform_device
*pdev)
ret = -ENOMEM;
goto err_unregister;
}
- create_proc_file();
+ if (create_proc_file() == 0) {
+ ret = -ENOMEM;
+ goto err_pool;
+ }
return 0;
+err_pool:
+ dma_pool_destroy(udc_controller->td_pool);
err_unregister:
device_unregister(&udc_controller->gadget.dev);
err_free_irq:
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections
On Sat, Jul 31, 2010 at 03:36:24PM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote: > > This set of patches de-couples the idea that there is a single > > directory in sysfs for each memory section. The intent of the > > patches is to reduce the number of sysfs directories created to > > resolve a boot-time performance issue. On very large systems > > boot time are getting very long (as seen on powerpc hardware) > > due to the enormous number of sysfs directories being created. > > On a system with 1 TB of memory we create ~63,000 directories. > > For even larger systems boot times are being measured in hours. > > Greg, Kame, how do we proceed with these ? I'm happy to put them in > powerpc.git with appropriate acks or will you take them ? I thought there would be at least one more round of these patches based on the review comments, right? I'll be glad to take them when everyone agrees with them. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections
On Sat, 2010-07-31 at 12:55 -0700, Greg KH wrote: > On Sat, Jul 31, 2010 at 03:36:24PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote: > > > This set of patches de-couples the idea that there is a single > > > directory in sysfs for each memory section. The intent of the > > > patches is to reduce the number of sysfs directories created to > > > resolve a boot-time performance issue. On very large systems > > > boot time are getting very long (as seen on powerpc hardware) > > > due to the enormous number of sysfs directories being created. > > > On a system with 1 TB of memory we create ~63,000 directories. > > > For even larger systems boot times are being measured in hours. > > > > Greg, Kame, how do we proceed with these ? I'm happy to put them in > > powerpc.git with appropriate acks or will you take them ? > > I thought there would be at least one more round of these patches based > on the review comments, right? Yes, but I was nontheless inquiring whether I should pick them up after said repost :-) > I'll be glad to take them when everyone agrees with them. Ok, good, one less thing to worry about in powerpc patchwork :-) Cheers, Ben. > thanks, > > greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown wrote: > > On 26 Jun 2010, at 00:04, Grant Likely wrote: > >> On Tue, Jun 22, 2010 at 5:00 PM, Mark Brown >>> On Tue, Jun 15, 2010 at 12:05:05PM -0400, Eric Millbrandt wrote: These patches reimplement the reset fuction in the ac97 to use gpio pins instead of using the mpc5200 ac97 reset functionality in the psc. This avoids a problem in which attached ac97 devices go into "test" mode appear unresponsive. These patches were tested on a pcm030 baseboard and on custom hardware with a wm9715 audio codec/touchscreen controller. >>> >>> Grant, are you OK with this series? >> >> Yes, I'm going to pick it up. > > I'm a little concerned with a collision with multi codec here. It'd > be handy if you could keep it separate in case it needs merging > into both trees (or we could merge via ASoC only). Hmmm. Yeah, probably better to take it via your tree then. I've currently got patch 1 in linux-next, but I'll drop it before asking benh to pull. Go ahead and add my acked-by. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/7] usb: fsl_udc_core: check return value of create_proc_read_entry()
On Sat, Jul 31, 2010 at 21:17 +0200, Dan Carpenter wrote:
> On Sat, Jul 31, 2010 at 09:38:20PM +0400, Kulikov Vasiliy wrote:
> > create_proc_read_entry() may fail, if so return -ENOMEM.
> >
>
> It can fail, but also we return NULL if procfs is disabled. I haven't
> looked at it very carefully, would this patch break the module if procfs
> was disabled?
Probably you are right, but many drivers in tree compare return value
with NULL. Some of them interpret this as error, some of them simply
call pr_warn("Hmm, I cannot create file in proc, strange..."). Maybe
there is more simplier way to check it without #ifdefs?
>
> The same applies to the similar patches in this set.
>
> regards,
> dan carpenter
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
On Fri, 2010-07-30 at 09:42 -0700, Jesse Barnes wrote:
> On Fri, 23 Jul 2010 14:56:28 +0100
> Ben Hutchings wrote:
>
> > commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove
> > unsafe and unnecessary hardware access" changed read_msi_msg_desc() to
> > return the last MSI message written instead of reading it from the
> > device, since it may be called while the device is in a reduced
> > power state.
> >
> > However, the pSeries platform code really does need to read messages
> > from the device, since they are initially written by firmware.
> > Therefore:
> > - Restore the previous behaviour of read_msi_msg_desc()
> > - Add new functions get_cached_msi_msg{,_desc}() which return the
> > last MSI message written
> > - Use the new functions where appropriate
> >
> > Signed-off-by: Ben Hutchings
> > ---
> > Compile-tested only.
> >
>
> Applied to linux-next with Michael's ack, thanks. I hope it actually
> works, I didn't see a tested-by!
I assume Stephen has been using it, otherwise his linux-next boot tests
will all have been failing. Either way he'll test it when it gets into
linux-next proper.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
