[LEDE-DEV] [PATCH] kernel: can: Add missing regmap dependency for kernel 4.4

2017-01-14 Thread Florian Fainelli 
Fixes build failure for kmod-can-c-can-platform which depends on
kmod-regmap for kernel 4.1 and 4.4.

Signed-off-by: Florian Fainelli 
---
 package/kernel/linux/modules/can.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/can.mk 
b/package/kernel/linux/modules/can.mk
index eeef88a835ce..5529fe02e0cd 100644
--- a/package/kernel/linux/modules/can.mk
+++ b/package/kernel/linux/modules/can.mk
@@ -241,7 +241,7 @@ $(eval $(call KernelPackage,can-c-can))
 define KernelPackage/can-c-can-platform
   TITLE:=Platform Bus based BOSCH C_CAN/D_CAN driver
   KCONFIG:=CONFIG_CAN_C_CAN_PLATFORM
-  DEPENDS:=kmod-can-c-can +LINUX_4_1:kmod-regmap
+  DEPENDS:=kmod-can-c-can +!LINUX_3_18:kmod-regmap
   FILES:=$(LINUX_DIR)/drivers/net/can/c_can/c_can_platform.ko
   AUTOLOAD:=$(call AutoProbe,c_can_platform)
   $(call AddDepends/can)
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2 ubox 0/6] kmodloader: add module alias support

2017-01-14 Thread Florian Fainelli 
Le 01/13/17 à 09:00, Yousong Zhou a écrit :
> Aliases are essential information for working with kernel modules.  Netfilter
> subsystem will request for ipt_hashlimit and ip6t_hashlimit respectively when
> called with
> 
>   xt_request_find_match(NFPROTO_IPV{4,6}, "hashlimit", 1)
>   
> The kernel __request_module() will then invoke user mode modprobe to load them
> 
>   /sbin/modprobe -q -- ipt_hashlimit
>   /sbin/modprobe -q -- ip6t_hashlimit
> 
> where ipt_hashlimit and ip6t_hashlimit are aliases of xt_hashlimit
> 
> The patch depends on another patch in the build system to restore alias info
> to kernel modules.

FWIW:

Reviewed-by: Florian Fainelli 

> 
> v2 <- v1
> 
>  - Fixed a missing pair of curly parenthesis after avl_for_each_element, and
>this time the code was checked okay with -Wmisleading-indentation
>  - Dropped the now redundant argc < 2 check in load_modprobe()
> 
> Yousong Zhou (6):
>   kmodloader: remove redundant glob wildcard char
>   kmodloader: log to kmsg when loading directories of modules
>   kmodloader: modprobe: skip possible command line arguments
>   kmodloader: fix out-of-bound access when parsing .modinfo
>   kmodloader: add module alias awareness
>   kmodloader: make insert_module() idempotent
> 
>  kmodloader.c | 184 
> +--
>  1 file changed, 153 insertions(+), 31 deletions(-)
> 


-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Adding new people in patchwork?

2017-01-14 Thread Florian Fainelli 
Hi,

How do we get new people added to the delegation list in patchwork?

Thanks!
-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] build: Suffix build directory with _$(LIBC) for external toolchains

2017-01-14 Thread Florian Fainelli 
For external toolchain, we also know the type of C library used, and the
toolchain triplet may not always be reflective of that, therefore make
$(TARGET_DIR_NAME) suffixed with _$(LIBC).

Signed-off-by: Florian Fainelli 
---
 rules.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rules.mk b/rules.mk
index 04fd936660be..b395e9f8fbf9 100644
--- a/rules.mk
+++ b/rules.mk
@@ -124,7 +124,8 @@ else
 GNU_TARGET_NAME=$(shell gcc -dumpmachine)
   endif
   REAL_GNU_TARGET_NAME=$(GNU_TARGET_NAME)
-  TARGET_DIR_NAME:=target-$(GNU_TARGET_NAME)$(if 
$(BUILD_SUFFIX),_$(BUILD_SUFFIX))
+  LIBC:=$(call qstrip,$(CONFIG_LIBC))
+  TARGET_DIR_NAME:=target-$(GNU_TARGET_NAME)_$(LIBC)$(if 
$(BUILD_SUFFIX),_$(BUILD_SUFFIX))
   TOOLCHAIN_DIR_NAME:=toolchain-$(GNU_TARGET_NAME)
 endif
 
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] scripts/getver.sh: append short git hash based on upstream commit

2017-01-14 Thread Magnus Kroken 
The short git hash suffix printed by getver.sh is taken from the
latest local commit, change this to use the hash from latest
upstream commit if available. This is considered the intended
behavior based on commit message a642a11faca87e2a7bddc1fadb54253e2fc26e84,
introducing getver.sh.

Signed-off-by: Magnus Kroken 
---
The referenced commit message says:
The new output format will look like "r2400+2-882472e" for dirty trees or like
"r2402-882472e" for clean ones.

Since the example hashes are the same, I take this to mean that this was the 
intended behavior.

Intended or not, I would suggest this anyway. If someone provides a LEDE 
version number from a dirty tree,
e.g. r2961+8-abcdef01, you need access to a LEDE Git tree and ability to run 
getver.sh to look up which
commit r2961 corresponds to. The short hash (abcdef01) is from the dirty tree, 
and can be anything that person has committed.
Appending the upstream base commit hash is useful when people ask for help and 
you want to track down the 
commit they're based on, and you may not have a running LEDE build environment 
available. Knowing that a tree
is dirty (+8) is useful as well, but the commit hash is only useful to people 
who have access to the dirty tree.

 scripts/getver.sh | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/scripts/getver.sh b/scripts/getver.sh
index ecf048f..4d594d3 100755
--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -40,7 +40,12 @@ try_git() {
REV="${UPSTREAM_REV}+$((REV - UPSTREAM_REV))"
fi
 
-   REV="${REV:+r$REV-$(git log --format="%h" -1)}"
+   if [ -n "$UPSTREAM_BASE" ]; then
+   REV="${REV:+r$REV-$(git log -n 1 --format="%h" 
$UPSTREAM_BASE)}"
+   else
+   REV="${REV:+r$REV-$(git log --format="%h" -1)}"
+   fi
+
;;
esac
 
-- 
2.1.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] x86: Add APU2 LED Driver

2017-01-14 Thread Hans Ulli Kroll via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
HI

On Sat, 14 Jan 2017, Chris Blake wrote:

> In regards to upstream it seems this driver in particular, APU2 LED,
> was submitted upstream at https://patches.linaro.org/patch/80049/
> previously. While this version of the driver varies slightly (better
> platform detection), would you still prefer this to be re-submitted in
> package form? Due to the platform specific code I doubt it would have
> much luck in the upstream lists.
> 

APU1 like mine can use the same driver but with other gpio layout.
A year ago I was in the early stage writing a driver for APU1 until I 
read the datasheet
quote
 Certain GPIOs are multiplexed with pins on the flash controller, PCI 
 controller, GbE MAC, or keyboard and PS/2 controller interfaces
end quote

APU1 uses pinmuxed PS/2 keybord and mouse
APU2 used pinmuxed Hardware monitor pins for FANIN

So I would use this patch which apu1/apu2 board only.

Hans Ulli Kroll

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] x86: Add APU2 LED Driver

2017-01-14 Thread Felix Fietkau 
On 2017-01-14 18:04, Chris Blake wrote:
> On Sat, Jan 14, 2017 at 10:41 AM, Chris Blake  wrote:
>> On Sat, Jan 14, 2017 at 10:31 AM, Felix Fietkau  wrote:
>>> On 2017-01-14 17:20, Chris Blake wrote:
 The following patch adds LED support for the PC Engines APU2/APU3 board
 on LEDE.

 Signed-off-by: Chris Blake 
>>> Has this driver been submitted for upstream inclusion yet?
>>>
>>> - Felix
>>>
>>
>> Felix,
>>
>> This driver has not been submitted upstream to the Linux mailing list
>> at this time.
>>
>> - Chris B
> 
> Felix,
> 
> In regards to upstream it seems this driver in particular, APU2 LED,
> was submitted upstream at https://patches.linaro.org/patch/80049/
> previously. While this version of the driver varies slightly (better
> platform detection), would you still prefer this to be re-submitted in
> package form? Due to the platform specific code I doubt it would have
> much luck in the upstream lists.
Yes, since there doesn't seem to be any progress towards getting this
merged, please re-submit it in package form.

Thanks,

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] x86: Add APU2 LED Driver

2017-01-14 Thread Chris Blake 
On Sat, Jan 14, 2017 at 10:41 AM, Chris Blake  wrote:
> On Sat, Jan 14, 2017 at 10:31 AM, Felix Fietkau  wrote:
>> On 2017-01-14 17:20, Chris Blake wrote:
>>> The following patch adds LED support for the PC Engines APU2/APU3 board
>>> on LEDE.
>>>
>>> Signed-off-by: Chris Blake 
>> Has this driver been submitted for upstream inclusion yet?
>>
>> - Felix
>>
>
> Felix,
>
> This driver has not been submitted upstream to the Linux mailing list
> at this time.
>
> - Chris B

Felix,

In regards to upstream it seems this driver in particular, APU2 LED,
was submitted upstream at https://patches.linaro.org/patch/80049/
previously. While this version of the driver varies slightly (better
platform detection), would you still prefer this to be re-submitted in
package form? Due to the platform specific code I doubt it would have
much luck in the upstream lists.

- Chris B

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 3/4] x86: Add NCT5104D GPIO driver

2017-01-14 Thread Felix Fietkau 
On 2017-01-14 17:40, Chris Blake wrote:
> On Sat, Jan 14, 2017 at 10:30 AM, Felix Fietkau  wrote:
>> On 2017-01-14 17:20, Chris Blake wrote:
>>> The following patch is to add driver support for the NCT5104D GPIO Super
>>> I/O chip which is found on the PC Engines APU2/APU3 boards.
>>>
>>> Signed-off-by: Chris Blake 
>> Has this driver been submitted for upstream inclusion yet?
>>
>> - Felix
>>
> 
> Felix,
> 
> This driver has not been submitted upstream to the Linux mailing list
> at this time.
Since we're working hard on cleaning up our non-upstream patch mess, I'd
like to ask you to either work on getting this code upstream, or make it
a self-contained package without kernel patches.

Same applies to the other patch.

Thanks,

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] x86: Add APU2 LED Driver

2017-01-14 Thread Chris Blake 
On Sat, Jan 14, 2017 at 10:31 AM, Felix Fietkau  wrote:
> On 2017-01-14 17:20, Chris Blake wrote:
>> The following patch adds LED support for the PC Engines APU2/APU3 board
>> on LEDE.
>>
>> Signed-off-by: Chris Blake 
> Has this driver been submitted for upstream inclusion yet?
>
> - Felix
>

Felix,

This driver has not been submitted upstream to the Linux mailing list
at this time.

- Chris B

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 3/4] x86: Add NCT5104D GPIO driver

2017-01-14 Thread Felix Fietkau 
On 2017-01-14 17:20, Chris Blake wrote:
> The following patch is to add driver support for the NCT5104D GPIO Super
> I/O chip which is found on the PC Engines APU2/APU3 boards.
> 
> Signed-off-by: Chris Blake 
Has this driver been submitted for upstream inclusion yet?

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 1/4] x86: Add sp5100_tco AMD patches

2017-01-14 Thread Chris Blake 
This adds the following patches to the x86 target:

sp5100_tco: Add AMD Mullins platform support
sp5100_tco: Add AMD Carrizo platform support
sp5100_tco: fix the device check for SB800 and later chipsets
watchdog: sp5100_tco: properly check for new register layouts

With these added, the sp5100_tco driver can then be used on newer AMD
platforms, such as the PCEngines APU2/APU3 boards.

Signed-off-by: Chris Blake 
---
 ...5100_tco-Add-AMD-Mullins-platform-support.patch | 30 
 ...5100_tco-Add-AMD-Carrizo-platform-support.patch | 31 +
 ...device-check-for-SB800-and-later-chipsets.patch | 80 ++
 ...5100_tco-properly-check-for-new-register-.patch | 76 
 4 files changed, 217 insertions(+)
 create mode 100644 
target/linux/x86/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
 create mode 100644 
target/linux/x86/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
 create mode 100644 
target/linux/x86/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
 create mode 100644 
target/linux/x86/patches-4.4/097-0004-watchdog-sp5100_tco-properly-check-for-new-register-.patch

diff --git 
a/target/linux/x86/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
 
b/target/linux/x86/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
new file mode 100644
index 000..ee88859
--- /dev/null
+++ 
b/target/linux/x86/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
@@ -0,0 +1,30 @@
+From 190aa4304de6fe2185d96392ddf56580fa133e99 Mon Sep 17 00:00:00 2001
+From: Denis Turischev 
+Date: Tue, 24 Nov 2015 10:46:12 +0200
+Subject: [PATCH] sp5100_tco: Add AMD Mullins platform support
+
+AMD Mullins watchdog is fully compatible to the previous Hudson chipset,
+reuse the existent sp5100_tco driver.
+
+Signed-off-by: Denis Turischev 
+Signed-off-by: Guenter Roeck 
+Signed-off-by: Wim Van Sebroeck 
+---
+ drivers/watchdog/sp5100_tco.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
+index eb8044e..ef039f8 100644
+--- a/drivers/watchdog/sp5100_tco.c
 b/drivers/watchdog/sp5100_tco.c
+@@ -306,6 +306,8 @@ static struct miscdevice sp5100_tco_miscdev = {
+ static const struct pci_device_id sp5100_tco_pci_tbl[] = {
+   { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, },
++  { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
++PCI_ANY_ID, },
+   { 0, }, /* End of list */
+ };
+ MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
+--
+2.7.4
diff --git 
a/target/linux/x86/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
 
b/target/linux/x86/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
new file mode 100644
index 000..664d4bb
--- /dev/null
+++ 
b/target/linux/x86/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
@@ -0,0 +1,31 @@
+From cca118fa2a0a94e0f0b3c8dd1dda922cdee45089 Mon Sep 17 00:00:00 2001
+From: Huang Rui 
+Date: Mon, 23 Nov 2015 18:07:36 +0800
+Subject: [PATCH] sp5100_tco: Add AMD Carrizo platform support
+
+sp5100_tco watchdog is also supported on AMD KernCZ chipset of Carrizo
+platform.
+
+Signed-off-by: Huang Rui 
+Cc: Denis Turischev 
+Signed-off-by: Guenter Roeck 
+Signed-off-by: Wim Van Sebroeck 
+---
+ drivers/watchdog/sp5100_tco.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
+index ef039f8..0ccadb4 100644
+--- a/drivers/watchdog/sp5100_tco.c
 b/drivers/watchdog/sp5100_tco.c
+@@ -308,6 +308,8 @@ static const struct pci_device_id sp5100_tco_pci_tbl[] = {
+ PCI_ANY_ID, },
+   { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, },
++  { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, PCI_ANY_ID,
++PCI_ANY_ID, },
+   { 0, }, /* End of list */
+ };
+ MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
+--
+2.7.4
diff --git 
a/target/linux/x86/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
 
b/target/linux/x86/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
new file mode 100644
index 000..e9f4513
--- /dev/null
+++ 
b/target/linux/x86/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
@@ -0,0 +1,80 @@
+From bdecfcdb5461834aab24002bb18d3cbdd907b7fb Mon Sep 17 00:00:00 2001
+From: Huang Rui 
+Date: Mon, 23 Nov 2015 18:07:35 +0800
+Subject: [PATCH] sp5100_tco: fix the device check for SB800 and later chipsets
+

[LEDE-DEV] [PATCH 2/4] x86: add kernel module for sp5100_tco watchdog

2017-01-14 Thread Chris Blake 
This change adds the sp5100_tco driver as a kernel module for the x86
target. Specifically, this can be used by the PCEngines APU2/APU3. The
reason for having this as a kernel module is to allow users to
load/unload it on demand, as the I2C interface on the APU2/APU3 will not
work while this module is loaded. More info can be found on GitHub at
https://github.com/riptidewave93/LEDE-APU2/pull/5#issuecomment-255667736

Signed-off-by: Chris Blake 
---
 target/linux/x86/modules.mk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk
index 656500b..87733c2 100644
--- a/target/linux/x86/modules.mk
+++ b/target/linux/x86/modules.mk
@@ -19,3 +19,18 @@ define KernelPackage/sound-cs5535audio/description
 endef

 $(eval $(call KernelPackage,sound-cs5535audio))
+
+define KernelPackage/sp5100_tco
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=SP5100 Watchdog Support
+  DEPENDS:=@TARGET_x86
+  KCONFIG:=CONFIG_SP5100_TCO
+  FILES:=$(LINUX_DIR)/drivers/watchdog/sp5100_tco.ko
+  AUTOLOAD:=$(call AutoLoad,50,sp5100_tco,1)
+endef
+
+define KernelPackage/sp5100_tco/description
+ Kernel module for the SP5100_TCO hardware watchdog.
+endef
+
+$(eval $(call KernelPackage,sp5100_tco))
--
2.7.4

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 3/4] x86: Add NCT5104D GPIO driver

2017-01-14 Thread Chris Blake 
The following patch is to add driver support for the NCT5104D GPIO Super
I/O chip which is found on the PC Engines APU2/APU3 boards.

Signed-off-by: Chris Blake 
---
 target/linux/x86/64/config-default |   9 +
 .../linux/x86/files/drivers/gpio/gpio-nct5104d.c   | 461 +
 .../patches-4.4/801-add-nct5104d-gpio-driver.patch |  28 ++
 3 files changed, 498 insertions(+)
 create mode 100644 target/linux/x86/files/drivers/gpio/gpio-nct5104d.c
 create mode 100644 
target/linux/x86/patches-4.4/801-add-nct5104d-gpio-driver.patch

diff --git a/target/linux/x86/64/config-default 
b/target/linux/x86/64/config-default
index 791c1f2..d2e2774 100644
--- a/target/linux/x86/64/config-default
+++ b/target/linux/x86/64/config-default
@@ -109,6 +109,15 @@ CONFIG_GART_IOMMU=y
 CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
 CONFIG_GENERIC_CPU=y
 CONFIG_GENERIC_PENDING_IRQ=y
+CONFIG_GPIOLIB=y
+# CONFIG_GPIO_104_IDIO_16 is not set
+# CONFIG_GPIO_AMDPT is not set
+# CONFIG_GPIO_F7188X is not set
+# CONFIG_GPIO_INTEL_MID is not set
+# CONFIG_GPIO_IT87 is not set
+# CONFIG_GPIO_LYNXPOINT is not set
+CONFIG_GPIO_NCT5104D=y
+CONFIG_GPIO_SYSFS=y
 CONFIG_HAVE_ACPI_APEI=y
 CONFIG_HAVE_ACPI_APEI_NMI=y
 # CONFIG_HAVE_AOUT is not set
diff --git a/target/linux/x86/files/drivers/gpio/gpio-nct5104d.c 
b/target/linux/x86/files/drivers/gpio/gpio-nct5104d.c
new file mode 100644
index 000..a37a1d0
--- /dev/null
+++ b/target/linux/x86/files/drivers/gpio/gpio-nct5104d.c
@@ -0,0 +1,461 @@
+/*
+ * GPIO driver for NCT5104D
+ *
+ * Author: Tasanakorn Phaipool 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRVNAME "gpio-nct5104d"
+
+/*
+ * Super-I/O registers
+ */
+#define SIO_LDSEL  0x07/* Logical device select */
+#define SIO_CHIPID 0x20/* Chaip ID (2 bytes) */
+#define SIO_GPIO_ENABLE0x30/* GPIO enable */
+#define SIO_GPIO1_MODE 0xE0/* GPIO1 Mode OpenDrain/Push-Pull */
+#define SIO_GPIO2_MODE 0xE1/* GPIO2 Mode OpenDrain/Push-Pull */
+
+#define SIO_LD_GPIO0x07/* GPIO logical device */
+#define SIO_LD_GPIO_MODE   0x0F/* GPIO mode control device */
+#define SIO_UNLOCK_KEY 0x87/* Key to enable Super-I/O */
+#define SIO_LOCK_KEY   0xAA/* Key to disable Super-I/O */
+
+#define SIO_NCT5104D_ID0x1061  /* Chip 
ID */
+#define SIO_PCENGINES_APU_NCT5104D_ID  0xc452  /* Chip ID */
+
+enum chips { nct5104d };
+
+static const char * const nct5104d_names[] = {
+   "nct5104d"
+};
+
+struct nct5104d_sio {
+   int addr;
+   enum chips type;
+};
+
+struct nct5104d_gpio_bank {
+   struct gpio_chip chip;
+   unsigned int regbase;
+   struct nct5104d_gpio_data *data;
+};
+
+struct nct5104d_gpio_data {
+   struct nct5104d_sio *sio;
+   int nr_bank;
+   struct nct5104d_gpio_bank *bank;
+};
+
+/*
+ * Super-I/O functions.
+ */
+
+static inline int superio_inb(int base, int reg)
+{
+   outb(reg, base);
+   return inb(base + 1);
+}
+
+static int superio_inw(int base, int reg)
+{
+   int val;
+
+   outb(reg++, base);
+   val = inb(base + 1) << 8;
+   outb(reg, base);
+   val |= inb(base + 1);
+
+   return val;
+}
+
+static inline void superio_outb(int base, int reg, int val)
+{
+   outb(reg, base);
+   outb(val, base + 1);
+}
+
+static inline int superio_enter(int base)
+{
+   /* Don't step on other drivers' I/O space by accident. */
+   if (!request_muxed_region(base, 2, DRVNAME)) {
+   pr_err(DRVNAME "I/O address 0x%04x already in use\n", base);
+   return -EBUSY;
+   }
+
+   /* According to the datasheet the key must be send twice. */
+   outb(SIO_UNLOCK_KEY, base);
+   outb(SIO_UNLOCK_KEY, base);
+
+   return 0;
+}
+
+static inline void superio_select(int base, int ld)
+{
+   outb(SIO_LDSEL, base);
+   outb(ld, base + 1);
+}
+
+static inline void superio_exit(int base)
+{
+   outb(SIO_LOCK_KEY, base);
+   release_region(base, 2);
+}
+
+/*
+ * GPIO chip.
+ */
+
+static int nct5104d_gpio_direction_in(struct gpio_chip *chip, unsigned offset);
+static int nct5104d_gpio_get(struct gpio_chip *chip, unsigned offset);
+static int nct5104d_gpio_direction_out(struct gpio_chip *chip,
+unsigned offset, int value);
+static void nct5104d_gpio_set(struct gpio_chip *chip, unsigned offset, int 
value);
+
+#define NCT5104D_GPIO_BANK(_base, _ngpio, _regbase)\
+   {   \
+   .chip

Re: [LEDE-DEV] [OpenWrt-Devel] upstreaming (most) rt2x00 patches

2017-01-14 Thread Martin Blumenstingl via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sat, Jan 14, 2017 at 3:44 AM, Daniel Golle  wrote:
> Hi Martin,
>
> On Sat, Jan 14, 2017 at 01:28:06AM +0100, Martin Blumenstingl wrote:
>> On Thu, Jan 12, 2017 at 3:35 PM, Daniel Golle  wrote:
>> > Hi!
>> >
>> > The amount of patches on top of rt2x00 has grown into a huge pile
>> > during the past couple of years. To get things into a shape that allow
>> > discussing and merging them upstream, I created a tree on github based
>> > on wireless-drivers-next.git:
>> >
>> > https://github.com/dangowrt/linux/commits/rt2x00-from-openwrt
>> >
>> > I had to fix up some of Gabor's patches to still apply on the updated
>> > code base, but apart from those small fixes, things still apply cleanly
>> > on that tree.
>> > Imho the patch adding support for MT7620 still needs some more cleaning
>> > (I fixed some white-space and indention issues already), and both
>> > MT7620 and RT5350 still use mdelay and udelay which should be replaced
>> > in the same way done for other codepaths upstream. It'd also be great
>> > not to mess up RF and RT, ie. correctly set the RF value
>> > for RT5350 and MT7620 according to the actual RF IP used on those
>> > chips. Just for clarification, RT6352 was later renamed to MT7620
>> >
>> > I for now didn't add any of the EEPROM-related patches, I a suppose
>> > that only read_eeprom_from_mtd() should go upstream and all file and
>> > firmware-loading mechanics can be considered legacy.
>> are you sure about removing the firmware-loading mechanism? I recently
>> *added* this to ath9k upstream due to the following problems we had
>> with "ath9k calibration data":
>> 1. calibration data is stored inside a UBI volume on some ar71xx and
>> lantiq devices
>> 2. calibration data is stored on an unaligned offset inside the NOR
>> flash of some lantiq (Fritz Box) devices
>> 3. some calibration data is simply broken (vendors did a swab16(),
>> messing up the position of some fields so we need another swab16() to
>> get valid calibration data)
>
> I'm fully aware of that and fully agree with you.
> However, the current state of rt2x00 eeprom loading hacks wasn't in
> shape for being sent upstream imho, ie. obvious things like missing
> additions to Documentation/devicetree/bindings/ and remaining
> platform_data legacy make it unlikely to have those patches merged
> at this stage.
> Apart from that, Mathias Kresin has recently been improving EEPROM
> loading on rt2x00 and once all the rest is in shape upstream he should
> just submit that on top once completed and cleaned up (ie. patches
> adding EEPROM file reading in various ways if requested via device-tree
> should be folded up, legacy platform_data stuff should be omitted).
then I just misunderstood you, problem solved!

>> there's also a similar discussion going on for wl1251 because there
>> seem to be devices where the calibration data is obfuscated, etc.
>> see [0] for more information on the wl1251 topic
>
> Interesting. Does that mean that the N900 hardware is now fully
> supported by kernel.org/torvalds/linux.git ?
seems so, but I don't have a N900 and I've only been following the
discussion loosely

>> apart from that: thank you for taking the time to upstream this
>> (building a pile of patches which *could* be upstreamed and
>> maintaining them for a very long time doesn't make us better than all
>> the vendors with their custom stacks, so big thanks :))!
>
> I recently started seeing new hope in rt2x00 as things were already
> working quite nicely with our current patchset (apart from MT7620
> which imho still needs quite some more work. If noone else comes first
> I might do that at some point).
>
> Now the driver has also received a lot of improvements related to
> aggregation upstream, so it might finally get somewhere near to the
> performance seen with ath9k. Adding proper upstream support for the
> WiSoC chips seems crucial, given the popularity of chips like the
> Rt5350, also to open the doors to other vanilla Linux based
> distributions on those platforms.
I actually used a device with RT3062F a bit more than a year ago,
because the main device I tried to use had crashing ath10k firmware
(due to some platforms not liking DMA bursts: [0]) and really poor
ath9k performance (due to [1]).
the device with RT3062F "just worked".

(so much for the off-topic stuff...)


[0] https://patchwork.kernel.org/patch/7173811/
[1] https://www.spinics.net/lists/linux-wireless/msg138953.html

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

2017-01-14 Thread Toke Høiland-Jørgensen 
"L. D. Pinney"  writes:

> Go back to playing the guitar and smoking dopethat's what you do best.
>
> STOP CROSS POSTING YOU FSCKin' Clown Boy

Dude, seriously? Lay off the abuse. Even if your argument had any merit,
this kind of language is uncalled for...

-Toke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev