Re: [OpenWrt-Devel] DSL support and luci integration
On 20 Jan 2012, at 23:47, Philip Prindeville wrote: I'd sure like to see netlink being used to communicate speed/carrier changes up into userspace. Unfortunately there's absolutely no netlink support in the lantiq driver and I don't think any of that info is available elsewhere, I would have thought trying to add a netlink capability would be a bit extreme? (and probably well outside my capability) … and that would then need to be done for every subsequent DSL driver to maintain standardisation. There is an ioctl interface, which also works without the daemon running, which I did consider, but my thought was that this would require an extra binary to maintain (unless there's a simple lua ioctl interface, but I couldn't find one) and would have a lot less transparency than a script -- but I'm happy to knock something up to make use of this if it's considered a better approach. Regards, Lee. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add mostly complete support for Sitecom WL-341 v3 and other Sercomm IP1006RRv2 based boards
On 21 January 2012 00:53, Marco Antonio Mauro marcu...@gmail.com wrote: This patch adds support for the Sitecom WL-341 v3 and other Sercomm IP1006RRv2 based boards for sysupgrade support and for the initial flash through pushbutton initiated recovery mode with the special partition table and fixes for the quirks and things required by the modified bootloader. There are two known bugs: 1. The LED configuration is broken -- only one led is working, an amber led, as I found no way to know which GPIOs were used for those. The board has 6 unlabeled leds, of which 1 is blue only and 5 are amber/blue. If I understand which GPIOs go to which leds I'll submit a patch later. I had this problem too and wrote a script to test gpios for leds and buttons (see attachment). Hope it'll help you (and maybe someone else). Note that it will not help if your leds are connected via shift registers (as on Belkin boards). 2. Wi-Fi is not working on my board probably because of the lack of RAM (the board only has 16MiB ram, but there is an empty slot for another ram chip,) but I don't know for sure. The driver loads but hostapd fails to load so I think it's not related to the specific device except for the lack of RAM. That's very strange, I don't have such problem with my 4/16 MB Sparklan WCR-150GN. I don't quite understand how it could be that it's low RAM problem if all kernel modules are loaded _before_ everything else? Regards, Roman blinker Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DSL support and luci integration
On 21/01/12 09:18, Lee Essen wrote: On 20 Jan 2012, at 23:47, Philip Prindeville wrote: I'd sure like to see netlink being used to communicate speed/carrier changes up into userspace. Unfortunately there's absolutely no netlink support in the lantiq driver and I don't think any of that info is available elsewhere, I would have thought trying to add a netlink capability would be a bit extreme? (and probably well outside my capability) … and that would then need to be done for every subsequent DSL driver to maintain standardisation. There is an ioctl interface, which also works without the daemon running, which I did consider, but my thought was that this would require an extra binary to maintain (unless there's a simple lua ioctl interface, but I couldn't find one) and would have a lot less transparency than a script -- but I'm happy to knock something up to make use of this if it's considered a better approach. as far as i can tell the patch looks fine. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] DWC OTG USB, round 3 (was: hardware driver - gadget driver...)
Hello Paul and Alan,
21.01.2012 1:17, Paul Zimmerman:
On Fri, 20 Jan 2012, Alan Stern wrote:
This is a serious problem. The gadget API does not specify whether
usb_ep_enable and usb_ep_disable should be able to run in interrupt
context. Consequently we end up with UDC drivers like your DWC thing
in which the routines cannot run in interrupt context, together with
gadget drivers like g_serial which do call them in interrupt context.
It may be that the best solution is for the composite.c driver to
implement Set-Config and Set-Interface requests in a workqueue, so that
the calls could be made in process context. For now, you can avoid the
problem by not calling dma_alloc_coherent in your endpoint-setup
routine.
g_file_storage doesn't have this problem because it uses its own kernel
thread for handling these requests.
Actually, dma_alloc_coherent() takes a gfp_t parameter, so you should be
able to set GFP_ATOMIC and do the allocation from interrupt context.
The problem comes from dma_free_coherent(). It unconditionally checks for
being called in process context, and gives a warning if not. This check was
added a year or two ago, for something in the ARM architecture IIRC. I keep
expecting that this will get fixed at some point, but so far it hasn't.
Based on your comments I decided to move some preparations to a
workqueue and there are no issues with those allocations anymore.
I've now finally got g_serial fully recognised on another side (by host
PC) and was even able to open the respective serial device there, but
unfortunately for that to succeed I had to also disable (just throw
away) all requests for EPs != 0 (I did this in ep_queue in dwc driver,
if matters). Without that, controller starts raising IN Token Received
with EP mismatch instead of normal Transfer complete bit. If I
understand it correctly, this means that Tx FIFO happened to be filled
in some particular order that controller disliked (and refused). I've
also found a fragment of code with possibly relevant comment (quoted
below). Indeed, apparently this EP mismatch event is not handled
anywhere in the driver (other than providing a line for dmesg). If it
should, then I'd guess it means the driver is just plain unfininshed and
I have no idea if it can even be fixed with a reasonable effort. Not
sure what was meant exactly by one endpoint at once though.. Of course
usefull gadget drivers would probably employ 1 EPs, even
g_file_storage does so? Strange thing.
Thank you.
Nikolai
/* Reactive the EP */
dwc_otg_ep_activate(GET_CORE_IF(pcd), ep-dwc_ep);
if (ep-stopped) {
ep-stopped = 0;
/* If there is a request in the EP queue start it */
/** @todo FIXME: this causes an EP mismatch in DMA mode.
* epmismatch not yet implemented. */
/*
* Above fixme is solved by implmenting a tasklet to call the
* start_next_request(), outside of interrupt context at some
* time after the current time, after a clear-halt setup packet.
* Still need to implement ep mismatch in the future if a gadget
* ever uses more than one endpoint at once
*/
ep-queue_sof = 1;
tasklet_schedule (pcd-start_xfer_tasklet);
}
/* Start Control Status Phase */
do_setup_in_status_phase(pcd);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Rework ramips_eth to not require irqsave locking anymore
On 17 January 2012 11:42, Helmut Schaa helmut.sc...@googlemail.com wrote:
@@ -313,6 +312,7 @@ ramips_eth_tx_housekeeping(unsigned long ptr)
struct net_device *dev = (struct net_device*)ptr;
struct raeth_priv *priv = netdev_priv(dev);
+ spin_lock(priv-page_lock);
while ((priv-tx[priv-skb_free_idx].txd2 TX_DMA_DONE)
(priv-tx_skb[priv-skb_free_idx])) {
dev_kfree_skb_irq(priv-tx_skb[priv-skb_free_idx]);
@@ -321,6 +321,7 @@ ramips_eth_tx_housekeeping(unsigned long ptr)
if (priv-skb_free_idx = NUM_TX_DESC)
priv-skb_free_idx = 0;
}
+ spin_unlock(priv-page_lock);
ramips_fe_int_enable(RAMIPS_TX_DLY_INT);
}
Seems that spinlock here introduces performance hit in wifi-eth path.
Are you sure it's needed? Seems that it works fine also without this spinlock.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
