On 21.01.23 15:51, Sergio Paracuellos wrote:
AFAICS, the Ralink driver sets gpio mode for a group of pins using
set_mux operation [1] so when the
gpio_request_enable() operation is called a check for that pin is set
as gpio is performed. Nothing else.
Maybe John Crispin who is the writer of this
On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos
wrote:
>On 1/21/23 15:19, Arınç ÜNAL wrote:
>> On 21.01.2023 21:32, Daniel Santos wrote:
>>> ... You can use this to see what the valid values are for each group,
>>> because until this all goes yaml, there's nothing to tell you if you've
>>>
On 1/21/23 15:19, Arınç ÜNAL wrote:
On 21.01.2023 21:32, Daniel Santos wrote:
... You can use this to see what the valid values are for each group,
because until this all goes yaml, there's nothing to tell you if
you've used an invalid value.
Speaking of which:
https://git.kernel.org/pub/scm
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 2023-01-21 22:42, Lukas Zeller
Hi Tomasz,
thanks a lot for that hint to dtbocfg and the makefile!
> On 21 Jan 2023, at 17:27, Tomasz Maciej Nowak wrote:
>
> [...]
>
> W dniu 21.01.2023 o 16:33, Lukas Zeller pisze:
>>
>> So basically, I'm suggesting to revisit the decision to reject the patch
>> from Daniel Golle [1].
>
>
By the way, I just got an "undelivered mail returned to sender" for
John's mail address. I don't think they'll be replying here any time
soon. ;)
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/l
On 21.01.2023 21:32, Daniel Santos wrote:
Hello all,
I saw this a few days ago, but was too busy to answer then -- sorry
about that. I've dug into this code a bit, but for the mt7620.
On 1/21/23 08:51, Sergio Paracuellos wrote:
Hi,
[+cc John Crispin]
On Sat, Jan 21, 2023 at 2:45 PM Arınç Ü
From: Maciej Krüger
This extends the conn:call function to take a function
as it's last parameter, which will make the library
use ubus_invoke_async.
This allows streaming the logs from ubus,
among other things.
An example has been provided
Signed-off-by: Maciej Krüger
---
lua/stream_logs.lu
This extends the conn:call function to take a function as it's last parameter,
which will make the library use ubus_invoke_async.
This allows streaming the logs from ubus, among other things.
An example has been provided in lua/streaming_logs.lua
___
This extends the conn:call function to take a function as it's last parameter,
which will make the library use ubus_invoke_async.
This allows streaming the logs from ubus, among other things.
An example has been provided in lua/streaming_logs.lua
___
Hello all,
I saw this a few days ago, but was too busy to answer then -- sorry
about that. I've dug into this code a bit, but for the mt7620.
On 1/21/23 08:51, Sergio Paracuellos wrote:
Hi,
[+cc John Crispin]
On Sat, Jan 21, 2023 at 2:45 PM Arınç ÜNAL wrote:
On 21.01.2023 10:56, Sergio Pa
This fixes the following compile problem:
/route.c: In function 'rtnl_flush':
/route.c:45:15: error: ignoring return value of 'write' declared with attribute
'warn_unused_result' [-Werror=unused-result]
45 | (void)write(fd, "-1", 2);
| ^~
cc1: al
Hi.
W dniu 21.01.2023 o 16:33, Lukas Zeller pisze:
> Hi Sergio, thanks for the reply!
>
> On 21 Jan 2023, at 14:00, Sergio Paracuellos
> wrote:
>
>> On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller wrote:
>>> [...]So while I understand that using only the DT mechanisms for
>>> configuring GPIO m
Hi,
> Le 21 janv. 2023 à 02:23, Christian Marangi a écrit :
>
> Yes CI test will catch that and will just fail. Now I think I have to
> ask someone to reboot buildbot again for the new subtarget... Or it will be
> picked automatically?
It needs a restart.
Cheers,
Thibaut
_
Hi Sergio, thanks for the reply!
On 21 Jan 2023, at 14:00, Sergio Paracuellos
wrote:
> On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller wrote:
>> [...]So while I understand that using only the DT mechanisms for configuring
>> GPIO modes, named gpios and libgpiod instead of /sys/class/gpio etc. is
Hi,
[+cc John Crispin]
On Sat, Jan 21, 2023 at 2:45 PM Arınç ÜNAL wrote:
>
> On 21.01.2023 10:56, Sergio Paracuellos wrote:
> > Hi,
> >
> > On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
> >>
> >> Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
> >> GPIO by default. Re
On 21.01.2023 10:56, Sergio Paracuellos wrote:
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
GPIO by default. Requesting a gpio by either from devicetree or `echo
203 > /sys/class/gpio/export` won't change anythin
Hi,
On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller wrote:
>
> Hi,
>
> > On 21 Jan 2023, at 08:56, Sergio Paracuellos
> > wrote:
> >
> > [...] Yes, you have to claim the pin group as gpio on the device tree to
> > make this work.
>
> This revals a underlying problem I tried to ask about back in Ju
Hi,
> On 21 Jan 2023, at 08:56, Sergio Paracuellos
> wrote:
>
> [...] Yes, you have to claim the pin group as gpio on the device tree to
> make this work.
This revals a underlying problem I tried to ask about back in June 2022 [1] -
what is the state of userland GPIO support in OpenWrt?
Chan
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
>
> Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
> GPIO by default. Requesting a gpio by either from devicetree or `echo
> 203 > /sys/class/gpio/export` won't change anything. You have to claim
> the pin group as gpi
20 matches
Mail list logo