Add driver for Individual Computers RapidRoad USB controller.
This is a frontend for isp1763hc MI driver.
The controller can either be connected to clockport or local expansion
port on X-Surf 100. For now only clockport connection is supported.
Fix up clockport attachments.
Move bus tag and attach args from the stack into softc. Properly
disestablish interrupt. Handle exactly one device per clockport.
Add driver for ISP1763A USB 2.0 host controller.
It's a relatively simple PIO-driven host/OTG chip, think more modern
and less broken slhci. Only the host part is supported now. Isochornous
transactions are not supported (this is a driver limitation).
Don't try to get the database version from the host's database when running cross.
On hosts like FreeBSD that do have the database in the same place we keep it,
but don't have our explicit version record, this was causing database version 0
instead of 1 to be emitted, which is wrong.
Pull up following revision(s) (requested by riastradh in ticket #1355):
share/mk/bsd.prog.mk: revision 1.360
share/mk/bsd.lib.mk: revision 1.424
share/mk/bsd.prog.mk: revision 1.361
share/mk/bsd.kmodule.mk: revision 1.87
share/mk/bsd.kmodule.mk: revision 1.88
libexec/ld.elf_so/Makefile: revision 1.152
(all via patch)
bsd.prog.mk: Fix parallel builds of debug data.
Previously, we had one rule to generate foo, and another rule to
derive foo.debug from it with objcopy -- and then rewrite foo _in
place_ to strip the debug data with objcopy.
This is wrong -- one rule should never overwrite another rule's
target; this violates the contract with make(1), and can lead it to
run rules in parallel on files that are changing, which in turn can
[39 lines not shown]
Pull up following revision(s) (requested by tls in ticket #516):
tools/Makefile.gnuhost: revision 1.58
build.sh: revision 1.406
Protect against autoconf/Xcode mishegas on macOS.
This seems to strike periodically, confuse a developer or two for a little
while, and then go away. Why? Because it happens in the interval between
Apple issuing a version of Xcode that supports a newer OS, and newer APIs,
and a given developer's system being upgraded (Apple typically ships Xcode
supporting a new version of macOS a little prior to the OS itself).
The symptom is that autoconf detects symbols that are weakly available with
the new Xcode but which will cause built executables to dump core if called
on the old host OS. This is evidently being addressed in newer versions of
autoconf but who knows when we'll get those across our tree. The fix is to
tell Xcode to use an older SDK if the potential for this condition is detected.
Pull up following revision(s) (requested by tls in ticket #516):
tools/Makefile.gnuhost: revision 1.58
build.sh: revision 1.406
Protect against autoconf/Xcode mishegas on macOS.
This seems to strike periodically, confuse a developer or two for a little
while, and then go away. Why? Because it happens in the interval between
Apple issuing a version of Xcode that supports a newer OS, and newer APIs,
and a given developer's system being upgraded (Apple typically ships Xcode
supporting a new version of macOS a little prior to the OS itself).
The symptom is that autoconf detects symbols that are weakly available with
the new Xcode but which will cause built executables to dump core if called
on the old host OS. This is evidently being addressed in newer versions of
autoconf but who knows when we'll get those across our tree. The fix is to
tell Xcode to use an older SDK if the potential for this condition is detected.
Protect against autoconf/Xcode mishegas on macOS.
This seems to strike periodically, confuse a developer or two for a little
while, and then go away. Why? Because it happens in the interval between
Apple issuing a version of Xcode that supports a newer OS, and newer APIs,
and a given developer's system being upgraded (Apple typically ships Xcode
supporting a new version of macOS a little prior to the OS itself).
The symptom is that autoconf detects symbols that are weakly available with
the new Xcode but which will cause built executables to dump core if called
on the old host OS. This is evidently being addressed in newer versions of
autoconf but who knows when we'll get those across our tree. The fix is to
tell Xcode to use an older SDK if the potential for this condition is detected.
Pull up following revision(s) (requested by riastradh in ticket #515):
external/gpl3/gcc/dist/gcc/config/arm/arm.cc: revision 1.2
external/gpl3/gcc/dist/gcc/config/arm/arm.cc: revision 1.3
(applied to arm.c)
external/gpl3/gcc/dist/gcc/config/arm/arm.md: revision 1.24
external/gpl3/gcc/dist/gcc/config/arm/arm.h: revision 1.27
(all via patch)
gcc/arm: For -mtp=soft, ensure stack alignment even in leaves.
The option -mtp=soft, which is the default on earmv5, makes queries
to the thread pointer, for access to static (`initial-exec')
thread-local storage, go through the C runtime subroutine
__aeabi_read_tp. (For earmv>=6, we use the cp15 register via a
single instruction.)
Thus procedures which gcc thinks of as leaf procedures that use
__aeabi_read_tp are not really leaf procedures -- and even though
[113 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #515):
external/gpl3/gcc/dist/gcc/config/arm/arm.cc: revision 1.2
external/gpl3/gcc/dist/gcc/config/arm/arm.cc: revision 1.3
external/gpl3/gcc/dist/gcc/config/arm/arm.md: revision 1.24
external/gpl3/gcc/dist/gcc/config/arm/arm.h: revision 1.27
gcc/arm: For -mtp=soft, ensure stack alignment even in leaves.
The option -mtp=soft, which is the default on earmv5, makes queries
to the thread pointer, for access to static (`initial-exec')
thread-local storage, go through the C runtime subroutine
__aeabi_read_tp. (For earmv>=6, we use the cp15 register via a
single instruction.)
Thus procedures which gcc thinks of as leaf procedures that use
__aeabi_read_tp are not really leaf procedures -- and even though
__aeabi_read_tp itself doesn't use the stack pointer at all,
resolving the symbol may take a detour through the dynamic linker,
[111 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #514):
share/mk/bsd.prog.mk: revision 1.360
share/mk/bsd.lib.mk: revision 1.424
share/mk/bsd.prog.mk: revision 1.361
tests/libexec/ld.elf_so/Makefile: revision 1.33
tests/lib/csu/Makefile: revision 1.14
share/mk/bsd.kmodule.mk: revision 1.87
share/mk/bsd.kmodule.mk: revision 1.88
libexec/ld.elf_so/Makefile: revision 1.152
bsd.prog.mk: Fix parallel builds of debug data.
Previously, we had one rule to generate foo, and another rule to
derive foo.debug from it with objcopy -- and then rewrite foo _in
place_ to strip the debug data with objcopy.
This is wrong -- one rule should never overwrite another rule's
target; this violates the contract with make(1), and can lead it to
[45 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1353):
tests/lib/librumphijack/t_tcpip.sh: revision 1.23
tests/lib/librumphijack/t_tcpip.sh: revision 1.25
tests/lib/librumphijack/t_tcpip.sh: revision 1.26
tests/lib/librumphijack: Avoid trying to run rpcbind as non-root.
Can probably make this work through rumphijack, but there's no sense
in even trying the test if we can't, so let's reduce the unprivileged
false alarms.
t_tcpip: Mark ssh test xfail.
PR bin/59278: tests/lib/librumphijack/t_tcpip:ssh failing since
openssh 10.0 update
[2 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1352):
tests/lib/libc/sys/t_posix_fadvise.c: revision 1.4
t_posix_fadvise: Don't check whether errno is preserved.
I can find no guarantee in POSIX about posix_fadvise preserving
errno; until such language is found I'm going to assume there is no
such guarantee.
What is happening is that, sometimes, rump_sys_posix_fadvise waits on
a mutex or condvar, which uses _lwp_park internally, which sometimes
wakes up early with EALREADY because a wakeup was already pending for
the thread by the time it entered _lwp_park. And that EALREADY is
delivered by _lwp_park via errno.
PR kern/53931: posix_fadvise_reg test case fails randomly on real
hardware
sys/conf/ssp.mk: Conditionalize use of USE_SSP on HAVE_SSP=yes.
Fixes the following failure after my previous change from
${USE_SSP:Uno} to ${USE_SSP} here so that make(1) would detect
failure to define USE_SSP -- which it did, for alpha, hppa, and ia64:
nbmake: /home/riastradh/netbsd/current/src/sys/conf/ssp.mk:3: Variable "USE_SSP" is undefined
in /home/riastradh/netbsd/current/src/sys/conf/Makefile.kern.inc:397
in /home/riastradh/netbsd/current/obj.hppa/sys/arch/hppa/compile/GENERIC/Makefile:1333
nbmake: Fatal errors encountered -- cannot continue
nbmake: stopped making "depend" in /home/riastradh/netbsd/current/obj.hppa/sys/arch/hppa/compile/GENERIC
PR lib/60858: fortuitous embarrassment: fortify is all kinds of busted
PR bin/60860 : Open output files later
Defer opening the output files until after the input file has
been read.
Also, check that the -o (output) file and the (optional) -m map
file don't name the same file (simple textual check, very easy
to defeat if desired).
And finally, abort early if the input file is empty, to avoid
generating a hash function which ends with (something like):
return (g[h[0]] + g[h[1]]) % 0;
which, if it compiles at all, which I doubt (I didn't bother
testing it) certainly won't do anything useful (maybe dump core).
Note: I doubt the utility of this change, the three files, in
any practical usage, will all be wanted once the has function
[20 lines not shown]
