Re: RFC: PERCPU_LIST to fix PR kern/52515

On Fri, Dec 8, 2017 at 6:51 PM, Kengo NAKAHARA wrote: > Hi, > > On 2017/12/07 14:21, Taylor R Campbell wrote: >> I dropped this thread on the floor a while ago and I forget what the >> status was. I've had a patch sitting in my tree for a while which I >> brushed off to put

I2C iic_exec() and clock stretch

Sorry to intrude... So... I have a I2C device I am writing a driver for that has a read cycle that needs one of the following: 1) Start a read with a STOP, except that before the data is sent down the bus, clock stretch for a bit while the device is working on what is is suppose to be working

Re: getsockopt(2)

chris...@astron.com (Christos Zoulas) wrote: >In article , >Robert Swindells wrote: >> >>chris...@astron.com (Christos Zoulas) wrote: >>>In article , >>> >>>So depending on the contents of the sockval we do something

Re: getsockopt(2)

In article , Robert Swindells wrote: > >chris...@astron.com (Christos Zoulas) wrote: >>In article , >> >>So depending on the contents of the sockval we do something different? > >FreeBSD does. The calls to copy in or

Re: getsockopt(2)

chris...@astron.com (Christos Zoulas) wrote: >In article , >Robert Swindells wrote: >> >>I wrote: >>>Does anyone know why we don't use the input 'optlen' parameter to the >>>getsockopt(2) syscall, we do write back to it on return. >>> >>>In

Re: kernel condvars: how to use?

> Date: Mon, 11 Dec 2017 11:13:16 -0500 (EST) > From: Mouse > > > If read does > > > while (sc->sc_foo < sc->sc_bar) > > cv_wait(>sc_cv, >sc_lock); > > > then whoever changes sc_foo or sc_bar might test whether they changed > > from sc->sc_foo <

Re: kernel condvars: how to use?

>>> If anything, you should just test rather whether you changed from a >>> state that would block a read to a state in which a read can make >>> progress. >> That's kind-of what LPT_RF_WAITING records. > What I meant is the condition that read actually loops on. [...] Yes, that's what I thought

Re: Merging ugen into the usb stack

Martin Husemann writes: > On Mon, Dec 11, 2017 at 08:24:00AM -0500, Greg Troxel wrote: >> I wonder if we should be attaching drivers to endpoints, rather than >> devices. > > This is the drivers decision (we have drivers that do it). > > However, ugen is not able to attach

Re: Merging ugen into the usb stack

On Mon, Dec 11, 2017 at 08:24:00AM -0500, Greg Troxel wrote: > I wonder if we should be attaching drivers to endpoints, rather than > devices. This is the drivers decision (we have drivers that do it). However, ugen is not able to attach to a single interface itself (currently). Martin

Re: Merging ugen into the usb stack

Martin Husemann writes: > However, it can not work with the way NetBSD uses ugen devices: > > uftdi0 at uhub3 port 2 > uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, > addr 3 > ucom0 at uftdi0 portno 1 > ucom1 at uftdi0 portno 2 > > I can

Re: Merging ugen into the usb stack

> Date: Mon, 11 Dec 2017 12:44:32 +0100 > From: Martin Husemann > > I could hack uftdi to allow attaching a ugen child, but that sounds > like a very special hack. Jared suggested to instead make ugen not a > separate device, but globaly fold it into the usb stack. That would

Re: RFC: PERCPU_LIST to fix PR kern/52515

> Date: Mon, 11 Dec 2017 11:55:27 +0100 > From: Edgar Fuß > > > struct psref { > > - LIST_ENTRY(psref) psref_entry; > > + SLIST_ENTRY(psref) psref_entry; > > + /* To keep ABI with LIST_ENTRY(psref) version. */ > > + void

Merging ugen into the usb stack

Hi folks, I have a Guruplug JTAG device (and right now need to use it to unbrick one of my Guruplugs after some ... stupid u-boot experiment). The device is supported by openocd, which we have in pkgsrc. The driver used is:

Re: RFC: PERCPU_LIST to fix PR kern/52515

> struct psref { > - LIST_ENTRY(psref) psref_entry; > + SLIST_ENTRY(psref) psref_entry; > + /* To keep ABI with LIST_ENTRY(psref) version. */ > + void*psref_unused0; Isn't it somewhat fishy to manally pad this, knowing how big