Re: [OpenWrt-Devel] SVN to GIT transition
On 2015-10-13 10:45, Roman Yeryomin wrote: > On 13 October 2015 at 10:50, Bruno Randolf wrote: >> On 10/12/2015 10:53 PM, Felix Fietkau wrote: git describe r-35387-g83c5a41 If you prefer, cut the last part and get "r-35387". Looks familiar? Now you even have real linear numbering in each branch, without the gaps you get when committing to different branches in SVN + the unique hash. Need to look up the commit? Use the hash (g83c5a41). Of course "r" is just an example to show the familiarity with SVN revisions, you could choose whatever seems fit, for example at this moment it would make sense to tag the moment when 15.05 was branched off from trunk as "dd", then you'd get "dd-number-hash" in trunk and "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to use "git describe --tags" because the tag was not created with -a). >>> >>> That looks quite interesting. The issue I see with that is if somebody >>> adds a local commit on top and builds the tree, the number behind 'r' is >>> misleading and the hash is useless. >> >> Right, I see, the ambiguous numbering with local commits may be a weak >> point. But then, if you don't find the hash in the OpenWRT git, you also >> know that it's not a clean copy of trunk and that's also valuable >> information. People should report bugs from clean trunk, not containing >> random, unknown, additional commits. >> > > and then, again, if a user is able to commit something usually that > means he is able to understand that reporting his local changes > doesn't make sense. People report bugs all the time, and if I'm lucky enough to have a bug report containing revision information, I want to maximize the likelihood of that revision information being useful (even if there are some local commits on top of that). Any assumptions about users thinking carefully if the revision info that they're posting is meaningful enough is flawed. People usually just post whatever is in the banner file. Often bug reports can be anonymous, or reporters just don't respond after posting the ticket. I don't want to compromise any remaining usefulness of such tickets. > Though, I still think that appropriate, meaningful tags will be a > better option to just r (which would be just svn legacy). > Not sure but probably both options could be used in parallel. A fake 'r' value is useless if I can't use it to look up the corresponding OpenWrt commit. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] Send power to USB port on WNR2200
> > This patch fixes ticket #15267 by enabling power on the > > WNR2200's USB port. At present, the USB port on the WNR2200 > > is non-functional due to it not receiving power. > > > > This patch defines an additional GPIO pin, but none of the > > current GPIO definitions have been modified. > > > > Signed-off-by: Riley Baird > bitmessage.ch> > > > > diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c > > b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c > > index bf7f9ee..a1de26a 100644 > > --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c > > +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c > > @@ -36,7 +36,7 @@ > > #define WNR2200_GPIO_LED_LAN4_GREEN16 > > #define WNR2200_GPIO_LED_PWR_AMBER 21 > > #define WNR2200_GPIO_LED_PWR_GREEN 22 > > - > > +#define WNR2200_GPIO_USB_5V4 > > #define WNR2200_GPIO_USB_POWER 24 > > > > #define WNR2200_KEYS_POLL_INTERVAL 20 /* msecs */ > > @@ -127,9 +127,9 @@ static void __init wnr2200_setup(void) > > wnr2200_leds_gpio); > > > > /* enable power for the USB port */ > > - gpio_request_one(WNR2200_GPIO_USB_POWER, > > - GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED, > > - "USB power"); > > was gpio24 just wrong or are there 2 pins for whatever reason ? Looking at Netgear's GPL source code again, it appears that gpio24 was just wrong. I have no idea why the original author put it in there. > > + ap9x_pci_setup_wmac_gpio(0, > > + BIT(WNR2200_GPIO_USB_5V), > > + BIT(WNR2200_GPIO_USB_5V)); > > > > ath79_register_usb(); > > } > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
> > People report bugs all the time, and if I'm lucky enough to have a bug > report containing revision information, I want to maximize the > likelihood of that revision information being useful (even if there are > some local commits on top of that). > Any assumptions about users thinking carefully if the revision info that > they're posting is meaningful enough is flawed. People usually just post > whatever is in the banner file. > Often bug reports can be anonymous, or reporters just don't respond > after posting the ticket. I don't want to compromise any remaining > usefulness of such tickets. > > > Though, I still think that appropriate, meaningful tags will be a > > better option to just r (which would be just svn legacy). > > Not sure but probably both options could be used in parallel. > A fake 'r' value is useless if I can't use it to look up the > corresponding OpenWrt commit. > Supposing we are able to trace the exact base and the modifications, what would be left? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to config GPIO and read the GPIO value in OpenWRT
Hi, I am working on AR9344 Openwrt. I need to configure the GPIO16 and read the status of GPIO. Based on GPIO read value, has to ON/OFF the status LED. Could anyone please explain how i can configure and read GPIO value. Regards, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
On 14 October 2015 at 10:10, Felix Fietkau wrote: > On 2015-10-13 10:45, Roman Yeryomin wrote: >> On 13 October 2015 at 10:50, Bruno Randolf wrote: >>> On 10/12/2015 10:53 PM, Felix Fietkau wrote: > git describe > > r-35387-g83c5a41 > > If you prefer, cut the last part and get "r-35387". > > Looks familiar? Now you even have real linear numbering in each branch, > without the gaps you get when committing to different branches in SVN + > the unique hash. Need to look up the commit? Use the hash (g83c5a41). > > Of course "r" is just an example to show the familiarity with SVN > revisions, you could choose whatever seems fit, for example at this > moment it would make sense to tag the moment when 15.05 was branched off > from trunk as "dd", then you'd get "dd-number-hash" in trunk and > "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to > use "git describe --tags" because the tag was not created with -a). That looks quite interesting. The issue I see with that is if somebody adds a local commit on top and builds the tree, the number behind 'r' is misleading and the hash is useless. >>> >>> Right, I see, the ambiguous numbering with local commits may be a weak >>> point. But then, if you don't find the hash in the OpenWRT git, you also >>> know that it's not a clean copy of trunk and that's also valuable >>> information. People should report bugs from clean trunk, not containing >>> random, unknown, additional commits. >>> >> >> and then, again, if a user is able to commit something usually that >> means he is able to understand that reporting his local changes >> doesn't make sense. > People report bugs all the time, and if I'm lucky enough to have a bug > report containing revision information, I want to maximize the > likelihood of that revision information being useful (even if there are > some local commits on top of that). > Any assumptions about users thinking carefully if the revision info that > they're posting is meaningful enough is flawed. People usually just post > whatever is in the banner file. > Often bug reports can be anonymous, or reporters just don't respond > after posting the ticket. I don't want to compromise any remaining > usefulness of such tickets. git describe origin is solving all your worries Then you can add his local commit hash if there are any and dirty flag to indicate if uncommited changes are present. Much better than svn revision in all ways. >> Though, I still think that appropriate, meaningful tags will be a >> better option to just r (which would be just svn legacy). >> Not sure but probably both options could be used in parallel. > A fake 'r' value is useless if I can't use it to look up the > corresponding OpenWrt commit. see above Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to config GPIO and read the GPIO value in OpenWRT
Am Wed, 14 Oct 2015 18:19:45 +0800 schrieb Afkar Rafique : > Hi, > > I am working on AR9344 Openwrt. I need to configure the GPIO16 and > read the status of GPIO. > > Based on GPIO read value, has to ON/OFF the status LED. > > Could anyone please explain how i can configure and read GPIO value. > > Regards, basicaly i suggest you to google raspberry pi and gpio. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to config GPIO and read the GPIO value in OpenWRT
On Wed, Oct 14, 2015 at 12:19 PM, Afkar Rafique wrote: > Could anyone please explain how i can configure and read GPIO value. There's an article on the wiki which explains how to set a GPIO to a specific value: [0] If you want to read a GPIO value then you use direction "in" and then simply cat to read the "value". The only thing that you might have to do is doing a bit of maths to get the correct GPIO number. When you are trying to read GPIO #16 then it's GPIO #16 of a specific chip -> /sys/class/gpio/ should contain a file gpiochipNNN. What you do is take NNN (let's assume it's 456) and add your GPIO number to it: 456 + 16 = 472 -> this is the number needef to "export" the GPIO. [0] http://wiki.openwrt.org/doc/hardware/port.gpio#software ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Broken SPI transfers on TD-W8970 (latest trunk)
Hi John, I am getting SPI errors on latest trunk. It seems that those might be related to your SPI changes from last week. I found that someone else reported a similar issue a few years ago: [0]. That patch was never applied and I'm not sure if it's 100% correct. These are the errors I get without the rxreq_max correction (hw->rxfs -1) applied - the device is barely usable in this case: [ 106.211973] spi-xway 1e100800.spi: SPI wait ready timed out stat: 44002003 [ 106.217446] m25p80 spi32766.3: wait failed [ 106.419959] spi-xway 1e100800.spi: SPI wait ready timed out stat: 44002003 [ 106.623973] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 [ 106.629442] m25p80 spi32766.3: wait failed [ 106.831959] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 [ 107.035969] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 [ 107.041432] m25p80 spi32766.3: wait failed [ 107.243966] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 [ 107.447973] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 However, with the rxreq_max correction applied it works better, but I get read errors sometimes: [ 18.798861] spi-xway 1e100800.spi: error 441e2203 [ 18.802207] spi_master spi32766: failed to transfer one message from queue [ 18.810784] spi-xway 1e100800.spi: error 44162203 [ 18.814123] spi_master spi32766: failed to transfer one message from queue or: # passwd [ 123.844172] spi-xway 1e100800.spi: error b4092203 [ 123.847459] spi_master spi32766: failed to transfer one message from queue passwd: no record of root in /etc/shadow, using /etc/passwd: I/O error I've attached two patches where the second one should help debugging this (or further) issues, and the other one might actually fix an actual on some devices. Are you able to reproduce these issues on your TD-W89x0 as well? Regards, Martin [0] https://lists.openwrt.org/pipermail/openwrt-devel/2012-April/014794.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] lantiq: Print the status register whenever an error occurs
This should help finding potential problems with the SPI driver. Signed-off-by: Martin Blumenstingl --- .../lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch | 4 +++- .../linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch b/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch index 9cc9349..81e5d39 100644 --- a/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch +++ b/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch @@ -42,7 +42,7 @@ Signed-off-by: John Crispin +obj-$(CONFIG_SPI_XWAY)+= spi-xway.o --- /dev/null +++ b/drivers/spi/spi-xway.c -@@ -0,0 +1,975 @@ +@@ -0,0 +1,977 @@ +/* + * Lantiq SoC SPI controller + * @@ -744,6 +744,8 @@ Signed-off-by: John Crispin + /* Disable all interrupts */ + ltq_spi_reg_clearbit(hw, LTQ_SPI_IRNEN_ALL, LTQ_SPI_IRNEN); + ++ dev_err(hw->dev, "error %x\n", ltq_spi_reg_read(hw, LTQ_SPI_STAT)); ++ + /* Clear all error flags */ + ltq_spi_reg_write(hw, LTQ_SPI_WHBSTATE_CLR_ERRORS, LTQ_SPI_WHBSTATE); + diff --git a/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch b/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch index ffcc95e..5325b83 100644 --- a/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch +++ b/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch @@ -42,7 +42,7 @@ Signed-off-by: John Crispin +obj-$(CONFIG_SPI_XWAY)+= spi-xway.o --- /dev/null +++ b/drivers/spi/spi-xway.c -@@ -0,0 +1,989 @@ +@@ -0,0 +1,991 @@ +/* + * Lantiq SoC SPI controller + * @@ -750,6 +750,8 @@ Signed-off-by: John Crispin + /* Disable all interrupts */ + ltq_spi_reg_clearbit(hw, LTQ_SPI_IRNEN_ALL, LTQ_SPI_IRNEN); + ++ dev_err(hw->dev, "error %x\n", ltq_spi_reg_read(hw, LTQ_SPI_STAT)); ++ + /* Clear all error flags */ + ltq_spi_reg_write(hw, LTQ_SPI_WHBSTATE_CLR_ERRORS, LTQ_SPI_WHBSTATE); + -- 2.6.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] lantiq: Fixed reading the number of RX FIFOs in the SPI driver
Until now the SPI driver used the TX bits for the RX FIFO. This seems uncritical for now since both are equals on my devices (VR9), but this could cause problems on other SoCs. Signed-off-by: Martin Blumenstingl --- .../linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch | 2 +- .../linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch b/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch index ed00b34..9cc9349 100644 --- a/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch +++ b/target/linux/lantiq/patches-3.18/0033-SPI-MIPS-lantiq-adds-spi-xway.patch @@ -913,7 +913,7 @@ Signed-off-by: John Crispin + /* Read module capabilities */ + id = ltq_spi_reg_read(hw, LTQ_SPI_ID); + hw->txfs = (id >> LTQ_SPI_ID_TXFS_SHIFT) & LTQ_SPI_ID_TXFS_MASK; -+ hw->rxfs = (id >> LTQ_SPI_ID_TXFS_SHIFT) & LTQ_SPI_ID_TXFS_MASK; ++ hw->rxfs = (id >> LTQ_SPI_ID_RXFS_SHIFT) & LTQ_SPI_ID_RXFS_MASK; + hw->dma_support = (id & LTQ_SPI_ID_CFG) ? 1 : 0; + + ltq_spi_config_mode_set(hw); diff --git a/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch b/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch index 13a1d9a..ffcc95e 100644 --- a/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch +++ b/target/linux/lantiq/patches-4.1/0033-SPI-MIPS-lantiq-adds-spi-xway.patch @@ -927,7 +927,7 @@ Signed-off-by: John Crispin + /* Read module capabilities */ + id = ltq_spi_reg_read(hw, LTQ_SPI_ID); + hw->txfs = (id >> LTQ_SPI_ID_TXFS_SHIFT) & LTQ_SPI_ID_TXFS_MASK; -+ hw->rxfs = (id >> LTQ_SPI_ID_TXFS_SHIFT) & LTQ_SPI_ID_TXFS_MASK; ++ hw->rxfs = (id >> LTQ_SPI_ID_RXFS_SHIFT) & LTQ_SPI_ID_RXFS_MASK; + hw->dma_support = (id & LTQ_SPI_ID_CFG) ? 1 : 0; + + ltq_spi_config_mode_set(hw); -- 2.6.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Supporting proprietary code
Hi I worked with Qualcomm and Intel on their networking chipsets and they are using openwrt on their systems. But one thing I noticed is unlike Android where they support adding proprietary source code in the build system, openwrt is not so flexible. Is there any plans for openwrt to add a folder inside openwrt build system where companies can add their source code and its automatically included in the build environment? Having that support will make it easy to adopt openwrt on many chipsets. Karthik Bollam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Supporting proprietary code
I think you can just use a custom package feed. That's how I've done it(although I don't use it for proprietary code so much as out of tree packages). On Wed, Oct 14, 2015 at 1:50 PM, Samba Siva Karthik Bollam < sambabol...@hotmail.com> wrote: > Hi > >I worked with Qualcomm and Intel on their networking chipsets and they > are using openwrt on their systems. But one thing I noticed is unlike > Android where they support adding proprietary source code in the build > system, openwrt is not so flexible. > > > > Is there any plans for openwrt to add a folder inside openwrt build system > where companies can add their source code and its automatically included in > the build environment? Having that support will make it easy to adopt > openwrt on many chipsets. > > > > Karthik Bollam > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Supporting proprietary code
Hi James This is what I have done 1: Created a folder [all intel platform specific modules went in to this folder] openwrt/intel 2: Added that in to make menuconfig That gave us the flexibility of showing the proprietary modules inside a separate entry in the menuconfig options. So it was easy to configure and also do source code scans. So I asked if that kind of support built in to openwrt build system would be a nice to have feature. Karthik Bollam From: James Hilliard Sent: Wednesday, October 14, 2015 11:54 AM To: Samba Siva Karthik Bollam Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Supporting proprietary code I think you can just use a custom package feed. That's how I've done it(although I don't use it for proprietary code so much as out of tree packages). On Wed, Oct 14, 2015 at 1:50 PM, Samba Siva Karthik Bollam wrote: Hi I worked with Qualcomm and Intel on their networking chipsets and they are using openwrt on their systems. But one thing I noticed is unlike Android where they support adding proprietary source code in the build system, openwrt is not so flexible. Is there any plans for openwrt to add a folder inside openwrt build system where companies can add their source code and its automatically included in the build environment? Having that support will make it easy to adopt openwrt on many chipsets. Karthik Bollam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Supporting proprietary code
You can define the section and category in a custom package feed makefile like this https://github.com/pinney/Bitmain_Packages/blob/master/cgminer-s3/Makefile#L30 . You can then add the package feed repo to https://github.com/openwrt-mirror/openwrt/blob/master/feeds.conf.default it should get pulled in when you run the packages install and update scripts. On Wed, Oct 14, 2015 at 2:03 PM, Samba Siva Karthik Bollam < sambabol...@hotmail.com> wrote: > Hi James > >This is what I have done > > > > 1: Created a folder [all intel platform specific modules went in to this > folder] > > openwrt/intel > > > > 2: Added that in to make menuconfig > > > > That gave us the flexibility of showing the proprietary modules inside a > separate entry in the menuconfig options. So it was easy to configure and > also do source code scans. So I asked if that kind of support built in to > openwrt build system would be a nice to have feature. > > > > > > Karthik Bollam > > > > > *From: *James Hilliard > *Sent: *Wednesday, October 14, 2015 11:54 AM > *To: *Samba Siva Karthik Bollam > *Cc: *openwrt-devel@lists.openwrt.org > *Subject: *Re: [OpenWrt-Devel] Supporting proprietary code > > > > > > I think you can just use a custom package feed. That's how I've done > it(although I don't use it for proprietary code so much as out of tree > packages). > > > > On Wed, Oct 14, 2015 at 1:50 PM, Samba Siva Karthik Bollam < > sambabol...@hotmail.com> wrote: > > Hi > >I worked with Qualcomm and Intel on their networking chipsets and they > are using openwrt on their systems. But one thing I noticed is unlike > Android where they support adding proprietary source code in the build > system, openwrt is not so flexible. > > > > Is there any plans for openwrt to add a folder inside openwrt build system > where companies can add their source code and its automatically included in > the build environment? Having that support will make it easy to adopt > openwrt on many chipsets. > > > > Karthik Bollam > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] how we hope to fix wifi and the internet
I think many of those here would be delighted to read about our proposal to washington dc, and other regulators of wifi in the world. http://www.businesswire.com/news/home/20151014005564/en/Global-Internet-Experts-Reveal-Plan-Secure-Reliable I note our main servers got completely slammed, you can get the letter from this alternate url, instead. http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf -- Dave Täht Do you want faster, better, wifi? https://www.patreon.com/dtaht ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] generic: add 8139cp fixes, enable hardware csum/tso on 4.0+
On Thu, 2015-10-08 at 10:08 +0200, John Crispin wrote: > > correction, one has a SoB, the other has a description. having both > in both patches would be nice Yeah, sorry about the missing SoB. Although the "missing" description was intentional — it was just the one line in the subject. I have added more words in the resubmission, although it's not clear they really help :) Hopefully better now with the versions I posted yesterday, which I also updated to reflect the fact that we now have a 4.3 kernel. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to config GPIO and read the GPIO value in OpenWRT
Thanks for the reply.
i have Create /etc/init.d/buttons and written below script:
#!/bin/sh /etc/rc.common
START=19
start() {
/bin/umount /etc/config 2>/dev/null
echo out > /sys/class/gpio/gpio16/direction 2> /dev/null
echo 16 > /sys/class/gpio/export 2> /dev/null
if [ "$(cat /sys/class/gpio/gpio16/value)" == "1" ] ; then
echo "255" >
/sys/devices/platform/leds-gpio/leds/db120:green:status/brightness
else
echo "0" >
/sys/devices/platform/leds-gpio/leds/db120:green:status/brightness
fi
}
and restart .
chmod +x /etc/init.d/buttons
/etc/init.d/buttons enable
/etc/init.d/buttons start
Now i am able to read the GPIO 16 value 1/0 based on GPIO state, but as
above script i have written to ON/OFF the Status LED based on GPIO value,
Status LED is not getting OFF even if GPIO16 value is "0".
Can anyone please help on this
On Thu, Oct 15, 2015 at 12:37 AM, Martin Blumenstingl <
martin.blumensti...@googlemail.com> wrote:
> On Wed, Oct 14, 2015 at 12:19 PM, Afkar Rafique
> wrote:
> > Could anyone please explain how i can configure and read GPIO value.
> There's an article on the wiki which explains how to set a GPIO to a
> specific value: [0]
> If you want to read a GPIO value then you use direction "in" and then
> simply cat to read the "value".
>
> The only thing that you might have to do is doing a bit of maths to
> get the correct GPIO number.
> When you are trying to read GPIO #16 then it's GPIO #16 of a specific
> chip -> /sys/class/gpio/ should contain a file gpiochipNNN.
> What you do is take NNN (let's assume it's 456) and add your GPIO
> number to it: 456 + 16 = 472 -> this is the number needef to "export"
> the GPIO.
>
>
> [0] http://wiki.openwrt.org/doc/hardware/port.gpio#software
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Broken SPI transfers on TD-W8970 (latest trunk)
bummer. i had hoped that my patch fixed the issue. did you try the patch graham posted ? John On 14/10/2015 20:38, Martin Blumenstingl wrote: > Hi John, > > I am getting SPI errors on latest trunk. > It seems that those might be related to your SPI changes from last week. > > I found that someone else reported a similar issue a few years ago: [0]. > That patch was never applied and I'm not sure if it's 100% correct. > > These are the errors I get without the rxreq_max correction > (hw->rxfs -1) applied - the device is barely usable in this case: > [ 106.211973] spi-xway 1e100800.spi: SPI wait ready timed out stat: 44002003 > [ 106.217446] m25p80 spi32766.3: wait failed > [ 106.419959] spi-xway 1e100800.spi: SPI wait ready timed out stat: 44002003 > [ 106.623973] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 > [ 106.629442] m25p80 spi32766.3: wait failed > [ 106.831959] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 > [ 107.035969] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 > [ 107.041432] m25p80 spi32766.3: wait failed > [ 107.243966] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 > [ 107.447973] spi-xway 1e100800.spi: SPI wait ready timed out stat: c4002003 > > However, with the rxreq_max correction applied it works better, but I > get read errors sometimes: > [ 18.798861] spi-xway 1e100800.spi: error 441e2203 > [ 18.802207] spi_master spi32766: failed to transfer one message from queue > [ 18.810784] spi-xway 1e100800.spi: error 44162203 > [ 18.814123] spi_master spi32766: failed to transfer one message from queue > or: > # passwd > [ 123.844172] spi-xway 1e100800.spi: error b4092203 > [ 123.847459] spi_master spi32766: failed to transfer one message from queue > passwd: no record of root in /etc/shadow, using /etc/passwd: I/O error > > I've attached two patches where the second one should help debugging > this (or further) issues, and the other one might actually fix an actual > on some devices. > > Are you able to reproduce these issues on your TD-W89x0 as well? > > Regards, > Martin > > > [0] https://lists.openwrt.org/pipermail/openwrt-devel/2012-April/014794.html > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
