[OpenWrt-Devel] trunk for the sunxi platform has a few inconsistencies

2017-02-27 Thread TheWerthFam 
I'm running the latest LEDE snapshop on the sunxi platform.  The 4.4 
kernel is a nice upgrade.

While using the image I've noticed a few inconsistencies.
The WAN LED is missing on this platform, could be since this uses a USB 
wifi adapter.  I see from the wiki page the WAN leds seem to be created 
by default on other platofms and not an extra package.

ls -l  /sys/class/leds/
lrwxrwxrwx1 root root 0 Jan  1  1970 
lamobo_r1:green:usr -> ../../devices/platform/leds/leds/lamobo_r1:green:usr
lrwxrwxrwx1 root root 0 Feb 28 02:03 
rt2800usb-phy0::assoc -> 
../../devices/platform/soc@01c0/1c14000.usb/usb1/1-1/1-1:1.0/leds/rt2800usb-phy0::assoc
lrwxrwxrwx1 root root 0 Feb 28 02:03 
rt2800usb-phy0::quality -> 
../../devices/platform/soc@01c0/1c14000.usb/usb1/1-1/1-1:1.0/leds/rt2800usb-phy0::quality
lrwxrwxrwx1 root root 0 Feb 28 02:03 
rt2800usb-phy0::radio -> 
../../devices/platform/soc@01c0/1c14000.usb/usb1/1-1/1-1:1.0/leds/rt2800usb-phy0::radio


Secondly I know that procd has had lots more development for this 
release.  I'm finding that the Procd  triggers for config file changes 
don't seem to work consistently.  These triggers worked on CC 15.05.1.  
Are the procd rc.buttons working consistently?

Sample relevant code section.
#!/bin/sh /etc/rc.common
#
START=95
USE_PROCD=1
...
...
My customapp has service_triggers()
Service_triggers()
{
procd_open_trigger
procd_add_reload_trigger "mycustomapp"
procd_close_trigger
}

Changing /etc/config/mycustomapp doesn't trigger a reload or restart of 
the /etc/init.d/mycustomapp

Any advice much appreciated.

Cheers
Derek
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware platform?

2017-02-27 Thread L. D. Pinney 
On Mon, Feb 27, 2017 at 11:32 AM, Dana Myers  wrote:

> On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers  > wrote:
>
> >* On 2/22/2017 6:18 PM, L. D. Pinney wrote:
> *>>>* spi-mt7621.c has bugs ... isn't very helpful.
> *>>>* I am a bit surprised you're not already aware of the SPI issues.
> *>>I am not surprised at all ... ALL of my MT76x8 devices have only a single
> SPI-NOR Chip connected to the SPI.
> On every device it works as intended ... load the OS.
>
>
> Of course - that's surely why this hardware bug in the MediaTek SPI
> peripheral
> escaped from the factory; they implement and document functionality
> (full-duplex
> operation), and either didn't test it or didn't regard the bug as
> critical. The
> critical use-case of the SPI port is to read the flash device, which is
> half-duplex,
> but that's not the only documented use of the SPI port.
>
> MediaTek documents the SPI port as a general peripheral (and provides
> an additional select line), and there's a bug in the hardware.
>
> Whenever you (or anyone) adds functionality to a device you can expect
> problems.
>
> Thanks, though this isn't relevant at all. I'm not *adding* functionality
> to the device.
> There's a bug in the SPI controller that's exposed when you try to use it
> as documented.
>
> In this case some device foreign to the actual device in question.
> More specifically a device such as a RFID module or STM32.
>
> Disagree this IS relevant.
The device in your case is the Onion Omega2.
There is only ONE thing connected to the SPI ... the NOR chip.
Is your second or third SPI peripheral soldered to the board?
Basically OpenWrt is working OK until you add something.
The problem is only present when something ELSE is connected to SPI.

> This isn't the case at all. There's a bug in the MediaTek SPI controller
> completely
> independent of what (if anything) is attached to it. Simply attempting to
> *send*
> a byte in full-duplex mode results in corrupted bits coming out of the
> MediaTek
> SPI Master-Out line. It has absolutely nothing to do with external
> devices. It's a
> bug in the MediaTek controller.
>
> This has been interesting bit of bikeshedding, but back to my original
> question.
>
If you have a working patch...You can start here :
>

> https://lede-project.org/docs/guide-developer/the-source-code
>
>
> I have a working patch. I know how to do a PR. I know how to RTFM :-)
> Which brings us full-circle to my initial query...
>

Why don't you post the [PATCH] here or even better to the LEDE-DEV list
where it is more likely to find 'action'


>
> My concern (as alluded to in the subject line) is that I have a patch that
> I know for certain is required for the MT7688 and I've tested on the
> MT7688.
> I don't have other MT76xx variants to  to verify the presence of  the
> hardware
> bug, so I'm reluctant  to generically apply the patch to spi-mt7621.c - my
> question is how to apply this patch for only the mt7688 target.
>

My question is :

If you have a patch...why don't YOU know where to apply it?
If you expect someone help post the patcheven if YOU don't know what to
do with it.

You will find it difficult to apply your patch specifically to mt7688.
It would more properly apply in target/linux/ramips/patches-4.? and thus be
applied to mt76?? as needed.


>
> However, the more I think about it, I strongly suspect this bug is present
> on all variants of the MT76xx, so the patch should be generically applied;
> I need to find confirmation; I'll try contacting MediaTek.
>

I hope you can speak ZH-TW :)
You seem to be using LEDE.
Which brings up the question of why are you posting to the OpenWrt-dev list?
When you aren't using OpenWrt and seem to know full well from this thread
that the patch should be applied upstream?


> Thanks,
> Dana  K6JQ
>
>
> You can start here:
> >>* https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20 
> >>
> *>>* which links to another forum thread which contains this *very* 
> informative
> *>* posting:
> *>>* http://52.76.69.244/jforum/posts/list/30/3683.page#12266 
> 
> *>>* and suggested patch:
> *>>* http://52.76.69.244/jforum/posts/list/30/3683.page#12299 
> 
> *>>* which is the basis of the patch I'm using.
> *>>* Please describe the problem?
> *>>* berniwa does a much better job than me in the above-linked posting.
> *>>>* Can I reproduce the same problem on one of my many MT76x8 devices?
> *>* If so how?
> *>>>* I've only seen reports of  the issue on MT7688-based devices (LinkIt 
> 7688,
> *>* Omega2)
> *>* and I personally have observed it on the Omega2.
> *>>* The easiest way to reproduce it is to attempt to send an SPI sequence
> *>* starting with the '10' bit sequence (first nibble of 0x8 .. 0xb).

[OpenWrt-Devel] GSoC 2017 - Freifunk accepted!

2017-02-27 Thread Andreas Bräu 
Hi there,

today Google announced the organizations they choosed for GSoC 2017. I’m
happy to tell you: Freifunk is again accepted as mentoring organization
for Google Summer of Code together with 200 other OpenSource
organizations! Our friends from OpenWISP.org got accepted, too! Thanks
to all who helped making this application successful: those who
collected all the ideas (this year we have really a lot of ideas!),
those who talked to possible mentors and those who wrote the application
texts.

>From now on students can find us on the GSoC Website, and we should
start talking to students that want to propose projects to freifunk. If
you know students, point them to our Ideas page
at https://wiki.freifunk.net/Ideas so they can get in touch with our
mentors.

The official Students Application period will start on March, 20. Then
students can start submitting their applications.

As a next step we’ll add the possible mentors to a mailing list.

If you have any questions regarding GSoC, our ideas or as organization,
please don’t hesitate to ask!

Best regards,

Andi

—
Andreas Bräu

XMPP: andibr...@jabber.weimarnetz.de 
Twitter:@evAltenberga 
Blog:https://blog.andi95.de 
PGP:0xB7E04818

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/4 v3] ARM: dts: add PCI to the Gemini device trees

2017-02-27 Thread Linus Walleij 
The Cortina Gemini has an internal PCI root bus, add this to
the device tree, and add interrupt mapping (swizzling) to the
relevant systems device trees.

Cc: Janos Laube 
Cc: Paulius Zaleckas 
Cc: Hans Ulli Kroll 
Cc: Florian Fainelli 
Cc: Feng-Hsin Chiang 
Cc: Greentime Hu 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Change compatible string to "cortina,gemini-pci", "faraday,ftpci100";
- Add "dma-ranges" property, after deciphering that some hardcoded
  constants in the driver is really about this.
ChangeLog v1->v2:
- Change bus-range to <0x00 0xff>
- Drop the three extra IRQs that are unused
- Implement the right interrupt mapping/swizzling
- Push the interrupt mapping down to each affected system, only
  SQ201 for now.

PCI maintainers: this is FYI only, I will funnel this to the ARM
SoC tree once we are done with the PCI driver.
---
 arch/arm/boot/dts/gemini-sq201.dts | 22 
 arch/arm/boot/dts/gemini.dtsi  | 42 ++
 2 files changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/gemini-sq201.dts 
b/arch/arm/boot/dts/gemini-sq201.dts
index dae2a70d8fbc..46309e79cc7b 100644
--- a/arch/arm/boot/dts/gemini-sq201.dts
+++ b/arch/arm/boot/dts/gemini-sq201.dts
@@ -92,5 +92,27 @@
read-only;
};
};
+
+   pci@5000 {
+   status = "okay";
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map =
+   <0x4800 0 0 1 _intc 0>, /* Slot 9 */
+   <0x4800 0 0 2 _intc 1>,
+   <0x4800 0 0 3 _intc 2>,
+   <0x4800 0 0 4 _intc 3>,
+   <0x5000 0 0 1 _intc 1>, /* Slot 10 */
+   <0x5000 0 0 2 _intc 2>,
+   <0x5000 0 0 3 _intc 3>,
+   <0x5000 0 0 4 _intc 0>,
+   <0x5800 0 0 1 _intc 2>, /* Slot 11 */
+   <0x5800 0 0 2 _intc 3>,
+   <0x5800 0 0 3 _intc 0>,
+   <0x5800 0 0 4 _intc 1>,
+   <0x6000 0 0 1 _intc 3>, /* Slot 12 */
+   <0x6000 0 0 2 _intc 0>,
+   <0x6000 0 0 3 _intc 1>,
+   <0x6000 0 0 4 _intc 2>;
+   };
};
 };
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index 3876feefc9d9..918e46546823 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -104,5 +104,47 @@
interrupt-controller;
#interrupt-cells = <2>;
};
+
+   pci@5000 {
+   compatible = "cortina,gemini-pci", "faraday,ftpci100";
+   /*
+* The first 256 bytes in the IO range is actually used
+* to configure the host bridge.
+*/
+   reg = <0x5000 0x100>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   status = "disabled";
+
+   bus-range = <0x00 0xff>;
+   /* PCI ranges mappings */
+   ranges =
+   /* 1MiB I/O space 0x5000-0x500f */
+   <0x0100 0 0  0x5000 0 0x0010>,
+   /* 128MiB non-prefetchable memory 0x5800-0x5fff 
*/
+   <0x0200 0 0x5800 0x5800 0 0x0800>;
+
+   /* DMA ranges */
+   dma-ranges =
+   /* 128MiB at 0x-0x07ff */
+   <0x0200 0 0x 0x 0 0x0800>,
+   /* 64MiB at 0x-0x03ff */
+   <0x0200 0 0x 0x 0 0x0400>,
+   /* 64MiB at 0x-0x03ff */
+   <0x0200 0 0x 0x 0 0x0400>;
+
+   /*
+* This PCI host bridge variant has a cascaded interrupt
+* controller embedded in the host bridge.
+*/
+   pci_intc: interrupt-controller {
+   interrupt-parent = <>;
+   interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-controller;
+   #address-cells = <0>;
+

[OpenWrt-Devel] [PATCH 3/4 v3] ARM: gemini: select MIGHT_HAVE_PCI

2017-02-27 Thread Linus Walleij 
As we have a PCI driver for the Gemini, we should select
MIGHT_HAVE_PCI.

Cc: Janos Laube 
Cc: Paulius Zaleckas 
Cc: Hans Ulli Kroll 
Cc: Florian Fainelli 
Cc: Feng-Hsin Chiang 
Cc: Greentime Hu 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2->v3:
- No changes

PCI maintainers: this is FYI only, I will funnel this to the ARM
SoC tree once we are done with the PCI driver.
---
 arch/arm/mach-gemini/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-gemini/Kconfig b/arch/arm/mach-gemini/Kconfig
index a5ee5fbab796..21f89a4c16fe 100644
--- a/arch/arm/mach-gemini/Kconfig
+++ b/arch/arm/mach-gemini/Kconfig
@@ -6,6 +6,7 @@ menuconfig ARCH_GEMINI
select FTTMR010_TIMER
select GPIO_GEMINI
select GPIOLIB
+   select MIGHT_HAVE_PCI
select POWER_RESET
select POWER_RESET_SYSCON
select SERIAL_OF_PLATFORM
-- 
2.9.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/4 v3] PCI: add driver for Faraday Technology Host Bridge

2017-02-27 Thread Linus Walleij 
This adds a host bridge driver for the Faraday Technology
FPPCI100 host bridge, used for Cortina Systems Gemini SoC
(SL3516) PCI Host Bridge.

This code is inspired by the out-of-tree OpenWRT patch and
then extensively rewritten for device tree and using the modern
helpers to cut down and modernize the code to all new PCI
frameworks. A driver exists in U-Boot as well.

Tested on the ITian Square One SQ201 NAS with the following
result in the boot log (trimmed to relevant parts):

OF: PCI: host bridge /soc/pci@5000 ranges:
OF: PCI:IO 0x5000..0x500f -> 0x
OF: PCI:   MEM 0x5800..0x5fff -> 0x5800
ftpci100 5000.pci: PCI host bridge to bus :00
pci_bus :00: root bus resource [bus 00-ff]
pci_bus :00: root bus resource [io  0x-0xf]
pci_bus :00: root bus resource [mem 0x5800-0x5fff]
ftpci100 5000.pci:
  DMA MEM1 BASE: 0x -> 0x07ff config 0007
ftpci100 5000.pci:
  DMA MEM2 BASE: 0x -> 0x03ff config 0006
ftpci100 5000.pci:
  DMA MEM3 BASE: 0x -> 0x03ff config 0006
PCI: bus0: Fast back to back transfers disabled
pci :00:00.0: of_irq_parse_pci() failed with rc=-22
pci :00:0c.0: BAR 0: assigned [mem 0x5800-0x58007fff]
pci :00:09.2: BAR 0: assigned [mem 0x58008000-0x580080ff]
pci :00:09.0: BAR 4: assigned [io  0x1000-0x101f]
pci :00:09.1: BAR 4: assigned [io  0x1020-0x103f]
pci :00:09.0: enabling device (0140 -> 0141)
pci :00:09.0: HCRESET not completed yet!
pci :00:09.1: enabling device (0140 -> 0141)
pci :00:09.1: HCRESET not completed yet!
pci :00:09.2: enabling device (0140 -> 0142)
rt61pci :00:0c.0: enabling device (0140 -> 0142)
ieee80211 phy0: rt2x00_set_chip: Info - Chipset detected -
   rt: 2561, rf: 0003, rev: 000c
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-pci :00:09.2: EHCI Host Controller
ehci-pci :00:09.2: new USB bus registered, assigned bus number 1
ehci-pci :00:09.2: irq 125, io mem 0x58008000
ehci-pci :00:09.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd :00:09.0: UHCI Host Controller
uhci_hcd :00:09.0: new USB bus registered, assigned bus number 2
uhci_hcd :00:09.0: HCRESET not completed yet!
uhci_hcd :00:09.0: irq 123, io base 0x1000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
uhci_hcd :00:09.1: UHCI Host Controller
uhci_hcd :00:09.1: new USB bus registered, assigned bus number 3
uhci_hcd :00:09.1: HCRESET not completed yet!
uhci_hcd :00:09.1: irq 124, io base 0x1020
hub 3-0:1.0: USB hub found
hub 3-0:1.0: config failed, hub doesn't have any ports! (err -19)
scsi 0:0:0:0: Direct-Access USB  Flash Disk   1.00 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 7900336 512-byte logical blocks: (4.04 GB/3.77 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI removable disk
ieee80211 phy0: rt2x00lib_request_firmware: Info -
   Loading firmware file 'rt2561s.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info -
   Firmware detected - version: 0.8
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

$ lspci
00:00.0 Class 0600: 159b:4321
00:09.2 Class 0c03: 1106:3104
00:09.0 Class 0c03: 1106:3038
00:09.1 Class 0c03: 1106:3038
00:0c.0 Class 0280: 1814:0301

cat /proc/interrupts
   CPU0
123:  0   PCI   0 Edge  uhci_hcd:usb2
124:  0   PCI   1 Edge  uhci_hcd:usb3
125:159   PCI   2 Edge  ehci_hcd:usb1
126:   1082   PCI   3 Edge  rt61pci

cat /proc/iomem
5000-50ff : /soc/pci@5000
5800-5fff : Gemini PCI MEM
  5800-58007fff : :00:0c.0
5800-58007fff : :00:0c.0
  58008000-580080ff : :00:09.2
58008000-580080ff : ehci_hcd

The EHCI USB hub works fine, I can mount and manage
files and the IRQs just keep ticking up. I can issue
iwlist wlan0 scanning and see all the WLANs here, I don't have
wpa_supplicant so have not tried connecting to them.

Cc: Janos Laube 
Cc: Paulius Zaleckas 
Cc: Hans Ulli Kroll 
Cc: Florian Fainelli 
Cc: Feng-Hsin Chiang 
Cc: Greentime Hu 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rewrite to use pci_alloc_host_bridge() and
  pci_register_host_bridge()
- Change compatible strings to "faraday,ftpci100" and
  "faraday,ftpci100-dual"
- Rename driver file to pci-ftpci100.c to reflect the name
  of the actual Faraday IP core.
- Make the driver depend on ARM again as not all archs use

[OpenWrt-Devel] [PATCH 1/4 v3] PCI: add DT bindings for Faraday Technology PCI Host Bridge

2017-02-27 Thread Linus Walleij 
This adds device tree bindings for the Faraday technology PCI
Host Bridge. This IP is found in the Storlink/Storm/Cortina
Gemini SoC platform.

Cc: Janos Laube 
Cc: Paulius Zaleckas 
Cc: Hans Ulli Kroll 
Cc: Florian Fainelli 
Cc: devicet...@vger.kernel.org
Cc: Feng-Hsin Chiang 
Cc: Greentime Hu 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Reinstate the specific-to-generic bindings also specifying the
  "cortina,gemini-pci" fixture for the Faraday block.
- Set compatible to "faraday,ftpci100" and "faraday,ftpci100-dual"
  this is clearly closer to or equal to what the IP blocks from
  Faraday are actually named.
- Add "dma-ranges" property, after deciphering that some hardcoded
  constants in the driver is really about this.
ChangeLog v1->v2:
- Rename from Cortina prefixes to Faraday. This is clearly
  a Faraday IP block.
- Support both the version with cascaded interrupts and the
  "dual" version with 1-to-1 mapped interrupts.
- Change bus-range to <0x00 0xff>
- Fix spelling mistake
- Write a bit about swizzling interrupts on the interrupt
  controller side
- Reasonable swizzling in the interrupt mapping example

This can be merged to the PCI tree whenever it is considered
fine for inclusion.
---
 .../devicetree/bindings/pci/faraday,ftpci100.txt   | 129 +
 1 file changed, 129 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/faraday,ftpci100.txt

diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt 
b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt
new file mode 100644
index ..35d4a979bb7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt
@@ -0,0 +1,129 @@
+Faraday Technology FTPCI100 PCI Host Bridge
+
+This PCI bridge is found inside that Cortina Systems Gemini SoC platform and
+is a generic IP block from Faraday Technology. It exists in two variants:
+plain and dual PCI. The plain version embeds a cascading interrupt controller
+into the host bridge. The dual version routes the interrupts to the host
+chips interrupt controller.
+
+The host controller appear on the PCI bus with vendor ID 0x159b (Faraday
+Technology) and product ID 0x4321.
+
+Mandatory properties:
+
+- compatible: ranging from specific to generic, should be one of
+  "cortina,gemini-pci", "faraday,ftpci100"
+  "cortina,gemini-pci-dual", "faraday,ftpci100-dual"
+  "faraday,ftpci100"
+  "faraday,ftpci100-dual"
+- reg: memory base and size for the host bridge
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells: set to <1>
+- bus-range: set to <0x00 0xff>
+- device_type, set to "pci"
+- ranges: see pci.txt
+- interrupt-map-mask: see pci.txt
+- interrupt-map: see pci.txt
+- dma-ranges: three ranges for the inbound memory region. The ranges must
+  be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, 
64MB,
+  128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked as
+  pre-fetchable.
+
+Mandatory subnodes:
+- For "faraday,ftpci100" a node representing the interrupt-controller inside 
the
+  host bridge is mandatory. It has the following mandatory properties:
+  - interrupt: see interrupt-controller/interrupts.txt
+  - interrupt-parent: see interrupt-controller/interrupts.txt
+  - interrupt-controller: see interrupt-controller/interrupts.txt
+  - #address-cells: set to <0>
+  - #interrupt-cells: set to <1>
+
+I/O space considerations:
+
+The plain variant has 128MiB of non-prefetchable memory space, whereas the
+"dual" variant has 64MiB. Take this into account when describing the ranges.
+
+Interrupt map considerations:
+
+The "dual" variant will get INT A, B, C, D from the system interrupt controller
+and should point to respective interrupt in that controller in its
+interrupt-map.
+
+The code which is the only documentation of how the Faraday PCI (the non-dual
+variant) interrupts assigns the default interrupt mapping/swizzling has
+typically been like this, doing the swizzling on the interrupt controller side
+rather than in the interconnect:
+
+interrupt-map-mask = <0xf800 0 0 7>;
+interrupt-map =
+   <0x4800 0 0 1 _intc 0>, /* Slot 9 */
+   <0x4800 0 0 2 _intc 1>,
+   <0x4800 0 0 3 _intc 2>,
+   <0x4800 0 0 4 _intc 3>,
+   <0x5000 0 0 1 _intc 1>, /* Slot 10 */
+   <0x5000 0 0 2 _intc 2>,
+   <0x5000 0 0 3 _intc 3>,
+   <0x5000 0 0 4 _intc 0>,
+   <0x5800 0 0 1 _intc 2>, /* Slot 11 */
+   <0x5800 0 0 2 _intc 3>,
+   <0x5800 0 0 3 _intc 0>,
+   <0x5800 0 0 4 _intc 1>,
+   <0x6000 0 0 1 _intc 3>, /* Slot 12 */
+   <0x6000 0 0 2 _intc 0>,
+   <0x6000 0 0 3 _intc 1>,
+   <0x6000 0 0 4 _intc 2>;
+
+Example:
+
+pci@5000 {
+   compatible = "cortina,gemini-pci", "faraday,ftpci100";
+   reg = <0x5000 0x100>;
+

Re: [OpenWrt-Devel] Howto/advice: Patch for variant of hardware platform?

2017-02-27 Thread Dana Myers 

On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote:

>/On 2/22/2017 6:18 PM, L. D. Pinney wrote: />//>//>/spi-mt7621.c has bugs ... isn't very 
helpful. />//>//>/I am a bit surprised you're not already aware of the SPI issues. />//>//I 
am not surprised at all ... ALL of my MT76x8 devices have only a single
SPI-NOR Chip connected to the SPI.
On every device it works as intended ... load the OS.


Of course - that's surely why this hardware bug in the MediaTek SPI peripheral
escaped from the factory; they implement and document functionality (full-duplex
operation), and either didn't test it or didn't regard the bug as critical. The
critical use-case of the SPI port is to read the flash device, which is 
half-duplex,
but that's not the only documented use of the SPI port.

MediaTek documents the SPI port as a general peripheral (and provides
an additional select line), and there's a bug in the hardware.

Whenever you (or anyone) adds functionality to a device you can expect
problems.

Thanks, though this isn't relevant at all. I'm not *adding* functionality to 
the device.
There's a bug in the SPI controller that's exposed when you try to use it as 
documented.


In this case some device foreign to the actual device in question.
More specifically a device such as a RFID module or STM32.

This isn't the case at all. There's a bug in the MediaTek SPI controller 
completely
independent of what (if anything) is attached to it. Simply attempting to *send*
a byte in full-duplex mode results in corrupted bits coming out of the MediaTek
SPI Master-Out line. It has absolutely nothing to do with external devices. 
It's a
bug in the MediaTek controller.

This has been interesting bit of bikeshedding, but back to my original question.


If you have a working patch...You can start here :



https://lede-project.org/docs/guide-developer/the-source-code


I have a working patch. I know how to do a PR. I know how to RTFM :-)
Which brings us full-circle to my initial query...

My concern (as alluded to in the subject line) is that I have a patch that
I know for certain is required for the MT7688 and I've tested on the MT7688.
I don't have other MT76xx variants to  to verify the presence of the hardware
bug, so I'm reluctant  to generically apply the patch to spi-mt7621.c - my
question is how to apply this patch for only the mt7688 target.

However, the more I think about it, I strongly suspect this bug is present
on all variants of the MT76xx, so the patch should be generically applied;
I need to find confirmation; I'll try contacting MediaTek.

Thanks,
Dana  K6JQ






You can start here:
>//>/https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20 />//>/which links to another forum thread which contains this *very* informative />/posting: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12266 />//>/and suggested patch: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12299 />//>/which is the basis of the patch I'm using. />//>/Please describe the problem? />//>/berniwa does a much better job than me in the above-linked posting. />//>//>/Can I reproduce the same problem on one of my many MT76x8 devices? />/If so how? />//>//>/I've only seen reports of the issue on MT7688-based devices (LinkIt 7688, />/Omega2) />/and I personally have observed it on the Omega2. />//>/The easiest way to reproduce it is to attempt to send an SPI sequence />/starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll />/find />/the leading '1' bit is sent as a '0'. />//>/I'd be somewhat surprised if the same issue wasn't present on all devices />/which />/incorporate the MT7621 SPI peripheral given the likelihood that MediaTek />/reproduces the same logic on every chip that includes the peripheral. />//>/The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's />/patch addresses by breaking up a transfer as needed (keeping chip select />/asserted). />//>//>/The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel. />/The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different. />//>//>/Understood; I didn't say that MediaTek was using the *same* patch, but that />/this issue is present on all MT7688 devices and that MediaTek has />/incorporated />/a patch for it. The patch I'm using is for 4.4, of course. />//>/If you could confirm the presence of the issue on other MT7621-based SPI />/peripherals, that would address my initial inquiry indirectly if we could />/just />/patch all instances of the MT7621 SPI build :-) />//>/Cheers, />/Dana K6JQ />//>//>//>//>//>//>/On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers > wrote: />//>>/On 2/22/2017 4:27 PM, L. D. Pinney wrote: />>//>>/Are you using https://github.com/OnionIoT/source onion-omega2 branch ? />>//>>//>>/I am not; I'm using https://github.com/lede-project/source (master />>/branch)

[OpenWrt-Devel] [PATCH] procd: service gets deleted when its last instance is freed

2017-02-27 Thread Alin Nastac 
This fixes the following regression introduced in commit
961dc692aff7457f874bce61f8e766514edcf794:
 1) reboot using the following configuration
root@OpenWrt:~# uci show system.ntp
system.ntp=timeserver
system.ntp.enable_server='0'
system.ntp.use_dhcp='1'
system.ntp.dhcp_interface='wan'
root@OpenWrt:~# uci show network.wan
network.wan=interface
network.wan.proto='dhcp'
network.wan.ifname='eth4'
network.wan.reqopts='1 3 6 15 33 42 51 121 249'
 2) if obtained DHCP lease has an option 42 sysntpd service will have an
 instance
 3) run "ifup wan"
 4) although the same DHCP lease was obtained, sysntpd would be stopped

Because sysntpd service is deleted when last instance is freed, its triggers
will also be released. Without these triggers in place, sysntpd will not be
reloaded when a new DHCP lease containing option 42 will be received.

Signed-off-by: Alin Nastac 
---
 service/service.c | 5 -
 service/service.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/service/service.c b/service/service.c
index 0584ee0..9675ba2 100644
--- a/service/service.c
+++ b/service/service.c
@@ -140,6 +140,8 @@ service_update(struct service *s, struct blob_attr **tb, 
bool add)
vlist_flush(>instances);
}
 
+   s->deleted = false;
+
rc(s->name, "running");
 
return 0;
@@ -149,6 +151,7 @@ static void
 service_delete(struct service *s)
 {
vlist_flush_all(>instances);
+   s->deleted = true;
service_stopped(s);
 }
 
@@ -602,7 +605,7 @@ service_start_early(char *name, char *cmdline)
 
 void service_stopped(struct service *s)
 {
-   if (avl_is_empty(>instances.avl)) {
+   if (s->deleted && avl_is_empty(>instances.avl)) {
service_event("service.stop", s->name, NULL);
avl_delete(, >avl);
trigger_del(s);
diff --git a/service/service.h b/service/service.h
index d4f0a83..cc629b1 100644
--- a/service/service.h
+++ b/service/service.h
@@ -40,6 +40,7 @@ struct validate {
 struct service {
struct avl_node avl;
const char *name;
+   bool deleted;
 
struct blob_attr *trigger;
struct vlist_tree instances;
-- 
1.7.12.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel