pcidevs updates for the VIA VX900 chipset

2018-07-01 Thread Frederic Cambus
Hi tech@, Add device IDs of the VIA VX900 chipset. Attaching a dmesg from my HP t510 Thin Client. Comments? OK? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1851 diff -u -p -r1.1851

Re: cpu.4: VIA C7 CPUs support Enhanced SpeedStep (i386)

2018-07-01 Thread Frederic Cambus
On Tue, Jun 05, 2018 at 10:04:52PM +1000, Jonathan Gray wrote: > > VIA C7 CPUs support Enhanced SpeedStep, so reflect that in cpu.4. > > > > On the VIA C7 1.5Ghz: > > > > cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz > > cpu0: > >

Re: arm64 acpi(4)

2018-07-01 Thread Mike Larkin
On Sun, Jul 01, 2018 at 06:13:43PM +0200, Mark Kettenis wrote: > Diff below actually enables acpi(4) on arm64. Mostly stubs for bits of code > that isn't needed on hardware-reduced ACPI. But the functions have to be > there for things to compile. > > This is enough to boot my MACCHIATOBin

Re: acpi(4) attach glue for amd64/i386

2018-07-01 Thread Mike Larkin
On Sun, Jul 01, 2018 at 04:59:47PM +0200, Mark Kettenis wrote: > Diff below moves the attach glue from acpi.c into acpi_machdep.c. > Gets rid of an #ifdef and helps me avoid an ugly hack on arm64. There > is some additional code duplication, but I think this is acceptable. > > ok? > ok

Re: pluart@acpi

2018-07-01 Thread Mike Larkin
On Sun, Jul 01, 2018 at 04:38:35PM +0200, Mark Kettenis wrote: > Since the ARM SBSA Generic UART is effectively a PL011 UART, the > expectation is that most arm64 servers will actually have pluart(4) as > their serial console instead of com(4). So we need a glue for > acpi(4). This provides that

Re: ahci@acpi

2018-07-01 Thread Mike Larkin
On Sun, Jul 01, 2018 at 02:15:04PM +0200, Mark Kettenis wrote: > Diff below makes it possible to attach ahci(4) at acpi(4) as required by > arm64 machines like the MACCHIATOBin and Overdrive 1000. > > ok? > ok mlarkin > > Index: dev/acpi/ahci_acpi.c >

Re: signal to process or posix thread

2018-07-01 Thread Joerg Sonnenberger
On Fri, Jun 29, 2018 at 04:21:17PM +0200, Alexander Bluhm wrote: > The problem is that POSIX has signals that are sent to processes > and signals sent to individual threads. Our kernel does not support > this properly. Well, not exactly. POSIX has synchronous and asynchronous signals. I.e.

arm64 acpi(4)

2018-07-01 Thread Mark Kettenis
Diff below actually enables acpi(4) on arm64. Mostly stubs for bits of code that isn't needed on hardware-reduced ACPI. But the functions have to be there for things to compile. This is enough to boot my MACCHIATOBin multi-user. A few more drivers are coming, the crucial bit being pci(4)

Re: acpi(4) attach glue for amd64/i386

2018-07-01 Thread Philip Guenther
On Sun, Jul 1, 2018 at 8:00 AM Mark Kettenis wrote: > Diff below moves the attach glue from acpi.c into acpi_machdep.c. > Gets rid of an #ifdef and helps me avoid an ugly hack on arm64. There > is some additional code duplication, but I think this is acceptable. > > ok? > Fewer ifdefs, yay.

acpi(4) attach glue for amd64/i386

2018-07-01 Thread Mark Kettenis
Diff below moves the attach glue from acpi.c into acpi_machdep.c. Gets rid of an #ifdef and helps me avoid an ugly hack on arm64. There is some additional code duplication, but I think this is acceptable. ok? Index: arch/amd64/amd64/acpi_machdep.c

pluart@acpi

2018-07-01 Thread Mark Kettenis
Since the ARM SBSA Generic UART is effectively a PL011 UART, the expectation is that most arm64 servers will actually have pluart(4) as their serial console instead of com(4). So we need a glue for acpi(4). This provides that glue and moves the shared code from dev/fdt to dev/ic. ok? P.S. This

ahci@acpi

2018-07-01 Thread Mark Kettenis
Diff below makes it possible to attach ahci(4) at acpi(4) as required by arm64 machines like the MACCHIATOBin and Overdrive 1000. ok? Index: dev/acpi/ahci_acpi.c === RCS file: dev/acpi/ahci_acpi.c diff -N dev/acpi/ahci_acpi.c ---

Re: signal to process or posix thread

2018-07-01 Thread Martin Pieuchot
On 29/06/18(Fri) 16:21, Alexander Bluhm wrote: > On Thu, Jun 28, 2018 at 01:54:29PM +0200, Martin Pieuchot wrote: > > > It may happen that the worker thread is in the signal handler and > > > also blocks the signals. > > > > Are you saying that the worker thread modified its mask itself, via > > a

Re: errors in usage.c - libusbhid

2018-07-01 Thread Martin Pieuchot
On 30/06/18(Sat) 23:47, David Bern wrote: > > Note that your diff doesn't apply. You have tab vs spaces issues. > Sorry about that, it seems like I need to setup a proper mail-client. > > > I don't understand what you're talking about. Can you give example of > > the 3 scenarios you're talking