Re: i2c and indirect vs. direct config

> On Jun 3, 2018, at 7:30 AM, Thor Lancelot Simon wrote: > > On Sat, Jun 02, 2018 at 03:51:07PM -0700, Jason Thorpe wrote: >> >>> On Jun 2, 2018, at 2:07 PM, Paul Goyette wrote: >>> >>> There's the "minimal-functionality" control

Re: i2c and indirect vs. direct config

> On Jun 2, 2018, at 2:07 PM, Paul Goyette wrote: > > There's the "minimal-functionality" controller that sits on the "system > management PCI bus" and driven by the imc/imcsmb driver. OMG, what a dumpster fire. Geez, if they were going to to for minimal functionality, why even bother with

Re: i2c and indirect vs. direct config

> On Jun 1, 2018, at 3:45 PM, Paul Goyette wrote: > > There is at least one i2c bus controller that explicitly doesn't handle > "quick" transactions - the imc controller built into the Intel X99 chip-set. > The docs are pretty clear that it implements an absolute minimum subset of > i2c, j

Re: i2c and indirect vs. direct config

> On Jun 1, 2018, at 3:45 PM, Paul Goyette wrote: > > On Thu, 31 May 2018, Jason Thorpe wrote: > >> I spent some time reviewing NXP’s i2c spec this evening (well, during >> timeouts, etc. — GO DUBS), and I’m becoming convinced that there is a subtle >> erro

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 9:34 PM, Jason Thorpe wrote: > > I spent some time reviewing NXP’s i2c spec this evening (well, during > timeouts, etc. — GO DUBS), and I’m becoming convinced that there is a subtle > error in our i2c_bitbang code… *smacks forehead* … RPI, of course, ha

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > I wonder if the i2c bus attachments should have the option of being > treated like gpio attachements with a new command... probably a lot of > work: > > iicctl iic2 attach dstrc 0x68 3231 I’ve been thinking about this. I think we could

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > I note that the gpioow, a onewire bus, may have simular ghost issues as > i2c: It’s literally impossible to probe for devices on raw GPIO — we really should do hard-and-fast locators in that scenario. -- thorpej

Re: i2c and indirect vs. direct config

> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > Unfortunate behavior. Looking back over the sensor driver I worked on, > it appears that I always read something to determine if the device was > actually there. I spent some time reviewing NXP’s i2c spec this evening (well, during timeo

Re: i2c and indirect vs. direct config

> On May 30, 2018, at 4:42 PM, Brad Spencer wrote: > > Jason Thorpe writes: > >>> On May 30, 2018, at 11:54 AM, Brad Spencer wrote: > > A zero length write would probably also work and should be just as safe, > although I am not sure that every i2c controller

Re: i2c and indirect vs. direct config

> On May 30, 2018, at 11:54 AM, Brad Spencer wrote: > Does the techniques mentioned in these offer any hope of determining the > presence of an actual device at a particular address on the bus in a > harmless manor: > > http://forum.arduino.cc/index.php?topic=61520.0 > https://electronics.sta

Re: i2c and indirect vs. direct config

> On May 30, 2018, at 12:47 AM, Martin Husemann wrote: > > To avoid this indirect config fallback, Jared disabled this > for all i2c controllers FDT knows about, assuming it would be > easy to just fix FDT instead. To be clear — Indirect-config wasn’t disabled by setting the i2c-indirect-co

Re: PWM and user space API

> On May 28, 2018, at 2:43 PM, Jason Thorpe wrote: > > The PCA9685 also doesn’t have a variable clock UNLESS it’s driven by an > external clock source, in which case a pre-scaler value can be applied > (though, I’m not 100% certain on this — need to re-read the data sheet).

Re: PWM and user space API

> On May 28, 2018, at 11:09 AM, Jason Thorpe wrote: > > I’m going to be writing a driver for the NXP PCA9685, and want to glue it > into the PWM kernel API jmcneill@ added… but I have a bunch of uses for this > device that won’t really be covered by FDT, so I think there n

PWM and user space API

I’m going to be writing a driver for the NXP PCA9685, and want to glue it into the PWM kernel API jmcneill@ added… but I have a bunch of uses for this device that won’t really be covered by FDT, so I think there needs to be some sort of user space API as well. I have to say that I’m growing fru

Re: Revisiting uvm_loan() for 'direct' write pipes

> On May 25, 2018, at 1:01 PM, Jaromír Doleček > wrote: > > So, I'm actually thinking to change uvm_loan() to not enforce R/O > mappings and leave page attributes without change. It would require > the caller to deal with possible COW or PG_RDONLY if they need to do > writes. In other words, a

Re: Revisiting uvm_loan() for 'direct' write pipes

> On May 21, 2018, at 12:49 PM, Jaromír Doleček > wrote: > > Mostly since I want to > have at least one other consumer of the interface before I consider it > as final, to make sure it covers the general use cases. BTW, I was thinking about this, and I think you need to also handle the case

Re: Ambient light sensors in envsys

> On May 19, 2018, at 4:23 PM, Jason Thorpe wrote: > > have a driver for the particular sensor I’m using that runs entirely in user > space, …in case anyone is curious: https://github.com/thorpej/Electronics/tree/master/Sensors/TSL256x -- thorpej

Ambient light sensors in envsys

Hey folks - I have a need to have an ambient light sensor in my silly little clock project. I have a driver for the particular sensor I’m using that runs entirely in user space, but I’m wondering if it might be a good idea to glue it into envsys. There are a couple reasons for putting it into

Re: kern/53166: NFS default to UDP; it should really default to TCP

Having heard no objections, I just committed this change. /me raises glass To more reliable NFS mounts! Cheers! > On May 8, 2018, at 5:52 PM, Jason Thorpe wrote: > > Per: http://mail-index.netbsd.org/netbsd-bugs/2018/04/08/msg056464.html > <http://mail-index.netbsd.org/netbsd-

Re: CVS commit: src/sys/dev/pci

> On May 16, 2018, at 1:07 PM, Jonathan A. Kollasch > wrote: > > I'm a bit uneasy about it myself for that same reason. However, we > do not to my knowledge have the infrastructure available to do a > complete validation of the resource assignment. If we did, we'd be > able to do hot attach

Re: firefox sandboxing

> On May 14, 2018, at 6:38 AM, Thomas Klausner wrote: > > We already support chroot(2). Are user namespaces > (http://man7.org/linux/man-pages/man7/user_namespaces.7.html - looks > like capabilities) something that would be good to have for NetBSD? IMO, chroot(2) is a pretty poor way to do sa

Re: CVS commit: src/sys/dev/pci

> On May 16, 2018, at 12:02 PM, Jonathan A. Kollasch > wrote: > > Module Name: src > Committed By: jakllsch > Date: Wed May 16 19:02:00 UTC 2018 > > Modified Files: > src/sys/dev/pci: pci_map.c > > Log Message: > Enable the appropriate memory or I/O space decode in the PCI > C

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

> On May 11, 2018, at 8:28 AM, Jaromír Doleček > wrote: > > I've modified the uvm_bio.c code to use direct map for amd64. Change > seems to be stable, I've also run 'build.sh tools' to test out the > system, build suceeded and I didn't observe any problems with > stability. Test was on 6-core

kern/53166: NFS default to UDP; it should really default to TCP

Per: http://mail-index.netbsd.org/netbsd-bugs/2018/04/08/msg056464.html I don’t disagree with mlelstv@’s opinion — that TCP is the better choice. (I may be biased.) In any case, would love to clear this change out of my local

Re: Patch: new random pseudodevice

On Dec 9, 2011, at 2:38 PM, Steven Bellovin wrote: > Imagine > what would happen if someone upgraded the disk to a flash disk or > one with a large flash cache Heh, I was gonna say -- "I haven't carried around a computer that actually has a hard drive in it for at least a year now." -- tho

Re: bus_space_physload(9)

On Mar 24, 2010, at 8:04 AM, Masao Uebayashi wrote: > It's in bus_space(9) because it's API for device drivers. Its behavior needs > UVM's help, of course. Also, because bus-specific code needs to map the bus_space_tag_t + the bus_addr_t into a system physical address. -- thorpej

Re: DTrace FBT provider heads-up

On Mar 12, 2010, at 2:16 PM, Darran Hunt wrote: > This gives us over 29,000 instrumentation points available for tracing with > DTrace. The full argument list is passed to the probe on function entry, and > the return result is passed on exit. Wicked cool. I use DTrace (and the FBT!) a lot i

Re: [PAE support] Types + cosmetic fixes

On Feb 26, 2010, at 11:07 AM, Manuel Bouyer wrote: > On Fri, Feb 26, 2010 at 10:58:33AM -0800, Jason Thorpe wrote: >>> they have, although it would make sense to make it different. >>> The main problem would be configure scripts that may not parse properly >>> a dif

Re: [PAE support] Types + cosmetic fixes

On Feb 26, 2010, at 8:51 AM, Manuel Bouyer wrote: > Yes. modules can use bus_space, or inlines/macros from pmap > (eventually indirectly through e.g. bus_dma). Then we should fix bus_space and bus_dma to avoid exposing those implementation details. > they have, although it would make sense to

Re: [PAE support] Types + cosmetic fixes

On Feb 25, 2010, at 1:49 AM, Manuel Bouyer wrote: > There are ABI differences, in the same way there are ABI differences between > atari and mac68k. Those ABI differences should be considered as bugs. > I'm not sure what is the "ABI to drivers", BTW. AFAIK drivers are not > restricted to a subs

Re: [PAE support] Types + cosmetic fixes

On Feb 24, 2010, at 4:51 PM, Jean-Yves Migeon wrote: > On 02/25/10 00:42, Jason Thorpe wrote: >> >> On Feb 23, 2010, at 7:57 AM, Jean-Yves Migeon wrote: >> >>> Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and >>> non-PAE

Re: [PAE support] Types + cosmetic fixes

On Feb 24, 2010, at 1:16 AM, Manuel Bouyer wrote: > I'm not sure what the effect to configure and similar scripts would be. > If this is for modules, I think this needs more though. I suspect some > kernel build options can also cause ABI changes which can cause modules > to fail, so modules shou

Re: [PAE support] Types + cosmetic fixes

On Feb 23, 2010, at 7:57 AM, Jean-Yves Migeon wrote: > Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and > non-PAE. Why not? -- thorpej

Re: >512bytes/sector support (Re: Support for 4KB sectors size disk ?)

On Jan 13, 2010, at 3:57 AM, Izumi Tsutsui wrote: > As I wrote first, we should make a decision of buffercache(9) > and physio(9) APIs for !512bytes/sector disks. > Fixing file systems or disk drivers without it just generates > yet another random inconsisntent patch because there is no "right" f

Re: Support for 4KB sectors size disk ?

On Jan 12, 2010, at 7:14 AM, Izumi Tsutsui wrote: > > My HP9000/382 has 256bytes/sector SCSI floppy (with FDD-SCSI convertor), > but I don't think it's worth to bother to support it. > (though it might be trivial once we abandon traditional DEV_BSIZE > constant from raw I/O access and all scsipi

<    1   2   3   4   5