On Thu, May 6, 2021 at 7:31 PM Denis Kalashnikov wrote:
> rb91x-ngl (nand-gpio-latch) requests and controls SoC GPIO
> lines that are used for NAND control and data lines multiplexed
> with a latch. Lines of the latch that are not used for NAND
> control lines, are used for power LED and user LED
On Thu, May 6, 2021 at 7:32 PM Denis Kalashnikov wrote:
> + /*
> +* MFD: NAND plus GPIO-controller. They use/share SoC GPIO lines.
> Some of the
> +* GPIO lines are multiplexed by a 8-bit latch (LVC573).
> +* NAND is controlled by GPIO lines (bitbang), also some
On Thu, May 6, 2021 at 7:32 PM Denis Kalashnikov wrote:
[skipped]
> +#define DRIVER_NAME "rb91x-gpio-latch"
Maybe just "rb91x-gpio"? Looks like this board has no more crazy GPIO
controllers.
> +static int get(struct gpio_chip *gc, unsigned offset)
> +{
> + return -ENOSYS;
> +}
On Thu, May 6, 2021 at 7:31 PM Denis Kalashnikov wrote:
> rb91x-ngl (nand-gpio-latch)
I would like to suggest rename it to 'rb91x-latch'. This driver has no
NAND or GPIO functionality. Looks like it just multiplexes access to
subordinate HW, what is clearly indicated by the device tree, where
Hello Denis,
On Thu, May 6, 2021 at 7:31 PM Denis Kalashnikov wrote:
> When porting RB91xG ad hoc drivers (gpio-latch and rb91x-nand) from ar71xx
> to ath79, I made a decision to rework this to more clear design in my opinion:
> MFD driver that requests and controls the gpio lines, and separate
On Thu, May 13, 2021 at 03:49:05PM +0200, Felix Fietkau wrote:
> We're talking about the version of the kernel tree used to create the
> ath10k-ct source, not the kernel version used by OpenWrt.
OK, sorry for the noise.
___
openwrt-devel mailing list
On Thu, May 13, 2021 at 12:14 PM Bjørn Mork wrote:
>
> [ CCing robimarko as the author and maintainer of the tps23861 driver ]
>
> Rafał Miłecki writes:
>
> > From: Rafał Miłecki
> >
> > This is a tiny app that reads list of PoE devices and initializes them
> > using built-in drivers. PoE
Hi Rafał,
Thanks for the proposal
On 2021-05-13 15:58, Rafał Miłecki wrote:
> Current /etc/config/network design and netifd implementation are quite a
> bit messy:
> 1. There is no clear layer 2 vs. layer 3 distinction
I think aside from a few legacy compatibility hacks (e.g. the infamous
Current /etc/config/network design and netifd implementation are quite a
bit messy:
1. There is no clear layer 2 vs. layer 3 distinction
2. UCI sections are inconsistent
3. For some setups there are few ways of defining them
4. A lot of netifd states are implicit (magic behaviour)
5. It's really
On 2021-05-13 11:10, Mirko Parthey wrote:
> On Thu, May 13, 2021 at 05:57:01AM +0200, Felix Fietkau wrote:
>> >> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need
>> >> > to be patched?
>> >> > Is 4.19 the oldest that owrt will consume?
>> >> I think so. 4.19 is used by
[ CCing robimarko as the author and maintainer of the tps23861 driver ]
Rafał Miłecki writes:
> From: Rafał Miłecki
>
> This is a tiny app that reads list of PoE devices and initializes them
> using built-in drivers. PoE status can be read using ubus.
>
> Signed-off-by: Rafał Miłecki
> ---
>
On Thu, May 13, 2021 at 05:57:01AM +0200, Felix Fietkau wrote:
> >> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need
> >> > to be patched?
> >> > Is 4.19 the oldest that owrt will consume?
> >> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update
> >>
There is a PR for the package:
https://github.com/openwrt/packages/pull/15615
On 5/13/21 9:00 AM, e9hack wrote:
Hi,
I've trouble to build libgpg-err since the update from 1.39 to 1.42.
Compilation does fail because the auto generated file gpg-error.h
contains wrong syntax in macro
David Adair via openwrt-devel [2021-05-12
21:18:44]:
Hi,
> Is there any interest in placing this in 21.02 along with the Makefile c
> hange to use it ? The build failure is specific to ccache 4.1 and does NOT
> occur using default config ( ccache and sdk disabled ).
feel free to send such
Hi,
I've trouble to build libgpg-err since the update from 1.39 to 1.42.
Compilation does fail because the auto generated file gpg-error.h contains
wrong syntax in macro GPGRT_LOCK_INITIALIZER:
#define GPGRT_LOCK_INITIALIZER {1,{{\c
0\c
,\0c
0\c
,\0c
The sequence is generated by
15 matches
Mail list logo
