> On Sep 12, 2021, at 6:16 PM, David Holland wrote:
>
> On Sat, Sep 11, 2021 at 03:43:24PM -0700, Jason Thorpe wrote:
>> The basic idea involves the device call mechanism I introduced a while ago.
>
> You still haven't explained why that needs to be untyped and based on
> uncheckable string
On Sat, Sep 11, 2021 at 03:43:24PM -0700, Jason Thorpe wrote:
> The basic idea involves the device call mechanism I introduced a while ago.
You still haven't explained why that needs to be untyped and based on
uncheckable string constants.
--
David A. Holland
dholl...@netbsd.org
> On Sep 12, 2021, at 2:49 PM, Tobias Nygren wrote:
>
> On Sun, 12 Sep 2021 12:30:14 -0700
> Jason Thorpe wrote:
>
>> Ok, sparc64 should be good do go now. I made a bunch of fake fixup entries
>> for the Qemu machine and, after a couple of additional fixes, verified that
>> the machinery
> On Sep 12, 2021, at 10:26 AM, Jason Thorpe wrote:
>
>
>
>> On Sep 12, 2021, at 7:37 AM, Tobias Nygren wrote:
>>
>> iic3 at rkiic3: I2C bus
>> typec-portc (fcs,fusb302) at iic3 addr 0x22 not configured
>> panic: kernel diagnostic assertion "rv" failed: file
>>
On Sun, 12 Sep 2021 12:30:14 -0700
Jason Thorpe wrote:
> Ok, sparc64 should be good do go now. I made a bunch of fake fixup entries
> for the Qemu machine and, after a couple of additional fixes, verified that
> the machinery is working as expected.
Gets further but hits another problem.
bus
> On Sep 12, 2021, at 11:32 AM, Jason Thorpe wrote:
>
>
>> On Sep 12, 2021, at 10:27 AM, Jason Thorpe wrote:
>>
>> Huh. Ok, this didn’t happen in qemu, but I’ll take a look today.
>
> Oh, yes it does. This is almost certainly due to a small tweak I made
> locally after I tested it the
> On Sep 12, 2021, at 10:27 AM, Jason Thorpe wrote:
>
> Huh. Ok, this didn’t happen in qemu, but I’ll take a look today.
Oh, yes it does. This is almost certainly due to a small tweak I made locally
after I tested it the first time. I am a dum-dum. Fixing now.
-- thorpej
> On Sep 12, 2021, at 5:31 AM, Tobias Nygren wrote:
>
> sparc64 kernel built from thorpej-i2c-spi-conf2 crashed early:
>
> r...@netra240.rymdfartsverket.se:/usr/obj/sys/arch/sparc64/compile/GENERIC.netra240-debug
> total memory = 7168 MB
> avail memory = 7023 MB
> mainbus0 (root)cpu0: data
> On Sep 12, 2021, at 7:37 AM, Tobias Nygren wrote:
>
> iic3 at rkiic3: I2C bus
> typec-portc (fcs,fusb302) at iic3 addr 0x22 not configured
> panic: kernel diagnostic assertion "rv" failed: file
> "/usr/src/sys/dev/i2c/i2c.c", line 630
> cpu0: Begin traceback...
> trace fp c0f784e0
> Date: Sun, 12 Sep 2021 08:57:07 -0700
> From: Jason Thorpe
>
> > On Sep 12, 2021, at 8:17 AM, Jason Thorpe wrote:
> >
> > Doing this with symbols is a mess.
>
> Here's a way to basically get most of what you want without
> referencing symbols:
Now the linker doesn't detect namespace
> On Sep 12, 2021, at 8:17 AM, Jason Thorpe wrote:
>
> Doing this with symbols is a mess.
Here’s a way to basically get most of what you want without referencing symbols:
struct device_call_generic {
const char *name;
void *args;
};
int device_call_generic(device_t,
> Date: Sun, 12 Sep 2021 08:17:15 -0700
> From: Jason Thorpe
>
> > On Sep 12, 2021, at 1:58 AM, Taylor R Campbell
> > wrote:
> >
> > Why is this a requirement/problem?
> >
> > The current mechanism still needs space in the kernel for the text of
> > the name (the string
> On Sep 12, 2021, at 1:58 AM, Taylor R Campbell
> wrote:
>
> Why is this a requirement/problem?
>
> The current mechanism still needs space in the kernel for the text of
> the name (the string "i2c-enumerate-devices"). Why refuse to expose
> that name to the linker so it can detect typos
Hi,
On 2021/09/12 7:43, Jason Thorpe wrote:
-- sandpoint (any will do; I bought a Synology, but the Ethernet interface
failed after a couple of days, even PPCBOOT complains, boo). rin@?
Thank you for working on this!
DIAGNOSTIC kernel built from thorpej-i2c-spi-conf2 branch successfully
On Sun, 12 Sep 2021 13:25:17 +0200
Tobias Nygren wrote:
> * aarch64: rkspi, m25p, ssdfb
Stock GENERIC64 crashed on ROCKPro64, due to i2c assertion so couldn't test any
of above.
iic3 at rkiic3: I2C bus
typec-portc (fcs,fusb302) at iic3 addr 0x22 not configured
panic: kernel diagnostic
On Sun, 12 Sep 2021 13:25:17 +0200
Tobias Nygren wrote:
> * sparc64: pcfiic, spdmem
sparc64 kernel built from thorpej-i2c-spi-conf2 crashed early:
r...@netra240.rymdfartsverket.se:/usr/obj/sys/arch/sparc64/compile/GENERIC.netra240-debug
total memory = 7168 MB
avail memory = 7023 MB
mainbus0
> Date: Sat, 11 Sep 2021 15:43:24 -0700
> From: Jason Thorpe
>
> For a few months now, I've been working on improving the auto
> configuration of I2C and SPI devices. These busses, of course, are
> not self-enumerating, and besides indirect configuration of devices
> listed in a kernel config
On Sat, 11 Sep 2021 15:43:24 -0700
Jason Thorpe wrote:
> -- evbarm (ACPI), specifically a system with an I2C MUX (I think jmcneill@
> has such a beast).
I have one but it is already in a not happy state even before
thorpej-i2c-spi-conf2 so won't bother testing it:
nxpiic0 at acpi0 (I2C0,
> Date: Sat, 11 Sep 2021 17:37:32 -0700
> From: Jason Thorpe
>
> > On Sep 11, 2021, at 4:29 PM, Taylor R Campbell
> > wrote:
> >
> > Here's another sketch that is much more flexible and general.
> > Adapting it to link sets should be easy; the main point is that the
> > only untyped parts
19 matches
Mail list logo
