Re: [U-Boot] [PATCH] serial: 16550: properly initialize fcr field of ns16550_platdata
Heiko Schocher (h...@denx.de) wrote: > Hello Oleksandr, > > Am 01.02.2017 um 19:52 schrieb Oleksandr Tymoshenko: > > Tom Rini (tr...@konsulko.com) wrote: > >> On Tue, Jan 31, 2017 at 05:15:20PM -0800, Oleksandr Tymoshenko wrote: > >> > >>> Default fcr value is initialized in ns16550_serial_ofdata_to_platdata > >>> but this function is only called if OF_CONTROL option is enabled while > >>> the field is used whenever DM_SERIAL is set. So for configs that > >>> do not have OF_CONTROL default fcr value is set to zero which leads > >>> to loosing characters when serial port input is faster than reading > >>> routine i.e. when copy-pasting long line to U-Boot prompt. > >>> > >>> As a fix initialize fcr field in probe method > >>> > >>> Signed-off-by: Oleksandr Tymoshenko <go...@bluezbox.com> > >>> Cc: Marek Vasut <ma...@denx.de> > >>> Cc: Tom Rini <tr...@konsulko.com> > >>> Cc: Simon Glass <s...@chromium.org> > >> > >> Are you still seeing this with v2017.03-rc1? Thanks! > > > > No, this bug is not reproducible on v2017.03-rc1, I believe 17fa032671 > > fixed it. Not sure how I missed that patch I am pretty sure I tested my > > BBB with master branch. > > Yes commit 17fa032671 fixed this issue. How do you test? You must > type very fast, or copy a long command ... Hi Heiko, I copy-pasted long lines for my test. I think I used 2017.01 for my test, not master. That's why I didn't realise that the bug is fixed in the latest version. -- gonzo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: 16550: properly initialize fcr field of ns16550_platdata
Tom Rini (tr...@konsulko.com) wrote: > On Tue, Jan 31, 2017 at 05:15:20PM -0800, Oleksandr Tymoshenko wrote: > > > Default fcr value is initialized in ns16550_serial_ofdata_to_platdata > > but this function is only called if OF_CONTROL option is enabled while > > the field is used whenever DM_SERIAL is set. So for configs that > > do not have OF_CONTROL default fcr value is set to zero which leads > > to loosing characters when serial port input is faster than reading > > routine i.e. when copy-pasting long line to U-Boot prompt. > > > > As a fix initialize fcr field in probe method > > > > Signed-off-by: Oleksandr Tymoshenko <go...@bluezbox.com> > > Cc: Marek Vasut <ma...@denx.de> > > Cc: Tom Rini <tr...@konsulko.com> > > Cc: Simon Glass <s...@chromium.org> > > Are you still seeing this with v2017.03-rc1? Thanks! No, this bug is not reproducible on v2017.03-rc1, I believe 17fa032671 fixed it. Not sure how I missed that patch I am pretty sure I tested my BBB with master branch. Thanks -- gonzo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: 16550: properly initialize fcr field of ns16550_platdata
Default fcr value is initialized in ns16550_serial_ofdata_to_platdata but this function is only called if OF_CONTROL option is enabled while the field is used whenever DM_SERIAL is set. So for configs that do not have OF_CONTROL default fcr value is set to zero which leads to loosing characters when serial port input is faster than reading routine i.e. when copy-pasting long line to U-Boot prompt. As a fix initialize fcr field in probe method Signed-off-by: Oleksandr Tymoshenko <go...@bluezbox.com> Cc: Marek Vasut <ma...@denx.de> Cc: Tom Rini <tr...@konsulko.com> Cc: Simon Glass <s...@chromium.org> --- drivers/serial/ns16550.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 2df4a1f..2b30a4f 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -352,6 +352,7 @@ int ns16550_serial_probe(struct udevice *dev) struct NS16550 *const com_port = dev_get_priv(dev); com_port->plat = dev_get_platdata(dev); + com_port->plat->fcr = UART_FCR_DEFVAL; NS16550_init(com_port, -1); return 0; @@ -437,7 +438,6 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev) return -EINVAL; } - plat->fcr = UART_FCR_DEFVAL; if (port_type == PORT_JZ4780) plat->fcr |= UART_FCR_UME; -- 2.9.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs/fat: Fix unaligned __u16 reads for FAT12 access
Brüns, Stefan (stefan.bru...@rwth-aachen.de) wrote:
> Doing unaligned reads is not supported on all architectures, use
> byte sized reads of the little endian buffer.
> Rename off16 to off8, as it reflects the buffer offset in byte
> granularity (offset is in entry, i.e. 12 bit, granularity).
> Fix a regression introduced in 8d48c92b45aea91e2a2be90f2ed93677e85526f1
>
> Reported-by: Oleksandr Tymoshenko <go...@bluezbox.com>
> Signed-off-by: Stefan Brüns <stefan.bru...@rwth-aachen.de>
> ---
> fs/fat/fat.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index fe899d0442..06088e2421 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -179,7 +179,7 @@ int flush_dirty_fat_buffer(fsdata *mydata)
> static __u32 get_fatent(fsdata *mydata, __u32 entry)
> {
> __u32 bufnum;
> - __u32 off16, offset;
> + __u32 offset, off8;
> __u32 ret = 0x00;
>
> if (CHECK_CLUST(entry, mydata->fatsize)) {
> @@ -242,8 +242,9 @@ static __u32 get_fatent(fsdata *mydata, __u32 entry)
> ret = FAT2CPU16(((__u16 *) mydata->fatbuf)[offset]);
> break;
> case 12:
> - off16 = (offset * 3) / 2;
> - ret = FAT2CPU16(*(__u16 *)(mydata->fatbuf + off16));
> + off8 = (offset * 3) / 2;
> + /* fatbut + off8 may be unaligned, read in byte granularity */
> + ret = mydata->fatbuf[off8] + mydata->fatbuf[off8 + 1] << 8;
This patch when applied gives me "Invalid FAT entry" message. Reason
is: operator '<<' has lower precedence than '+' so this expression is
equivalent to (mydata->fatbuf[off8] + mydata->fatbuf[off8 + 1]) << 8
With explicit parentheses around shift it works as expected:
ret = mydata->fatbuf[off8] + (mydata->fatbuf[off8 + 1] << 8);
--
gonzo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] FAT12 regression after 8d48c92b45aea91e2a2be90f2ed93677e85526f1
Hello, U-Boot 2017.01 and master branch is broken on BeagleBone Black with boot partition formatted as FAT12, it hang after printing "Loading u-boot.img" message. I bisected regression to this patch: http://lists.denx.de/pipermail/u-boot/2016-December/276305.html This code simplification is not going to work on architectures with strict alignment requirements: + ret = FAT2CPU16(*(__u16 *)(mydata->fatbuf + off16)); fatbuf is a pointer to __u8 and off16 can take any values so mydata->fatbuf + off16 is not guaranteed to be 16-bits aligned and 16-bit access to non-aligned address will cause exception. -- gonzo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] efi: Use device device path type Messaging for network interface node
When adding network interface node use Messaging device path with
subtype MAC Address and device's MAC address as a value instead
of Media Device path type with subtype File Path and path "Net"
Signed-off-by: Oleksandr Tymoshenko <go...@bluezbox.com>
Cc: Alexander Graf <ag...@suse.de>
---
include/efi_api.h| 13 +
lib/efi_loader/efi_net.c | 17 +
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index bdb600e..5c3836a 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -268,6 +268,19 @@ struct efi_device_path {
u16 length;
};
+struct efi_mac_addr {
+ u8 addr[32];
+};
+
+#define DEVICE_PATH_TYPE_MESSAGING_DEVICE 0x03
+# define DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR0x0b
+
+struct efi_device_path_mac_addr {
+ struct efi_device_path dp;
+ struct efi_mac_addr mac;
+ u8 if_type;
+};
+
#define DEVICE_PATH_TYPE_MEDIA_DEVICE 0x04
# define DEVICE_PATH_SUB_TYPE_FILE_PATH 0x04
diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index 3796496..604ac6e 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -27,7 +27,8 @@ struct efi_net_obj {
struct efi_simple_network net;
struct efi_simple_network_mode net_mode;
/* Device path to the network adapter */
- struct efi_device_path_file_path dp[2];
+ struct efi_device_path_mac_addr dp_mac;
+ struct efi_device_path_file_path dp_end;
/* PXE struct to transmit dhcp data */
struct efi_pxe pxe;
struct efi_pxe_mode pxe_mode;
@@ -205,7 +206,7 @@ static efi_status_t EFIAPI efi_net_open_dp(void *handle,
efi_guid_t *protocol,
struct efi_simple_network *net = handle;
struct efi_net_obj *netobj = container_of(net, struct efi_net_obj, net);
- *protocol_interface = netobj->dp;
+ *protocol_interface = >dp_mac;
return EFI_SUCCESS;
}
@@ -236,11 +237,10 @@ void efi_net_set_dhcp_ack(void *pkt, int len)
int efi_net_register(void **handle)
{
struct efi_net_obj *netobj;
- struct efi_device_path_file_path dp_net = {
- .dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE,
- .dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH,
+ struct efi_device_path_mac_addr dp_net = {
+ .dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE,
+ .dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR,
.dp.length = sizeof(dp_net),
- .str = { 'N', 'e', 't' },
};
struct efi_device_path_file_path dp_end = {
.dp.type = DEVICE_PATH_TYPE_END,
@@ -279,8 +279,9 @@ int efi_net_register(void **handle)
netobj->net.receive = efi_net_receive;
netobj->net.mode = >net_mode;
netobj->net_mode.state = EFI_NETWORK_STARTED;
- netobj->dp[0] = dp_net;
- netobj->dp[1] = dp_end;
+ netobj->dp_mac = dp_net;
+ netobj->dp_end = dp_end;
+ memcpy(netobj->dp_mac.mac.addr, eth_get_ethaddr(), 6);
memcpy(netobj->net_mode.current_address.mac_addr, eth_get_ethaddr(), 6);
netobj->net_mode.max_packet_size = PKTSIZE;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: rtl8169: Fix return value for rtl_send_common
> On Jul 4, 2016, at 8:40 AM, Simon Glass <s...@chromium.org> wrote: > > On 1 July 2016 at 14:22, Oleksandr Tymoshenko <go...@bluezbox.com> wrote: >> Return value of rtl_send_common propogates unmodified all the way >> up to eth_send and further to API consumer if CONFIG_API is enabled. >> Previously rtl_send_common returned number of bytes sent on success >> which was erroneouly detected as error condition by API consumers >> that checked for operation success by comparing return value with 0. >> >> Switch rtl_send_common to use common convention: return 0 on success >> and negative value for failure. >> >> Cc: Stephen Warren <swar...@nvidia.com> >> Cc: Joe Hershberger <joe.hershber...@ni.com> >> Signed-off-by: Oleksandr Tymoshenko <go...@bluezbox.com> >> --- >> drivers/net/rtl8169.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > Reviewed-by: Simon Glass <s...@chromium.org> > > But I'd like to see a function comment on rtl_send_common(), and on > the driver-model send() method in struct eth_ops, for that matter. Hi Simon, Should I submit new version or is it OK to submit new patch with comments added to these two functions? Thank you ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: rtl8169: Fix return value for rtl_send_common
Return value of rtl_send_common propogates unmodified all the way
up to eth_send and further to API consumer if CONFIG_API is enabled.
Previously rtl_send_common returned number of bytes sent on success
which was erroneouly detected as error condition by API consumers
that checked for operation success by comparing return value with 0.
Switch rtl_send_common to use common convention: return 0 on success
and negative value for failure.
Cc: Stephen Warren <swar...@nvidia.com>
Cc: Joe Hershberger <joe.hershber...@ni.com>
Signed-off-by: Oleksandr Tymoshenko <go...@bluezbox.com>
---
drivers/net/rtl8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 843b083..1cc0b40 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -666,12 +666,12 @@ static int rtl_send_common(pci_dev_t dev, unsigned long
dev_iobase,
puts("tx timeout/error\n");
printf("%s elapsed time : %lu\n", __func__, currticks()-stime);
#endif
- ret = 0;
+ ret = -ETIMEDOUT;
} else {
#ifdef DEBUG_RTL8169_TX
puts("tx done\n");
#endif
- ret = length;
+ ret = 0;
}
/* Delay to make net console (nc) work properly */
udelay(20);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot DWC2 unused variables
On 2014-02-03, at 10:34 PM, Stephen Warren swar...@wwwdotorg.org wrote:
Oleksandr,
Thanks for the quick response on the s-o-b lines. Another question: The
compiler is complaining about hprt0 being written but then not used in
the functions below. I assume the second parameter passed to
dwc_write_reg32() should be hprt0.d32 rather than val?
Yes, I think you're right. My mistake.
void dwc_otg_set_prtpower(dwc_otg_core_if_t * core_if, uint32_t val)
{
hprt0_data_t hprt0;
hprt0.d32 = dwc_read_reg32(core_if-host_if-hprt0);
hprt0.b.prtpwr = val;
dwc_write_reg32(core_if-host_if-hprt0, val);
}
void dwc_otg_set_prtsuspend(dwc_otg_core_if_t * core_if, uint32_t val)
{
hprt0_data_t hprt0;
hprt0.d32 = dwc_read_reg32(core_if-host_if-hprt0);
hprt0.b.prtsusp = val;
dwc_write_reg32(core_if-host_if-hprt0, val);
}
void dwc_otg_set_prtresume(dwc_otg_core_if_t * core_if, uint32_t val)
{
hprt0_data_t hprt0;
hprt0.d32 = dwc_read_reg32(core_if-host_if-hprt0);
hprt0.b.prtres = val;
dwc_write_reg32(core_if-host_if-hprt0, val);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Signed-off-by for RPI U-Boot USB patches
On 2014-02-01, at 10:17 PM, Stephen Warren swar...@wwwdotorg.org wrote: (Sorry for the spam; resending with the correct U-Boot mailing list in CC) On 02/01/2014 11:14 PM, Stephen Warren wrote: Oleksandr, I'm starting to look at getting USB support enabled for the Raspberry Pi in mainline U-Boot. To that end, I looked at: git://github.com/gonzoua/u-boot-pi.git rpi I took the DWC driver from there and applied it to a very recent mainline U-Boot. It works very well:-) Nice to know :) Thanks for bringing this stuff to upstream. The main thing preventing me from sending the driver for inclusion in mainline U-Boot is that none of the commits in that branch contain a Signed-off-by tag from you. Could you please reply here with your s-o-b line for all the commits listed below? I really should start using commit -s :) Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com Thank you very much! For details of what s-o-b means, please see https://www.kernel.org/doc/Documentation/SubmittingPatches section 12 Sign your work. (There's also a standalone website containing that section now, but I can't for the life of me find it...) b22090f Fix usb_lowlevel_init and usb_lowlevel_stop 8d5c624 Merge of doom: update to latest u-boot cd2dac2 Increase buffer for bulk transfers and make virtual hub highspeed fc4164b Enable USB mass storage support 9085155 Increase timeout for soft reset 4b3863c More sophysticated initialization code 8cb8ecc Rmeove hardcoded MAC address 6ab7258 Report error, do not hang 9e5763c Fix typo and whitespaces d141598 Fix memory layout for U-Boot 5d8b20f Cleanup and add function declarations eb2bb98 Add sanity check, just in case 8c85e48 Clean up mess with buffers d8fb4c3 Get rid of device-specific structures/registers ce7f827 Merge branch 'rpi' of github.com:gonzoua/u-boot-pi into rpi a78f29e Slap licenses on top of the newly created files d80dd6a Remove debug level cc7227e Minor cleanup 0d3c12f More stable CONTROL transfers, working BULK transfers 9da26b0 Remove debug output 70f4b54 Add support for USB ethernet and SMSC95XX ae9e5fc Add stripped-down version of Linux driver for DWC OTG a1bfc20 Skeleton DWC OTG driver implementation b47e41c Slap licenses on top of the newly created files ded1dc9 Remove debug level 602704e Minor cleanup ecc6e3d More stable CONTROL transfers, working BULK transfers d966ac2 Add support for USB ethernet and SMSC95XX 71633e5 Add stripped-down version of Linux driver for DWC OTG 182c5b0 Skeleton DWC OTG driver implementation (yes, there are duplicate entries in that list, because there are in the git tree I took the code from) ___ linux-rpi-kernel mailing list linux-rpi-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] S-o-b entries for bcm2708 SDHCI driver in the downstream R.Pi Linux kernel
On 2012-11-07, at 9:38 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/07/2012 01:47 PM, Oleksandr Tymoshenko wrote: On 11/6/2012 6:58 PM, Stephen Warren wrote: On 10/26/2012 10:54 PM, Stephen Warren wrote: (Sorry for the resend; I sent this to the wrong U-Boot mailing list the first time around) Dom, ddv2005, Gray, I'm trying to get Signed-off-by lines for all code in the Raspberry Pi Linux kernel trees related to the SDHCI driver (or just everything). The list of relevant commits for SDHCI is below. Can you please check Documentation/SubmittingPatches in the kernel source tree, and if you're able to, provide your Signed-of-by lines for all of the patches I list below that were either authored by you, or passed through you (the latter I assume mainly in the case of Dom who applied these to git). I've taken a closer look at the downstream Raspberry Pi kernel trees and I see that the very first bcm2708 commit in the rpi-3.6.y branch contains all the code that's been used by the U-Boot MMC driver port. commit f5b930be71d6de64c3264b2f9eff4a4079d50c14 Author: popcornmix popcorn...@gmail.com AuthorDate: Tue Jan 17 19:20:11 2012 + Commit: popcornmix popcorn...@gmail.com CommitDate: Mon Oct 8 16:25:24 2012 +0100 Main bcm2708 linux port Signed-off-by: popcornmix popcorn...@gmail.com This commit is actually already signed off by popcornmix, and Dom Cobley previously indicated that's him, and gave his permission to rewrite that S-o-b to his real name. Oleksandr, I believe that means that if you can give your S-o-b to the U-Boot patch you created based on Dom's kernel code, we will be good to go with the U-Boot patch I posted, and I can then repost it including fixes for the review feedback it received. I believe this is the only commit I made to SDHCI-related code: commit c78b8ea9ae717432770843b825ea8a1a77f223fc Author: Oleksandr Tymoshenko go...@bluezbox.com Date: Wed Jun 20 11:53:07 2012 -0700 Add driper for R-Pi eMMC controller Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com Thanks for that S-o-b. I also picked up some of the code from the following commit of yours: commit 1c2b43a634955661d6f7b69459de00ffd1c2d7a6 Author: Oleksandr Tymoshenko go...@bluezbox.com Date: Tue Jul 3 19:57:37 2012 -0700 Workaround insufficient timeouts in u-boot commit 1c2b43a634955661d6f7b69459de00ffd1c2d7a6 Author: Oleksandr Tymoshenko go...@bluezbox.com Date: Tue Jul 3 19:57:37 2012 -0700 Workaround insufficient timeouts in u-boot Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] S-o-b entries for bcm2708 SDHCI driver in the downstream R.Pi Linux kernel
On 11/6/2012 6:58 PM, Stephen Warren wrote: On 10/26/2012 10:54 PM, Stephen Warren wrote: (Sorry for the resend; I sent this to the wrong U-Boot mailing list the first time around) Dom, ddv2005, Gray, I'm trying to get Signed-off-by lines for all code in the Raspberry Pi Linux kernel trees related to the SDHCI driver (or just everything). The list of relevant commits for SDHCI is below. Can you please check Documentation/SubmittingPatches in the kernel source tree, and if you're able to, provide your Signed-of-by lines for all of the patches I list below that were either authored by you, or passed through you (the latter I assume mainly in the case of Dom who applied these to git). I've taken a closer look at the downstream Raspberry Pi kernel trees and I see that the very first bcm2708 commit in the rpi-3.6.y branch contains all the code that's been used by the U-Boot MMC driver port. commit f5b930be71d6de64c3264b2f9eff4a4079d50c14 Author: popcornmix popcorn...@gmail.com AuthorDate: Tue Jan 17 19:20:11 2012 + Commit: popcornmix popcorn...@gmail.com CommitDate: Mon Oct 8 16:25:24 2012 +0100 Main bcm2708 linux port Signed-off-by: popcornmix popcorn...@gmail.com This commit is actually already signed off by popcornmix, and Dom Cobley previously indicated that's him, and gave his permission to rewrite that S-o-b to his real name. Oleksandr, I believe that means that if you can give your S-o-b to the U-Boot patch you created based on Dom's kernel code, we will be good to go with the U-Boot patch I posted, and I can then repost it including fixes for the review feedback it received. I believe this is the only commit I made to SDHCI-related code: commit c78b8ea9ae717432770843b825ea8a1a77f223fc Author: Oleksandr Tymoshenko go...@bluezbox.com Date: Wed Jun 20 11:53:07 2012 -0700 Add driper for R-Pi eMMC controller Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mmc: add bcm2835 driver
On 10/26/2012 10:32 AM, Tom Rini wrote: On Tue, Oct 23, 2012 at 10:50:47PM -0600, Stephen Warren wrote: This adds a simple driver for the BCM2835's SD controller. Workarounds are implemented for: * Register writes can't be too close to each-other in time, or they will be lost. * Register accesses must all be 32-bit, so implement custom accessors. This code was extracted from: git://github.com/gonzoua/u-boot-pi.git master which was created by Oleksandr Tymoshenko. Portions of the code there were obviously based on the Linux kernel at: git://github.com/raspberrypi/linux.git rpi-3.2.27 No s-o-b tags were present in either location. Um, that's a bit worrying to me. Wolfgang? I didn't have much experience with s-o-b stuff, so excuse my ignorance. Is there official procedure, or is it enough to state that I sign off on everything in git://github.com/gonzoua/u-boot-pi.git master authored by me? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
