Re: [U-Boot] [PATCH 4/4] efikamx: Place machine ID into board config

2011-09-24 Thread Marek Vasut
On Friday, September 23, 2011 04:17:28 PM Stefano Babic wrote:
> On 09/23/2011 03:36 PM, Marek Vasut wrote:
> > On Friday, September 23, 2011 02:50:52 PM Fabio Estevam wrote:
> >> Let common code set the machine ID.
> > 
> > This will need rework ... stefano, can we get the efikasb stuff mainline
> > so Fabio can rework this ?
> 
> No..it is not a good idea to push a patch that is already required to be
> changed.
> 
> As this patch addresses a comment in the EfikaMX/SB patchset, the best
> way is to fix this issue directly in that patchset.

I also added that machine_is_() things so we'll have that all. Eventually, I 
plan to add MX/SB runtime detection, but that's not in place so far.

> 
> Best regards,
> Stefano Babic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] usb: Move ehci.h and ehci-core.h to include/usb directory

2011-09-24 Thread Marek Vasut
On Saturday, September 24, 2011 09:10:02 PM Fabio Estevam wrote:
> Move ehci.h and ehci-core.h to include/usb directory.
> 
> Cc: Remy Bohmer 
> Signed-off-by: Fabio Estevam 

Like we discussed earlier, something similar should soon go in as a part of a 
bigger series. Therefore I'd prefer to keep that together.

Cheers
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] Timer API (again!)

2011-09-24 Thread J. William Campbell
On 9/16/2011 4:53 AM, Graeme Russ wrote:
 > Hi All,
 >
 > Well, here we are again, a Timer API discussion
 >
 > All things considered, I don't think the Linux approach is right for 
U-Boot
 > - It is designed to cater for way more use-cases than U-Boot will 
ever need
 > to deal with (time queues and call-backs in particular)
Hi Graeme,
Glad you are tackling this again.
 >
 > To summarize, in a nutshell, what _I_ think U-Boot need from a Timer API
 >
 >   1. A reliable udelay() available as early as possible that is OK to 
delay
 >  longer than requested, but not shorter - Accuracy is not implied or
 >  assumed
I think you don't really mean this. SOME attempt at accuracy is to be 
expected. Not perfect is allowed, but to be totally bogus is not 
allowed. That is worse than nothing. Longer by 20% or so is possibly ok, 
2% isn't.
 >   2. A method of obtaining a number of 'time intervals' which have 
elapsed
 >  since some random epoch (more info below)
 >   3. A nice way of making A->B time checks simple within the code
 >
 > OK, some details:
 >
 > 1. I'm starting to thing this should be a function pointer or a flag 
in gd.
 > Why oh why would you do such a thing I hear you ask... udelay() is 
needed
 > _EARLY_ - It may well be needed for SDRAM or other hardware 
initialisation
 > prior to any reliable timer sub-system being available. But early 
udelay()
 > is often inaccurate and when the timer sub-system gets fully 
initialised,
 > it can be used for an accurate udelay(). x86 used to have an global data
 > flag that got set when the timer-subsystem got initialised. If the 
flag was
 > not set, udelay() would use one implementation, but if it was set, 
udelay()
 > would use a more accurate implementation. In the case of the eNET 
board, it
 > had an FPGA implementation of a microsecond timer which was even more
 > accurate that the CPU, so it had it's own implementation that should 
have
 > duplicated the 'if (gd->flags&  TIMER_INIT)' but never did (this was OK
 > because udelay() was never needed before then)
 >
 > I think a function pointer in gd would be a much neater way of 
handling the
 > fact that more accurate (and efficient) implementations of udelay() may
 > present themselves throughout the boot process
I think this won't be popular, but I am not against it on the face of it.
 >
 > An other option would be to have the gd flag and make udelay() a lib
 > function which performs the test - If the arch timer has better than 1us
 > resolution it can set the flag and udelay() will use the timer API
 >
 > 2a (random epoch) - The timer sub-system should not rely on a particular
 > epoch (1970, 1901, 0, 1, since boot, since timer init, etc...) - By 
using
 > the full range of an unsigned variable, the epoch does not matter
 >
 > 2b (time interval) - We need to pick a base resolution for the timer 
API -
 > Linux uses nano-seconds and I believe this is a good choice. Big Fat 
Note:
 > The underlying hardware DOES NOT need to have nano-second resolution. 
The
 > only issue with nano-seconds is that it mandates a 64-bit timer - A few
 > people are against this idea - lets discuss. A 32-bit microsecond timer
 > provides ~4300 seconds (~1.2 hours) which _might_ be long enough, but
 > stand-alone applications doing burn-in tests may need longer. Going
 > milli-seconds means we cannot piggy-back udelay() on the timer API.
Well, as you probably know, I am "one of those" against a 64 bit timer 
API to figure out if my disk is ready, especially if my hardware 
timebase does not support nanosecond resolution anyway. I think having a 
time base in milliseconds like we have now is perfectly adequate for 
"sane" bootloader usage. The requirement for the timer API would then be 
to provide the "current time" in millisecond resolution, and the time in 
as close to microsecond resolution as possible. This would be a "helper" 
function for udelay.  Udelay could then always be implemented using 
microseconds to ticks and getting the subtracting delta ticks from the 
target value.
If you can provide the first function, you can provide the second. They 
can usually be the same code with different constants involved. The gd-> 
call may actually be inside udelay, with the timer init replacing the 
pointer used by udelay to get the current time in "microseconds". The 
helper function for udelay should not be called by other parts of 
u-boot, to prevent abuse of this capability. Note that a 32 bit 
millisecond delay is like 49 days, so that should be plenty. I think it 
must be kept in mind that u-boot is used on lots of "small" systems. 
Using up lots of resources for 64 bit arithmetic that we don't need 
elsewhere is , IMHO, not a good idea. If it really did something that we 
need, all well and good, I am for it. But in this case, I don't think it 
really helps us any. But it does make things harder for some CPUs, and 
that is not a good thing.
 >
 > My preference is a 64-bit nano-second timer with ud

Re: [U-Boot] [PATCH v3] Add USB support for Efika

2011-09-24 Thread Fabio Estevam
On Sat, Sep 24, 2011 at 4:19 PM, Marek Vasut  wrote:
> On Saturday, September 24, 2011 09:07:14 PM Fabio Estevam wrote:
>> On Sat, Sep 24, 2011 at 12:57 PM, Remy Bohmer  wrote:
>> ...
>>
>> > I think it is a good idea to move these headers to include/usb.
>> > Patches are welcome.
>>
>> Will send a patch for this.
>
> No you won't, it's already in the works.

Sorry, just saw your email after sending the patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] FYI

2011-09-24 Thread Segle, Mary M
 
 
FYI
 
This is to inform you that I am a delegate from the United Nations Compensation 
Commission and to notify you finally about your outstanding Compensation Cheque 
payment of $2,811,041.00 USD.
 
Please Send your Name, Address, City, State, Zip Code, Country and telephone 
number to upsng2...@dgoh.org   for your cheque 
delivery.
 
Thanks for your attention.
 
Segle Mary
Deputy Special Representative
United Nation Compensation (UNCC)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/6] USB: Fix complaints about strict aliasing in OHCI-HCD

2011-09-24 Thread Marek Vasut
On Saturday, September 24, 2011 07:41:12 PM Remy Bohmer wrote:
> Hi Marek,
> 
> 2011/8/28 Marek Vasut :
> > Signed-off-by: Marek Vasut 
> > ---
> >  drivers/usb/host/ohci-hcd.c |   69
> > +++--- 1 files changed, 38
> > insertions(+), 31 deletions(-)
> 
> I guess this is a v3 of this patch. Am I right?

It's been a while here, but I think so, yes.

> 
> Kind regards,
> 
> Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] Add USB support for Efika

2011-09-24 Thread Marek Vasut
On Saturday, September 24, 2011 09:07:14 PM Fabio Estevam wrote:
> On Sat, Sep 24, 2011 at 12:57 PM, Remy Bohmer  wrote:
> ...
> 
> > I think it is a good idea to move these headers to include/usb.
> > Patches are welcome.
> 
> Will send a patch for this.

No you won't, it's already in the works.

> 
> Regards,
> 
> Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] usb: Move ehci.h and ehci-core.h to include/usb directory

2011-09-24 Thread Fabio Estevam
Move ehci.h and ehci-core.h to include/usb directory.

Cc: Remy Bohmer 
Signed-off-by: Fabio Estevam 
---
 drivers/usb/host/ehci-core.h |   29 --
 drivers/usb/host/ehci-fsl.c  |4 +-
 drivers/usb/host/ehci-hcd.c  |2 +-
 drivers/usb/host/ehci-ixp4xx.c   |4 +-
 drivers/usb/host/ehci-kirkwood.c |4 +-
 drivers/usb/host/ehci-mpc512x.c  |4 +-
 drivers/usb/host/ehci-mxc.c  |4 +-
 drivers/usb/host/ehci-pci.c  |4 +-
 drivers/usb/host/ehci-ppc4xx.c   |4 +-
 drivers/usb/host/ehci-vct.c  |4 +-
 drivers/usb/host/ehci.h  |  203 --
 include/usb/ehci-core.h  |   29 ++
 include/usb/ehci.h   |  203 ++
 13 files changed, 249 insertions(+), 249 deletions(-)
 delete mode 100644 drivers/usb/host/ehci-core.h
 delete mode 100644 drivers/usb/host/ehci.h
 create mode 100644 include/usb/ehci-core.h
 create mode 100644 include/usb/ehci.h

diff --git a/drivers/usb/host/ehci-core.h b/drivers/usb/host/ehci-core.h
deleted file mode 100644
index 39e5c5e..000
--- a/drivers/usb/host/ehci-core.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*-
- * Copyright (c) 2007-2008, Juniper Networks, Inc.
- * Copyright (c) 2008, Excito Elektronik i Skåne AB
- * All rights reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2 of
- * the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#ifndef USB_EHCI_CORE_H
-#define USB_EHCI_CORE_H
-
-extern int rootdev;
-extern struct ehci_hccr *hccr;
-extern volatile struct ehci_hcor *hcor;
-
-#endif
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 6e0043a..19b97ee 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -27,8 +27,8 @@
 #include 
 #include 
 
-#include "ehci.h"
-#include "ehci-core.h"
+#include 
+#include 
 
 /*
  * Create the appropriate control structures to manage
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 2197119..bdadd46 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include "ehci.h"
+#include 
 
 int rootdev;
 struct ehci_hccr *hccr;/* R/O registers, not need for volatile */
diff --git a/drivers/usb/host/ehci-ixp4xx.c b/drivers/usb/host/ehci-ixp4xx.c
index b8f15ae..d15237b 100644
--- a/drivers/usb/host/ehci-ixp4xx.c
+++ b/drivers/usb/host/ehci-ixp4xx.c
@@ -22,8 +22,8 @@
 #include 
 #include 
 
-#include "ehci.h"
-#include "ehci-core.h"
+#include 
+#include 
 /*
  * Create the appropriate control structures to manage
  * a new EHCI host controller.
diff --git a/drivers/usb/host/ehci-kirkwood.c b/drivers/usb/host/ehci-kirkwood.c
index 5570fc6..ab75acd 100644
--- a/drivers/usb/host/ehci-kirkwood.c
+++ b/drivers/usb/host/ehci-kirkwood.c
@@ -25,8 +25,8 @@
 #include 
 #include 
 #include 
-#include "ehci.h"
-#include "ehci-core.h"
+#include 
+#include 
 #include 
 
 #define rdl(off)   readl(KW_USB20_BASE + (off))
diff --git a/drivers/usb/host/ehci-mpc512x.c b/drivers/usb/host/ehci-mpc512x.c
index d360108..8d2c93b 100644
--- a/drivers/usb/host/ehci-mpc512x.c
+++ b/drivers/usb/host/ehci-mpc512x.c
@@ -32,8 +32,8 @@
 #include 
 #include 
 
-#include "ehci.h"
-#include "ehci-core.h"
+#include 
+#include 
 
 static void fsl_setup_phy(volatile struct ehci_hcor *);
 static void fsl_platform_set_host_mode(volatile struct usb_ehci *ehci);
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index a0cfbb7..fde1f0f 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -24,8 +24,8 @@
 #include 
 #include 
 
-#include "ehci.h"
-#include "ehci-core.h"
+#include 
+#include 
 
 #define USBCTRL_OTGBASE_OFFSET 0x600
 
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 020ab11..e1f84d9 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -22,8 +22,8 @@
 #include 
 #include 
 
-#include "ehci.h"
-#include "ehci-core.h"
+#include 
+#include 
 
 #ifdef CONFIG_PCI_EHCI_DEVICE
 static struct pci_device_id ehci_pci_ids[] = {
diff --git a/drivers/usb/host/ehci-ppc4xx.c b/drivers/usb/host/ehci-ppc4xx.c
index 1179919..1a1fae1 100644
--- a/drivers/usb/host/ehci-ppc4xx.c
+++ b/drivers/usb/host/ehci-ppc4xx.c
@@ -22,8 +22,8 @@
 #include 
 #include 
 
-#include "ehci.h"
-#include "ehci-core.h"
+#include 
+#include 
 
 /*
  * Create the appropria

Re: [U-Boot] [PATCH v3] Add USB support for Efika

2011-09-24 Thread Fabio Estevam
On Sat, Sep 24, 2011 at 12:57 PM, Remy Bohmer  wrote:
...
> I think it is a good idea to move these headers to include/usb.
> Patches are welcome.

Will send a patch for this.

Regards,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] World's Easiest Program, paying everybody daily

2011-09-24 Thread thomas peters
New Ricochet Riches pays you 2%+ in DAILY, PASSIVE Income!

NO REFERRING REQUIRED!

Become part of the Ricochet Riches Network of Passive Income programs! -
Everyone earns at Ricochet Riches.

* Earn 2%+ Daily (60%+ Monthly)
* Earn from Multiple Income Streams
* Start with as little as $10
* Compound your earnings for EXPONENTIAL Growth!
* 2 levels of Referral Commission - 10% from 1st level referrals - 5% from
2nd level Referrals

2 Simple Steps:

1) Register at Ricochet Riches
2) Purchase one or more RR Ad Unit for just $10 each

UPDATE:

Turbo 1x2 is coming to the Ricochet Riches Network!

Here are some brief details about the upcoming Turbo 1x2 addition:

* ONE-Time cost of $35
* Multiple Turbo positions allowed
* Incredibly small 1x2 matrix
* Pays $20 per cycle into available RR balance
* Pays 50% matching bonus when referrals cycle (into RR Ad Unit Balance for
MORE passive income)
* Unlimited Free re-entries

Every member of Ricochet Riches (Free or Paid) can participate in Turbo 1x2!

Your referrals will automatically follow you in to the other RR Network
programs that will be coming out such as the awesome new “Turbo1x2” that
will be opening up by this weekend as we start the RR Network expansion!

REMEMBER: NO REFERRING REQUIRED!

http://www.ricochetriches.com/?tmp74

To Your Success
Tom

P.S: Talk about stress free earning, just purchase your positions, sit back
and get PAID EVERYDAY - Now how EASY is that?

P.P.S:  Join Today & be one of the first in Turbo 1x2 when it launches! (You
heard it here first!)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Pull request: u-boot-usb

2011-09-24 Thread Remy Bohmer
The following changes since commit 279bbbca12e71ae68278b756048194003a6d6e21:

  Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-09-23
08:23:25 +0200)

are available in the git repository at:

  git://git.denx.de/u-boot-usb.git master

Marek Vasut (1):
  ASIX: Fix buffer access in asix_get_phy_addr()

 drivers/usb/eth/asix.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/6] USB: Fix complaints about strict aliasing in OHCI-HCD

2011-09-24 Thread Remy Bohmer
Hi Marek,

2011/8/28 Marek Vasut :
> Signed-off-by: Marek Vasut 
> ---
>  drivers/usb/host/ohci-hcd.c |   69 +++---
>  1 files changed, 38 insertions(+), 31 deletions(-)
>

I guess this is a v3 of this patch. Am I right?

Kind regards,

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] GCC4.6: Remove unused "port" variable in cmd_usb.c

2011-09-24 Thread Remy Bohmer
Hi,

2011/9/23 Marek Vasut :
> Signed-off-by: Marek Vasut 
> ---
>  common/cmd_usb.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/common/cmd_usb.c b/common/cmd_usb.c
> index cd4d417..8c87265 100644
> --- a/common/cmd_usb.c
> +++ b/common/cmd_usb.c
> @@ -281,7 +281,7 @@ static inline char *portspeed(int speed)
>  void usb_show_tree_graph(struct usb_device *dev, char *pre)
>  {
>        int i, index;
> -       int has_child, last_child, port;
> +       int has_child, last_child;
>
>        index = strlen(pre);
>        printf(" %s", pre);
> @@ -300,7 +300,6 @@ void usb_show_tree_graph(struct usb_device *dev, char 
> *pre)
>                                /* found our pointer, see if we have a
>                                 * little sister
>                                 */
> -                               port = i;
>                                while (i++ < dev->parent->maxchild) {
>                                        if (dev->parent->children[i] != NULL) {
>                                                /* found a sister */

If it was not part of a patch-series, I would have pulled it in directly...
Acked-by: Remy Bohmer 

Kind regards,

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 0/2] usb:gadget:s5p USB Device Controller (UDC) implementation

2011-09-24 Thread Remy Bohmer
Hi,

2011/9/16 Lukasz Majewski :
> Dear all,
>
>> This patch series adds support for Samsung's USB Device Controller
>> (UDC) on GONI reference target.
>>
>> ---
>> Depend on:
>> http://patchwork.ozlabs.org/patch/112847/
>>
>> Lukasz Majewski (2):
>>   usb:gadget:s5p USB Device Controller (UDC) implementation
>>   usb:gadget:s5p Enabling the USB Gadget framework at GONI
>
> Are there any comments about those patches?
> There wasn't any reply about them for some time...

Applied to u-boot-usb.
Thanks.

Kind regards,

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ASIX: Fix buffer access in asix_get_phy_addr()

2011-09-24 Thread Remy Bohmer
Hi,

2011/9/23 Marek Vasut :
> Signed-off-by: Marek Vasut 
> ---
>  drivers/usb/eth/asix.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c

Applied to u-boot-usb. Thanks.

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] USB: Add usb_event_poll() to get keyboards working with EHCI

2011-09-24 Thread Remy Bohmer
Hi,

2011/9/24 Marek Vasut :
> On Saturday, September 24, 2011 06:41:58 PM Remy Bohmer wrote:
>> Hi,
>>
>> 2011/9/23 Marek Vasut :
>> > Signed-off-by: Marek Vasut 
>> > Cc: Remy Bohmer 
>> > ---
>> >  drivers/usb/host/ehci-hcd.c |   33 -
>> >  1 files changed, 32 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
>> > index 52b98c2..5b53b3a 100644
>> > --- a/drivers/usb/host/ehci-hcd.c
>> > +++ b/drivers/usb/host/ehci-hcd.c
>> > @@ -27,6 +27,10 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#ifdef CONFIG_USB_KEYBOARD
>> > +#include 
>> > +extern unsigned char new[];
>> > +#endif
>> >
>> >  #include "ehci.h"
>> >
>> > @@ -914,5 +918,32 @@ submit_int_msg(struct usb_device *dev, unsigned long
>> > pipe, void *buffer,
>> >
>> >        debug("dev=%p, pipe=%lu, buffer=%p, length=%d, interval=%d",
>> >              dev, pipe, buffer, length, interval);
>> > -       return -1;
>> > +       return ehci_submit_async(dev, pipe, buffer, length, NULL);
>>
>> Why is changing this line needed?
>
> To actually submit the interrupt request ?

Was just checking... at first impression it appeared to be some
unrelated change. While looking at it in its context it seems indeed
logical.

> Ah right ... there must be some changes in my repo or u-boot-imx/next ... will
> do in my next submission round.

OK. I will pull it in then.

Kind regards,

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] USB: Add usb_event_poll() to get keyboards working with EHCI

2011-09-24 Thread Marek Vasut
On Saturday, September 24, 2011 06:41:58 PM Remy Bohmer wrote:
> Hi,
> 
> 2011/9/23 Marek Vasut :
> > Signed-off-by: Marek Vasut 
> > Cc: Remy Bohmer 
> > ---
> >  drivers/usb/host/ehci-hcd.c |   33 -
> >  1 files changed, 32 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> > index 52b98c2..5b53b3a 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> > @@ -27,6 +27,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#ifdef CONFIG_USB_KEYBOARD
> > +#include 
> > +extern unsigned char new[];
> > +#endif
> > 
> >  #include "ehci.h"
> > 
> > @@ -914,5 +918,32 @@ submit_int_msg(struct usb_device *dev, unsigned long
> > pipe, void *buffer,
> > 
> >debug("dev=%p, pipe=%lu, buffer=%p, length=%d, interval=%d",
> >  dev, pipe, buffer, length, interval);
> > -   return -1;
> > +   return ehci_submit_async(dev, pipe, buffer, length, NULL);
> 
> Why is changing this line needed?

To actually submit the interrupt request ?

> 
> > +}
> > +
> > +#ifdef CONFIG_SYS_USB_EVENT_POLL
> > +/*
> > + * This function polls for USB keyboard data.
> > + */
> > +void usb_event_poll()
> > +{
> > +   struct stdio_dev *dev;
> > +   struct usb_device *usb_kbd_dev;
> > +   struct usb_interface *iface;
> > +   struct usb_endpoint_descriptor *ep;
> > +   int pipe;
> > +   int maxp;
> > +
> > +   /* Get the pointer to USB Keyboard device pointer */
> > +   dev = stdio_get_by_name("usbkbd");
> > +   usb_kbd_dev = (struct usb_device *)dev->priv;
> > +   iface = &usb_kbd_dev->config.if_desc[0];
> > +   ep = &iface->ep_desc[0];
> > +   pipe = usb_rcvintpipe(usb_kbd_dev, ep->bEndpointAddress);
> > +
> > +   /* Submit a interrupt transfer request */
> > +   maxp = usb_maxpacket(usb_kbd_dev, pipe);
> > +   usb_submit_int_msg(usb_kbd_dev, pipe, &new[0],
> > +   maxp > 8 ? 8 : maxp, ep->bInterval);
> >  }
> > +#endif /* CONFIG_SYS_USB_EVENT_POLL */
> 
> Patch does not apply to u-boot-usb master.
> Please rebase this patch.

Ah right ... there must be some changes in my repo or u-boot-imx/next ... will 
do in my next submission round.

Cheers

> 
> Kind regards,
> 
> Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] USB: Add usb_event_poll() to get keyboards working with EHCI

2011-09-24 Thread Remy Bohmer
Hi,

2011/9/23 Marek Vasut :
> Signed-off-by: Marek Vasut 
> Cc: Remy Bohmer 
> ---
>  drivers/usb/host/ehci-hcd.c |   33 -
>  1 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 52b98c2..5b53b3a 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -27,6 +27,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_USB_KEYBOARD
> +#include 
> +extern unsigned char new[];
> +#endif
>
>  #include "ehci.h"
>
> @@ -914,5 +918,32 @@ submit_int_msg(struct usb_device *dev, unsigned long 
> pipe, void *buffer,
>
>        debug("dev=%p, pipe=%lu, buffer=%p, length=%d, interval=%d",
>              dev, pipe, buffer, length, interval);
> -       return -1;
> +       return ehci_submit_async(dev, pipe, buffer, length, NULL);

Why is changing this line needed?

> +}
> +
> +#ifdef CONFIG_SYS_USB_EVENT_POLL
> +/*
> + * This function polls for USB keyboard data.
> + */
> +void usb_event_poll()
> +{
> +       struct stdio_dev *dev;
> +       struct usb_device *usb_kbd_dev;
> +       struct usb_interface *iface;
> +       struct usb_endpoint_descriptor *ep;
> +       int pipe;
> +       int maxp;
> +
> +       /* Get the pointer to USB Keyboard device pointer */
> +       dev = stdio_get_by_name("usbkbd");
> +       usb_kbd_dev = (struct usb_device *)dev->priv;
> +       iface = &usb_kbd_dev->config.if_desc[0];
> +       ep = &iface->ep_desc[0];
> +       pipe = usb_rcvintpipe(usb_kbd_dev, ep->bEndpointAddress);
> +
> +       /* Submit a interrupt transfer request */
> +       maxp = usb_maxpacket(usb_kbd_dev, pipe);
> +       usb_submit_int_msg(usb_kbd_dev, pipe, &new[0],
> +                       maxp > 8 ? 8 : maxp, ep->bInterval);
>  }
> +#endif /* CONFIG_SYS_USB_EVENT_POLL */

Patch does not apply to u-boot-usb master.
Please rebase this patch.

Kind regards,

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm, usb, davinci: make USBPHY_CTL register configurable

2011-09-24 Thread Remy Bohmer
Hi,

> Hmm.. Anyway I have to resend the cam_enc_4xx board port, as now the new
> SPL Framework is in mainline, and my post used the old one. Also
> I added in the meantime USB support for it, for which I needed this patch.
> But actually I am wating for a new HW, so I can't test it ... and then
> I post this patchset again with this patch in it! Can I add then your
> "Acked-by" for this patch?

Acked-by: Remy Bohmer 

Kind regards,

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] Add USB support for Efika

2011-09-24 Thread Remy Bohmer
Hi Stefano,

2011/9/19 Stefano Babic :
> you change several files, some of them in the general USB support. You
> must then split your patch into a patchset, and each patch must address
> a single issue. Really with your patch you do not only add USB support
> to the EfikaMX board, but you want to add support for MX5 Soc and maybe
> fix some issues. And if you change some general USB files, you should

I agree that this patch must be split up into a patchset.

> add in CC the USB maintainer (Remy, I have already added him in my answer).

Thanks.

>> +#include "../../drivers/usb/host/ehci.h"
>> +#include "../../drivers/usb/host/ehci-core.h"
>
> This seems to me pretty nasty - but it is not the only example in u-boot
> including files from drivers/. Can we imagine to move these files into
> the include directory ?

I think it is a good idea to move these headers to include/usb.
Patches are welcome.

Kind regards,

Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/4] Buffer overruns in printf

2011-09-24 Thread Simon Glass
Hi Albert,

On Sat, Sep 24, 2011 at 2:37 AM, Albert ARIBAUD
 wrote:
> Le 23/09/2011 22:46, Simon Glass a écrit :
>>
>> Hi Albert,
>>
>> On Fri, Sep 23, 2011 at 1:40 PM, Albert ARIBAUD
>>   wrote:
>>>
>>> Hi Simon,
>>>
>>> Le 23/09/2011 19:38, Simon Glass a écrit :

 The printf family of functions in U-Boot cannot deal with a situation
 where
 the caller provides a buffer which turns out to be too small for the
 format
 string. This can result in buffer overflows, stack overflows and other
 bad
 behavior.
>>>
>>> Indeed overruns can lead to bad behaviors, but in any case, it can never
>>> be
>>> recovered, because at the root, the problem is that the caller provided
>>> inconsistent arguments to printf.
>>
>> Recovery is one thing, but I would settle for just not crashing, which
>> is the purpose of this patch. We could also easily WARN if that were
>> considered appropriate here.
>>
>>>
>>> So in essence, you're 'fixing' printf for a design error in printf's
>>> caller,
>>> instead of fixing the design error.
>>
>> Well, the nature of a function is that it cannot know what arguments
>> might be passed to it. It can only assert(), limit check, etc. A limit
>> check is what this patch aims to add.
>
> I do agree that as a rule, a function should check its arguments, but as any
> rule, this one has understated assumptions. Here, one assumption is that
> calls to the functions cannot be made compliant, and therefore it falls to
> the function to ensure this compliance; and another one is that the function
> can actually check this conformance.

There is also the issue of programmer error, or unexpected situations,
and graceful failure in these cases. We want to avoid hard-to-find
memory/stack corruption bugs if the cost of doing so is moderate.

>
> The first assumption is correct in an OS or general-purpose library where
> the number of callers is virtually unlimited and there is no way to make
> sure all calls are conforming.
>
> In U-Boot however, the number of callers is bound and known (unless you're
> thinking of standalone U-Boot apps, but I don't see this as a use case so
> frequent that it warrants a 'fix')

Yes, and one can inspect each call and decide if the nprint() variants
are preferable in each case.
>
> The second assumption is false by nature for printf(), which simply cannot
> check its input buffer (OTOH *nprintf() does, and it is its job).
>
> Besides, there *is* a sub-family of printf functions which are dedicated to
> the case where buffers provided may be too small for the print output --
> meaning that the issue is known and an easy fix exists if cropping the
> output is allowable.

Yes, or even if cropping is not allowed, we might expect a nice error,
rather than a crash sometime later when the stack corruption or data
space overwriting causes problems.
>
> So basically the choice is between:
>
> - adding code to the printf() family to try and fix an issue that it is
> fundamentally unable to properly fix, and for which a solution exists, or
>
> - grepping and fixing calls to *sprintf() in U-Boot that do not respect the
> known contraints of printf(), by resizing the buffer or calling *snprintf()
> instead.
>
> I am definitely not in favor of the first option concerning U-Boot.

Sounds fine to me. So I think we need the nprintf() variants in there,
but the message is not to use them willy nilly. Going back to my patch
series, 3/4 is ok, but 4/4 mostly crosses the line. Do I have that
right?

By the way, printf() ends up calling the same code, but without limit
checking in place. The alternative is to duplicate all the format
string processing code (a limit-checking version and an unchecked
version) which would be worse.

> Amicalement,
> --
> Albert.
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation

2011-09-24 Thread Marek Vasut
On Friday, September 23, 2011 07:35:15 PM Scott Wood wrote:
> On 09/22/2011 03:51 AM, Marek Vasut wrote:
> > On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote:
> >> On 09/21/2011 10:16 PM, Wolfgang Denk wrote:
> >>> Dear Stefano & Marek,
> >>> 
> >>> can you please provide the requested information?
> >> 
> >> Hi Scott,
> >> 
> >>> In message <4e7a4145.30...@freescale.com> Scott Wood wrote:
> > In message <4e7a320d.1030...@freescale.com> you wrote:
> >> Is this hardware going to be supported in Linux?  It would be nice
> >> if we could keep this code in sync.
> > 
> > Stefano has submitted patches for the iMX28 based M28 / M28EVK board,
> > so yes, this hardware going to be supported in mainline Linux, too.
>  
>  How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS?
>  
>  I'd like to see this change be submitted to Linux first, or else have
>  an explanation of why a divergence for U-Boot is warranted.
> >> 
> >> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije:
> >>http://www.spinics.net/lists/arm-kernel/msg139526.html
> >> 
> >> However, I have not seen the option NAND_OWN_BUFFERS in his patches.
> >> 
> >> Best regards,
> >> Stefano
> > 
> > Like I said, this patch is not needed anymore. It's just a convenience
> > measure now. I don't need to for mx28.
> 
> Let's hold off on this patch until it's actually needed, then.

Very well then, mind merging the rest then ?

Cheers
> 
> -Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] ucdragon.com

2011-09-24 Thread Alex





Preferred Domain Availability Notice:
ucdragon.com will be listed for auction in a few days.  This domain might be 
useful for you, since you own a domain similar to this domain.
To express interest in owning this domain, fill out the simple form here: 
ucdragon.com
 
Sincerely,Alexander
330 Franklin Road #135A

Suite 186

Brentwood, TN  37027
 
If you do not want more of these messages, please click the link above and 
follow instructions at the bottom of the page
Something to ponder: Pleasure in the job puts perfection in the work.  -- 
Aristotle

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Building u-boot for Walnut board (PPC 405GPr)

2011-09-24 Thread Anatolij Gustschin
Hi,

On Fri, 23 Sep 2011 18:11:28 -0700
"Brian S. Park"  wrote:

> Hi,
> I'm currently working on updating the firmware on our custom board 
> (based on IBM walnut board) and tried to build the latest released 
> u-boot 2011.06 using ELDK4.2.
> Using the fresh source code extracted from u-boot-2011.06.tar.bz2,  I 
> did "make walnut_config" and then "make". But I get the following error.
> 
> ppc_4xx-ld:u-boot.lds:1: parse error
> make: *** [u-boot] Error 1
> 
> All of the code compiles. I think it's a linker error but I have no idea 
> how to resolve the problem.
> Any help would be appreciated.

$ wget -c ftp://ftp.denx.de/pub/u-boot/u-boot-2011.06.tar.bz2
$ tar xf u-boot-2011.06.tar.bz2
$ cd u-boot-2011.06/
$ export CROSS_COMPILE=ppc_4xx-
$ ./MAKEALL walnut
Configuring for walnut board...
   textdata bss dec hex filename
 219550   19468   42544  281562   44bda ./u-boot

- SUMMARY 
Boards compiled: 1
--

There is no such problem with walnut board in the v2011.06 release.
Please double-check our source.

HTH,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/4] Buffer overruns in printf

2011-09-24 Thread Albert ARIBAUD
Le 23/09/2011 22:46, Simon Glass a écrit :
> Hi Albert,
>
> On Fri, Sep 23, 2011 at 1:40 PM, Albert ARIBAUD
>   wrote:
>> Hi Simon,
>>
>> Le 23/09/2011 19:38, Simon Glass a écrit :
>>>
>>> The printf family of functions in U-Boot cannot deal with a situation
>>> where
>>> the caller provides a buffer which turns out to be too small for the
>>> format
>>> string. This can result in buffer overflows, stack overflows and other bad
>>> behavior.
>>
>> Indeed overruns can lead to bad behaviors, but in any case, it can never be
>> recovered, because at the root, the problem is that the caller provided
>> inconsistent arguments to printf.
>
> Recovery is one thing, but I would settle for just not crashing, which
> is the purpose of this patch. We could also easily WARN if that were
> considered appropriate here.
>
>>
>> So in essence, you're 'fixing' printf for a design error in printf's caller,
>> instead of fixing the design error.
>
> Well, the nature of a function is that it cannot know what arguments
> might be passed to it. It can only assert(), limit check, etc. A limit
> check is what this patch aims to add.

I do agree that as a rule, a function should check its arguments, but as 
any rule, this one has understated assumptions. Here, one assumption is 
that calls to the functions cannot be made compliant, and therefore it 
falls to the function to ensure this compliance; and another one is that 
the function can actually check this conformance.

The first assumption is correct in an OS or general-purpose library 
where the number of callers is virtually unlimited and there is no way 
to make sure all calls are conforming.

In U-Boot however, the number of callers is bound and known (unless 
you're thinking of standalone U-Boot apps, but I don't see this as a use 
case so frequent that it warrants a 'fix')

The second assumption is false by nature for printf(), which simply 
cannot check its input buffer (OTOH *nprintf() does, and it is its job).

Besides, there *is* a sub-family of printf functions which are dedicated 
to the case where buffers provided may be too small for the print output 
-- meaning that the issue is known and an easy fix exists if cropping 
the output is allowable.

So basically the choice is between:

- adding code to the printf() family to try and fix an issue that it is 
fundamentally unable to properly fix, and for which a solution exists, or

- grepping and fixing calls to *sprintf() in U-Boot that do not respect 
the known contraints of printf(), by resizing the buffer or calling 
*snprintf() instead.

I am definitely not in favor of the first option concerning U-Boot.

> Regards,
> Simon

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot