this adds support for the ohci controllers seen on the pine64.
it is very quick and very dirty, but it works. i'm able to use a usb1
serial dongle now where it didnt even connect before.
i believe it relies on the ehci companion setting up the phy.
ok?
Index: files.fdt
=
Hello tech@
I would like to add PCI devices for latest Intel SoC (Gemini Lake).
Included a patch for sdhc(4) too that depends on this to enable eMMC.
The Intel eMMC controller does not like bus power going to 0V. There
may be other systems (Apollo Lake) that need this quirk too.
With both patche
> On 2 Jan 2019, at 21:16, Mark Kettenis wrote:
>
>> Date: Wed, 2 Jan 2019 16:08:53 +1000
>> From: David Gwynne
>>
>> This makes it more obvious what interesting things there are to hack on.
>>
>> Thoughts? ok?
>
> I kind of deliberately didn't do this. Some device trees have quite a
> la
On Tue, Jan 01, 2019 at 10:26:47PM +0100, Klemens Nanni wrote:
> There since import and last used by ALTQ which henning removed in 2004.
>
> OK?
>
OK sashan
> Index: sbin/pfctl//pfctl.h
> ===
> RCS file: /cvs/src/sbin/pfctl/pfctl.h
Hello,
On Tue, Jan 01, 2019 at 08:17:43PM +0100, Klemens Nanni wrote:
> Synopsis is `[-t table -T command [address ...]]', yet tables without
> commands are silently ignored:
>
> $ pfctl -t t
> pfctl: /dev/pf: Permission denied
> # pfctl -t t ; echo $?
> 0
>
> Commands w
Hello,
I don't object your change. However I hesitate to give OK too. I hope PF
users, who have non-trivial rulesets will speak up here.
IMO opinion we are hitting limitations of pfctl(8) here. Making warnings
more useful requires to introduce some additional hints to pfctl, to
better express, w
On Wed, 2 Jan 2019 at 08:56, Alexandre Ratchov wrote:
> On Tue, Jan 01, 2019 at 11:02:39PM -, Christian Weisgerber wrote:
> > On 2018-12-31, Alexandre Ratchov wrote:
> >
> > > Our current USB sub-system has limitations that currently allow only
> > > the following combinations:
> > > - USB
Remi Locherer(remi.loche...@relo.ch) on 2019.01.02 20:00:19 +0100:
> Hi tech,
>
> ospfd detects and removes routes in the kernel routing table with priority
> RTP_OSPF (or the configured fib-priority) that have been inserted by another
> program.
>
> Below diff adds the same behaviour to ospf6d.
On Wed, Jan 02, 2019 at 08:00:19PM +0100, Remi Locherer wrote:
> Hi tech,
>
> ospfd detects and removes routes in the kernel routing table with priority
> RTP_OSPF (or the configured fib-priority) that have been inserted by another
> program.
>
> Below diff adds the same behaviour to ospf6d.
>
>
Hi tech,
ospfd detects and removes routes in the kernel routing table with priority
RTP_OSPF (or the configured fib-priority) that have been inserted by another
program.
Below diff adds the same behaviour to ospf6d.
OK?
Remi
Index: kroute.c
I tested the diff with a FiiO E10K Olympus 2.
Previously, it only produced stuttering audio, which I assumed was
because it's a UAC v1.0 device and I connected it on ehci. Now, it
can't be opened at all.
The first thing I noticed was that the kernel now finds two uaudio
devices instead of one (t
zeur here.
mewrote:
> You don't need my permission, but ok zeurkous =)
On 2nd thought, do we really need is_stdin then, though? Isn't a test
like 'tf[i].fp == stdin' enough?
--zeur.
--
Friggin' Machines!
> Date: Wed, 2 Jan 2019 16:08:53 +1000
> From: David Gwynne
>
> This makes it more obvious what interesting things there are to hack on.
>
> Thoughts? ok?
I kind of deliberately didn't do this. Some device trees have quite a
large number of devices and when we started with the device tree
appr
zeur here.
"Martijn van Duren" wrote:
> I'd like to propose a slightly different diff, since POSIX states that a
> filename "-" should mean stdin
Argh, I really hate that convention... but I suppose POSIX is always
right :)
> I would like to prepare the struct
> tailfile to contain the is_stdin
On Tue, Jan 01, 2019 at 10:30:55PM +0100, Remi Locherer wrote:
> Hi tech,
>
> when removing an interface from ospdf.conf and doing a reload other
> OSPF routers should get a router LSA update. Then they can remove the
> affected route. But currently this does not happen. The affected route
> might
On 12/29/18 5:05 PM, leo_...@volny.cz wrote:
> zeur here.
>
> The following {,ab}use of tail(1):
>
> %
> causes an abort trap 'cause of a missing "rpath" pledge. An excellent
> demonstration of pledge(2)'s usefulness, since it exposed a little bug
> that caused tail to try and re-open stdin, wh
16 matches
Mail list logo
