Hello
Thank you for tracking this down.
Here are two new patches for the scan stuff, hopefully working now.
Bernhard Loos
2010/5/15 Hauke Mehrtens :
> Am 14.05.2010 00:25, schrieb Bernhard Loos:
>> Hello
>> Do you have any clue, what could produce b43? Because, after looking
>> at t
Am 14.05.2010 00:25, schrieb Bernhard Loos:
> Hello
> Do you have any clue, what could produce b43? Because, after looking
> at the code, I'm kinda at a loss, where this comes from. And do you
> know, which patch exactly produces the problem?
> I will split the patch up, but it may take a day or tw
Hello
Do you have any clue, what could produce b43? Because, after looking
at the code, I'm kinda at a loss, where this comes from. And do you
know, which patch exactly produces the problem?
I will split the patch up, but it may take a day or two, until I have
the time. Some of the other patches ar
Am 13.05.2010 20:54, schrieb Hauke Mehrtens:
> Am 13.05.2010 18:52, schrieb Bernhard Loos:
>> Hello
>> Around line 583 in drivers/sbb/scan.c, there should be an if
>> (bus->chip_rev >=4).
>> Could you remove the if and always execute the code which assigns
>> bus->nr_devices?
>> This shouldn't be a
Am 13.05.2010 18:52, schrieb Bernhard Loos:
> Hello
> Around line 583 in drivers/sbb/scan.c, there should be an if
> (bus->chip_rev >=4).
> Could you remove the if and always execute the code which assigns
> bus->nr_devices?
> This shouldn't be a problem, because the bits for the device number
> sh
Hello
Around line 583 in drivers/sbb/scan.c, there should be an if
(bus->chip_rev >=4).
Could you remove the if and always execute the code which assigns
bus->nr_devices?
This shouldn't be a problem, because the bits for the device number
should be zero on cores which don't support it.
I can also p
Am 13.05.2010 01:08, schrieb Bernhard Loos:
> Sorry, I goofed up while porting the patch to latest trunk, as I did
> develop this on an older svn revision.
> The line should be ssb_chipco_pll_write(cc, 0xa, 0x380005C0);
>
> Bernhard
Hi Bernhard,
Now it compiles for me.
I have just instal
Sorry, I goofed up while porting the patch to latest trunk, as I did
develop this on an older svn revision.
The line should be ssb_chipco_pll_write(cc, 0xa, 0x380005C0);
Bernhard
2010/5/12 Hauke Mehrtens :
> Am 07.05.2010 22:38, schrieb Bernhard Loos:
>> Hello
>> This is another patch for
Am 07.05.2010 22:38, schrieb Bernhard Loos:
> Hello
> This is another patch for the 4716.
> This replaces patch #3, as it had a bunch of problems.
> With this patch the device boots and works reasonable well -
> considering the missing drivers, but I have already an idea for those.
> Serial init co
Hello
This includes 2 patches to add the actual scan method for the ai type
bus and implementations for enalbe/disable device.
The ai scan patch is a bit difficult, because I more or less assumes
that the first core is a chipcommon core, which is at least for the
4710 soc not the case. I'm not comp
Hi Bernhard,
please send these patches to the ssb maintainers and the mailinglist to
get them included into the linux mainline code.
Hauke
Bernhard Loos wrote:
> And I forgot the actual patch again, sorry.
>
> 2010/4/15 Bernhard Loos :
>> Hello
>> This adds two patches to brcm47xx.
>> 950-sbb-s
2010/4/15 Bernhard Loos :
> Hello
> This adds two patches to brcm47xx.
> 950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of
> sysfs attributes to ssb devices, similiar to pci devices.
> 951-brcm4716-defines.patch contains defines for registers and device
> ids used on th brcm4716
>
And I forgot the actual patch again, sorry.
2010/4/15 Bernhard Loos :
> Hello
> This adds two patches to brcm47xx.
> 950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of
> sysfs attributes to ssb devices, similiar to pci devices.
> 951-brcm4716-defines.patch contains defines for regi
Hello
This adds two patches to brcm47xx.
950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of
sysfs attributes to ssb devices, similiar to pci devices.
951-brcm4716-defines.patch contains defines for registers and device
ids used on th brcm4716
Bernhard
_
Hello
I did work on adding support for the BRCM4716 to openwrt after getting
an ASUS RT-N16 from glp.
The main problem is, that the sonics silicon backplane is completly
different especially the registers of the actual backplane.
Also, it uses a different MIPS core and also a different ethernet mac
15 matches
Mail list logo
