tls@ wrote:
> On Fri, Apr 12, 2024 at 09:13:17AM -0400, Thor Lancelot Simon wrote:
> > On Sat, Apr 06, 2024 at 11:56:27PM +0900, Izumi Tsutsui wrote:
> > >
> > > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay
> > > tty devices, especiall
On Fri, Apr 12, 2024 at 09:13:17AM -0400, Thor Lancelot Simon wrote:
> On Sat, Apr 06, 2024 at 11:56:27PM +0900, Izumi Tsutsui wrote:
> >
> > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay
> > tty devices, especially news68k that can use a putcha
On Sat, Apr 06, 2024 at 11:56:27PM +0900, Izumi Tsutsui wrote:
>
> I'd like to add new APIs to use wskbd(4) input on non-wsdisplay
> tty devices, especially news68k that can use a putchar function
> provided by firmware PROM as a kernel console device.
Wouldn't a tty be a
.143
> > +++ sys/dev/wscons/wskbd.c 6 Apr 2024 06:59:50 -
> [...]
> > @@ -706,6 +709,24 @@ wskbd_input(device_t dev, u_int type, in
> > }
> > #endif
> >
> > +#if NWSDISPLAY == 0
> > + if (sc->sc_translating) {
>
> The #endif above is f
Hello,
On Sat, 6 Apr 2024 23:56:27 +0900
Izumi Tsutsui wrote:
> I'd like to add new APIs to use wskbd(4) input on non-wsdisplay
> tty devices, especially news68k that can use a putchar function
> provided by firmware PROM as a kernel console device.
>
> # Details
>
>
On Sat, Apr 06, 2024 at 23:56:27 +0900, Izumi Tsutsui wrote:
> To support "text only" framebuffer console, we can use putchar
> functions provided by the firmware PROM.
Is that a console-typewriter--like device without addressable cursor
terminal emulation? Can you use wsemul_dumb to avoid rasop
# tl;dr
I'd like to add new APIs to use wskbd(4) input on non-wsdisplay
tty devices, especially news68k that can use a putchar function
provided by firmware PROM as a kernel console device.
# Details
The news68k machines have various framebuffer options, but
most of them are not
Iain Hibbert writes:
> On Fri, 5 Jan 2024, Brad Spencer wrote:
>
>> I see a few options for doing this, such as simply matching all of the
>> possible children and using sysctl to enable the one you want. Probably
>> followed by a rescan call. That seems ugly, however. The use of
>> 'drvctl -r
s to expect things you did to persist to the next session, but
devices have device-specific semantics anyway.
m...@goathill.org (MLH) writes:
> Brad Spencer wrote :
>
>> It has a built in UART which is a separate USB device and then
>> a USB device that can be programmed to provide I2C,
Hello...
> What are you using to flash these devices?
No flashing of anything is needed to u
On Fri, 5 Jan 2024, Brad Spencer wrote:
> I see a few options for doing this, such as simply matching all of the
> possible children and using sysctl to enable the one you want. Probably
> followed by a rescan call. That seems ugly, however. The use of
> 'drvctl -r -a ' seemed to hold promise.
Brad Spencer wrote :
> It has a built in UART which is a separate USB device and then
> a USB device that can be programmed to provide I2C,
What are you using to flash these devices?
I have been using several I2C devices such as servomotor controllers,
i/o extenders, relay controllers, di
stuff,
>> as well as the normal USB UART. It is not possible to use all of the
>> modes at the same time. That is, these are not separate devices, but
>> modes within one device. Or another way, depending on the mode of the
>> chip you get different child devices attached to
. It is not possible to use all of the
> modes at the same time. That is, these are not separate devices, but
> modes within one device. Or another way, depending on the mode of the
> chip you get different child devices attached to it. I am curious on
> what the thoughts are on how th
engine allows the chip to be a I2C
bus, SPI bus and provides some simple GPIO, and a bunch of other stuff,
as well as the normal USB UART. It is not possible to use all of the
modes at the same time. That is, these are not separate devices, but
modes within one device. Or another way, depending on
On Fri, Aug 19, 2022 at 01:52:47AM +, Taylor R Campbell wrote:
> All that said: What is the failure mode you're seeing for ihidev that
> blocks suspend?
It fails to read HID descriptor. The ihidev device remains unfunctionnal
and breaks suspend.
I thought about this workaround:
--- sys/dev/i
p...@whooppee.com (Paul Goyette) writes:
>Don't forget to deregister the device if the xxx_attach() later exits...
I think the point was to not do this, so that a failed attach doesn't
prevent the system from entering sleep mode.
Here, calling pmf_register first on attachment is then required,
b
> Date: Fri, 19 Aug 2022 01:22:39 +
> From: Emmanuel Dreyfus
>
> I have patches to move the pmf_device_register() earlier in xxx_attach()
> to workaround the problem in iwm(4) and ihidev(4) where I encounter the
> problem, but perhaps the problem could be worked around globaly, by not
> faili
On Fri, 19 Aug 2022, Emmanuel Dreyfus wrote:
Hello
When a devices fails initialization, the xxx_attach() function may exit
early, before calling pmf_device_register().
The consequence is that any attempt to put the system to sleep fail with
a "Devices without power management su
Hello
When a devices fails initialization, the xxx_attach() function may exit
early, before calling pmf_device_register().
The consequence is that any attempt to put the system to sleep fail with
a "Devices without power management support: ..." message.
Weird things happ
Thanks Taylor and Chuck for the comments. Replying to both emails
there.
Taylor R Campbell wrote:
> > Date: Fri, 12 Aug 2022 17:31:31 +1000
> > From: Simon Burge
> >
> > As part of my boot-from-ZFS work, I've generalised how "non-disk"
> >
_components(). but I don't think that this change
is actually an improvement. it moves the knowledge of what kinds of disk
devices
that raidframe wants to examine to look for its labels out of the raidframe code
and into every other block device driver. if you really want to get rid of
this list
> Date: Fri, 12 Aug 2022 17:31:31 +1000
> From: Simon Burge
>
> As part of my boot-from-ZFS work, I've generalised how "non-disk"
> disk-type storage devices interface with the mountroot mechanism and
> also tidied up how devices can report that they can contain
Hi folks,
As part of my boot-from-ZFS work, I've generalised how "non-disk"
disk-type storage devices interface with the mountroot mechanism and
also tidied up how devices can report that they can contain a virtual
storage device (eg, a RAID, LVM, ZFS, etc).
A summary of changes:
On Sun, Jul 03, 2022 at 01:20:15PM +0200, Martin Husemann wrote:
> On Sun, Jul 03, 2022 at 05:21:27AM -, Michael van Elst wrote:
> > Another question of course is why the isa fd driver reads a disklabel at all
> > when it (ab-)uses the partition number to select densities.
>
> Yeah, can we com
On Sun, Jul 03, 2022 at 05:21:27AM -, Michael van Elst wrote:
> Another question of course is why the isa fd driver reads a disklabel at all
> when it (ab-)uses the partition number to select densities.
Yeah, can we commit that fix with a log like:
fd(4): only support GPT partitioning on flo
een around forever, so is this
>perhaps due to dkwedge_discover?
fd doesn't try to discover wedges, but for identifying a possible wedge
rootconf() calls opendisk() and VOP_IOCTL(, DIOCGDINFO, ) to check the
disklabel. And opendisk() only opens the RAW_PART.
It's difficult to skip flo
Hi, all,
It has been ages since I've used floppies in NetBSD very much, but
checking the man page, different slice letters are used to indicate disk
densities. From fdc(4):
The driver supports the following floppy diskette formats by using
particular partitions:
1.44MB 3.
mlel...@serpens.de (Michael van Elst) writes:
>- The copied filesystem code in libsa uses absolute disk offsets
> in bytes to locate superblocks. A backend that uses physical blocks
> cannot easily address such offsets if it doesn't know the block
> size.
> The filesystem code deduces this as
nick.hud...@gmx.co.uk (Nick Hudson) writes:
>https://github.com/skrll/src/commit/a5432c0ce71ea2fd1b7ad22ff6c26d01f4dca7=
>1a
When looking at this, I got a few more issues:
- The copied filesystem code in libsa uses absolute disk offsets
in bytes to locate superblocks. A backend that uses phys
On 23/04/2022 15:25, Tobias Nygren wrote:
On Sat, 23 Apr 2022 14:17:09 - (UTC)
Michael van Elst wrote:
nick.hud...@gmx.co.uk (Nick Hudson) writes:
To enable efiboot to work from Apple M1 nvme I had to apply this diff so
that libsa picks up the fs_fshift based FFS_FSBTODB.
Is this c
On Sat, 23 Apr 2022 14:17:09 - (UTC)
Michael van Elst wrote:
> nick.hud...@gmx.co.uk (Nick Hudson) writes:
>
> >To enable efiboot to work from Apple M1 nvme I had to apply this diff so
> >that libsa picks up the fs_fshift based FFS_FSBTODB.
>
> >Is this correct or does it mean the FS has an
nick.hud...@gmx.co.uk (Nick Hudson) writes:
>To enable efiboot to work from Apple M1 nvme I had to apply this diff so
>that libsa picks up the fs_fshift based FFS_FSBTODB.
>Is this correct or does it mean the FS has an incorrect fs_fsbtodb? (and
>there's a bug in mkfs somewhere)
The bug is prob
Hi,
To enable efiboot to work from Apple M1 nvme I had to apply this diff so
that libsa picks up the fs_fshift based FFS_FSBTODB.
Is this correct or does it mean the FS has an incorrect fs_fsbtodb? (and
there's a bug in mkfs somewhere)
Thanks,
Nick
Index: sys/ufs/ffs/fs.h
==
voff_t)pi.pi_secsize * pi.pi_size);
-
+ error = (*ioctl)(vp->v_rdev, DIOCGMEDIASIZE, &msize, FREAD, curlwp);
+ if (error == 0)
+ uvm_vnp_setsize(vp, (voff_t)msize);
+
return 0;
}
---END---
I've used DIOCGMEDIASIZE which seems to work on all the disk-type devices
th
r...@sdf.org (RVP) writes:
>Are block and dk* (wedge) devices supposed to support lseek()?
When a disk device is opened, the DIOCGPARTINFO ioctl is used to
query the size of the disk and cache it in the vnode.
The dk driver doesn't represent a disk and doesn't support DIOCGPART
Are block and dk* (wedge) devices supposed to support lseek()?
Because I see this on both -HEAD and 9.2_STABLE:
# Disks
#
$ sudo stat -f '%N: %z' /dev/rsd0
/dev/rsd0: 7849115648 # works
$ sudo stat -f '%N: %z' /dev/sd0
/dev/sd0: 0
On Thu, Jul 15, 2021 at 11:00:36AM -0700, Chuck Silvers wrote:
> setting an extattr on a device node in UFS is already disallowed.
> ffs_setextattr() has this check:
>
> if (ap->a_vp->v_type == VCHR || ap->a_vp->v_type == VBLK)
> return (EOPNOTSUPP);
>
> I have not
On Thu, Jul 15, 2021 at 06:26:55PM +0200, Rhialto wrote:
> > Seems to me the best/safest thing to do for now would be to prohibit
> > the extended-attr on devices and fifos.
>
> If I have a normal file system, and in a directory is an entry with an
> inode for a fifo (or
On Thu, Jul 15, 2021 at 02:55:10AM +, David Holland wrote:
> So I think what I would like to do is, for now at least (the device
> plumbing changes I posted about a couple months back would eventually
> change the situation) just prohibit extended attributes on device
> nodes entirely.
>
> (I
> On Jul 14, 2021, at 9:14 PM, Paul Goyette wrote:
>
> Seems to me the best/safest thing to do for now would be to prohibit
> the extended-attr on devices and fifos.
That seems at best a sort-term workaround, but perhaps warranted to eliminate
the data corruption issue.
-- thorpej
On Wed 14 Jul 2021 at 21:14:16 -0700, Paul Goyette wrote:
> Seems to me the best/safest thing to do for now would be to prohibit
> the extended-attr on devices and fifos.
If I have a normal file system, and in a directory is an entry with an
inode for a fifo (or a device), and I set an ex
Seems to me the best/safest thing to do for now would be to prohibit
the extended-attr on devices and fifos.
On Thu, 15 Jul 2021, David Holland wrote:
I noticed that there was a loose function ffsext_strategy lying
around, mentioned it to Christos, and he committed this:
> Modified Fi
od (actually it isn't, it blew up a vnode tables
cleanup patch I was preparing, but never mind that for now) but:
If this is needed for fifos, isn't it also needed for devices?
The ffs extended attribute blocks are stored in the buffer cache as
negative offsets into the file they belon
> A working devfs that can be used in all places where device nodes
> might be needed would mean that the device vnode apparatus in ffs and
> every other fs could be removed, yes,
...only if you don't mind breaking compatability.
I don't know to what extent compatability is necessary, but I think
was that it was a mistake. I don't propose to
waste my time doing it again.
> The way we handle ZFS is just goofy
As far as I know this is largely or entirely the fault of the ZFS
developers for doing their own thing instead of sticking to the
established/conventional abstraction
wo...@planix.ca ("Greg A. Woods") writes:
>My understanding w.r.t. the rationale FreeBSD used in deciding to remove
>the block devices was that FreeBSD never really buffered/cached by
>device in the first place. Also, according to PHK in his 2002 BSDCan
>paper about FreeB
Brian Buhrow writes:
> hello David. What I don't see in your proposal is a way of
> implementing a dynamic device
> filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that
> I'm aware of that
> use static special files in their filesystems
At Tue, 1 Jun 2021 14:00:50 -0400 (EDT), Mouse
wrote:
Subject: Re: Devices.
>
> Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the
> chroot to have as minimal a set of devices as still allows it to do its
> job, and in particular I do not want it to ever dynami
At Sat, 29 May 2021 16:17:13 -0700, John Nemeth wrote:
Subject: Re: Devices.
>
> On May 29, 22:52, David Holland wrote:
> } On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote:
> }
> } > > For disks, which for historical reasons live in both cdevsw and
> } > > bd
" these nodes would be device nodes and directories at the same
time. That would be much nicer than having two nodes (with slightly
different names), one for the device node and one for the directory.
I don't think I've seen a devfs like that; there is a hierarchy in the
linux /
> When you want a device tree in a chroot, you just mount the device
> filesystem on that chroot.
Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the
chroot to have as minimal a set of devices as still allows it to do its
job, and in particular I do not want it to ever
hello David. What I don't see in your proposal is a way of
implementing a dynamic device
filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that I'm
aware of that
use static special files in their filesystems to point to devices. If your
proposal wa
hink devfs would fix. (I know what
> headaches *I* think it would fix. I'm wondering which ones *you* think
> are worth bringing it in for.)
Even though I didn't start this thread, I'd like to chime in here.
Hardware isn't static, and hasn't been for a long time. Hot
>> You can run devpubd. When a wedge and thus the dk* unit attaches,
>> it runs the 01-makedev hook that creates the device node in /dev.
> That's not a "mode". It's a clunky userland daemon that tries to
> make up for the fact that we don't have a devfs.
Your wording is heavily biased.
To bias
On May 30, 14:24, Michael van Elst wrote:
} mueller6...@twc.com ("Thomas Mueller") writes:
}
} > Where do I find the "enough dk* nodes" mode? Would it be in
} > the kernel config? I never saw it.
}
} You can run devpubd. When a wedge and thus the dk* unit attaches, it
} runs the 01-makedev hook
mueller6...@twc.com ("Thomas Mueller") writes:
>Where do I find the "enough dk* nodes" mode? Would it be in the kernel
>config? I never saw it.
You can run devpubd. When a wedge and thus the dk* unit attaches, it
runs the 01-makedev hook that creates the device node in /dev.
from Michael van Elst:
> mueller6...@twc.com ("Thomas Mueller") writes:
> >It's a nuisance not to be able to recognize all partitions on a
> >GPT-partitioned drive because not enough dk* nodes have been configured.
> >FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
>
mueller6...@twc.com ("Thomas Mueller") writes:
>It's a nuisance not to be able to recognize all partitions on a
>GPT-partitioned drive because not enough dk* nodes have been configured.
>FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
>between GPT partitions and MBR-ba
It's been proposed that we should stop having
> } block devices, which would have the same net effect; I have no strong
> } opinion on that and it doesn't need to be part of this set of changes.
> I was thinking the same thing about getting rid of block
> devices. The onl
dholland-t...@netbsd.org (David Holland) writes:
>This was all based on the experience of adding discard and adding the
>dispatching for it as a first-class [bc]devsw op rather than an ioctl:
>it was a pain because it ultimately required touching _every_ driver,
>not just the ones that needed to s
I'm wondering which ones *you* think
are worth bringing it in for.)
The major downside I've seen is that they also render difficult or
impossible a number of clever things that are rarely useful but
borderline essential when they are useful. Most of those things are
based on devices bein
27;s time that we joined the 21st century. Anything done with
> devices should be done with idea of a devfs in mind. Yes, devfs
> like things have caused a lot of problems on other operating systems,
> but I think we have enough brain power and enough real world examples
> to be able
On Sun, May 30, 2021 at 12:00:16AM +0200, Johnny Billquist wrote:
> On 2021-05-29 22:26, David Holland wrote:
> > There are a number of infelicities in the way we currently handle the
> > I/O plumbing for devices in the kernel. These include:
>
> [...]
>
> Just
d of the bdev/cdev distinction. It is, as
} > you say, a historical artifact, and IMO it is not serving anyone at
} > this point.
}
} It is deeply baked into the system call API and into POSIX, so it's
} not going anywhere. It's been proposed that we should stop having
} block devices, wh
his point.
It is deeply baked into the system call API and into POSIX, so it's
not going anywhere. It's been proposed that we should stop having
block devices, which would have the same net effect; I have no strong
opinion on that and it doesn't need to be part of this set of changes
On 2021-05-29 22:26, David Holland wrote:
There are a number of infelicities in the way we currently handle the
I/O plumbing for devices in the kernel. These include:
[...]
Just looking/thinking about the ioctl part - you say abolish it inside
the kernel. So does that mean that we keep the
On Sat, 29 May 2021, David Holland wrote:
Anyhow, I think this architecture addresses all the problems cited.
The critical question is: what have I overlooked? There are probably
some issues I've thought about but failed to remember to discuss
above; there are also probably some issues I've
> There are a number of infelicities in the way we currently handle the
> I/O plumbing for devices in the kernel. These include: [...]
Thank you. I don't agree with all of that (which I daresay astonishes
nobody), but much of it sounds like a codification of some vague unease
There are a number of infelicities in the way we currently handle the
I/O plumbing for devices in the kernel. These include:
- cloning devices exist but as currently implemented violate
layering abstractions;
- every file system needs to have cutpaste vnode ops tables for
device
quot;stepping" effect.
What software do you use that supports the "tilt" option? I think I have
figured out what gimp and mypaint expect from devices (it seems to just
use the extra axes as tilt parameters, so wscons will need another axis),
I will start looking into adding the driv
Hi,
Sorry. I missed your email.
Yorick Hardy writes:
(snip)
> Understood! Based on the xf86-input-usbtablet, I can have a look
> at extending wscons and xf86-input-ws to support tilt also,
> do you have an XD-0912-U to test with?
>
> (I take a very long time to do the driver work, so it might
>
bluetooth mode which I have not looked at.
> >
> > Linux has extensive support for the Wacom devices, but (in my
> > opinion) the code is so tangled that it was much easier to work
> > back from the reports and watching how they changed in response to
> > physical events.
Hi,
Yorick Hardy writes:
> Dear tech-kern,
>
> Please find a patch below for a new uintuos driver for two Wacom
> Intuos tablets (the Art CTH490 and Intuos M). The Intuos M also
> has a bluetooth mode which I have not looked at.
>
> Linux has extensive support for the Waco
On Mon, Oct 28, 2019 at 01:04:13PM -0700, Jason Thorpe wrote:
>
> > On Oct 28, 2019, at 12:03 PM, Michael van Elst wrote:
> >
> > So anything smaller as DEV_BSIZE will already fail at some other place,
> > validating it in bounds_check_with_label might even be the best place
> > for now, indepen
recall trying the same disk on something more
> recent, though I also don't recall why not. I don't find comparable
> commits in my other trees, so if I did try it, it presumably didn't
> crash the relevant kernel(s).)
>
> So, while I agree that there are vanishingly small n
don't find comparable
commits in my other trees, so if I did try it, it presumably didn't
crash the relevant kernel(s).)
So, while I agree that there are vanishingly small numbers of "real"
devices showing such behaviour, I also think it a bug for attaching a
disk to crash the k
> On Oct 28, 2019, at 12:03 PM, Michael van Elst wrote:
>
> So anything smaller as DEV_BSIZE will already fail at some other place,
> validating it in bounds_check_with_label might even be the best place
> for now, independent on wether it triggers a division by zero. Better
> places could exis
To provide a bit more context: this code path with the potential
division by zero has been in the tree for over a decade; if there
exist any real devices with sector size below DEV_BSIZE, they
would have resulted in a div-by-zero since 2006-11-25.
The panic I fixed was a result of
On Mon, Oct 28, 2019 at 07:24:03PM +0100, Martin Husemann wrote:
> The practical difference is likely zero, as such setup just do not happen
> in real life (and the other error(s) needed to get here being fixed).
> I prefer my version because it does not introduce artifical limits on the
> sector
}
This makes bounds_check_with_label() fail early for all devices with small
sector size.
Instead I would like to fix it differently. The div by zero happend when
calculating the cylinder number for the buffer - which is not used a lot
typically (or not at all). This looks lik
Dear Michael,
On 2019-10-27, Michael wrote:
> Hello,
>
> On Sat, 26 Oct 2019 21:54:51 +0200
> Yorick Hardy wrote:
>
> > Dear tech-kern,
> >
> > Please find a patch below for a new uintuos driver for two Wacom
> > Intuos tablets (the Art CTH490 and Intuos M). The Intuos M also
> > has a blueto
Hello,
On Sat, 26 Oct 2019 21:54:51 +0200
Yorick Hardy wrote:
> Dear tech-kern,
>
> Please find a patch below for a new uintuos driver for two Wacom
> Intuos tablets (the Art CTH490 and Intuos M). The Intuos M also
> has a bluetooth mode which I have not looked at.
I bought a small Intuos ( n
Dear tech-kern,
Please find a patch below for a new uintuos driver for two Wacom
Intuos tablets (the Art CTH490 and Intuos M). The Intuos M also
has a bluetooth mode which I have not looked at.
Linux has extensive support for the Wacom devices, but (in my
opinion) the code is so tangled that it
Hello,
There are a couple of ways of using a yubikey as a certificate source
for use with SSH. One is as a CCID device via PC/SC Lite and the other
is via GPG.
Going down the former approach, using PC/SC Lite to get setup from
scratch (ignoring keygen), install pcsc-lite (as the middleware) and
ope
hi Nat,
i object to the plan here. we should simply just use the
file system to control this, like normal unix stuff.
eg, ttyaction should chown the audio device to the console
user or whatever the admin chooses. it should be possible
for me to decide to make things as open or as closed as
pos
/audioctl/mixer devices at all times.
These changes primarily affect audio when hw.driverN.multiuser=0 although it is
no longer permissible to interfere with the audio_info structures of an audio
channel belonging to another user regardless of the value of
hw.driverN.multiuser.
This should address PR
in the list of playing channels.
User noticable changes are that it is not permissible to open /dev/mixer if
another user has audio playing - so it is not possible to interfere with
another users mixer settings.
The super user has access to audio/audioctl/mixer devices at all times.
These
On Sat, Dec 31, 2016 at 11:47:07AM -0600, Jonathan A. Kollasch wrote:
> Example config(5) file addition:
>
> spigen0 at spi1 slave 0
>
Also useful:
device-majorspigen char 159spigen
and then you can use:
# mknod spigen0 c spigen 0
Jonathan Kolasch
> >> we already have the SPI(4) framework. My question is, how can a user-space
> >> program read from or write to a SPI connected peripheral? I've found the
> >> gpioctl(8) program and gpio( devices for talking to GPIO connected devices,
> >&g
hello. A patch would be great! I realize I may have to back port it
to NetBSD-5, but I'm ok with that .
I do plan to make these changes to ugen(4) part of -current, but I
wanted to be confident that my fixes work reliably in my known working
environment before I move them to -curr
On 01/27/16 19:10, Brian Buhrow wrote:
hello. Although I've been silent on this issue for a while, I've
continued to make progress in getting the ugen(4) driver into a state where
it works well with the libimobiledevice tools and can reliably be used with
Apple products. The problem I'v
hello. Although I've been silent on this issue for a while, I've
continued to make progress in getting the ugen(4) driver into a state where
it works well with the libimobiledevice tools and can reliably be used with
Apple products. The problem I've run into now is the one that's been
tro
row
> Cc: Nick Hudson ; Nick Hudson ;
> tech-kern@NetBSD.org
> Subject: Re: Potential problem with reading data from usb devices with
> ugen(4)
>
>
> Brian Buhrow writes:
>
> > To answer your question about whether there is a standard for
> > generating these
Brian Buhrow writes:
> To answer your question about whether there is a standard for
> generating these packets, it seems there is not. Linux expects you to use
> an ioctl() to generate the packet while FreeBSD expects you to send a write
> request with 0 bytes, as we do with the ugen(4)
hello greg. I've been trying to keep the noise on this thread to a
minimum, but it appears I mis-wrote about what happens when trying to
generate zero-length packets. The state of my re-worked ugen(4) is much
more stable and I have installed some additional diagnostics to determine
what is
uirement lower down in the stack that transactions have >0
length, then the parts that validate system calls should check that.
> If option DIAGNOSTIC is not defined, then I'm simply unable to write to any
> USB devices attached to that bus without a reboot.
Generally in a situation wher
= 0".
If option DIAGNOSTIC is not defined, then I'm simply unable to write to any
USB devices attached to that bus without a reboot.
With uhci(4), things go better. that is, I can still write to the bus
and devices on the bus after I issue the ZLP write request, but I don't
thin
hello. For completeness, let me be more clear about what happens when
I attempt to send zero length packets to a USB device now that I've sorted
out the other issues.
With ehci(4) and options DIAGNOSTIC turned on, I get a
panic: curlen == 0.
Without options DIAGNOSTIC and ehci(
On 27/12/2015 20:00, Brian Buhrow wrote:
hello Nick. I've been doing this work under NetBSD-5 and the ehci(4)
driver definitely doesn't behave well when sent a zero-length packet under
that branch.
Define "doesn't behave well"
I also checked out your USB branch, as well as the -cur
1 - 100 of 239 matches
Mail list logo
