Re: CVS commit: src/sys/kern

2018-06-30 Thread Robert Elz
Date:Sun, 1 Jul 2018 01:54:35 +
From:Taylor R Campbell 
Message-ID:  <20180701015435.93fa760...@jupiter.mumble.net>

  | Sorry about the breakage with xen_machdep.c that made finding this
  | tricky. 

No problem, for me it turned out to actually help ... I hadn't attempted to
boot an updated kernel since the last sh mods (a week or so ago) - for
the previous fix (module build) I could not test (my kernels do not allow
modules to be loaded) so I didn't bother trying ... just verified build 
success.Without that build breakage I wouldn't have known that
recent kernels were not booting until sometime in the future.

kre



Re: CVS commit: src/sys/kern

2018-06-30 Thread Taylor R Campbell
> Date: Sun, 01 Jul 2018 06:34:05 +0700
> From: Robert Elz 
> 
> Date:Sat, 30 Jun 2018 22:47:51 +
> From:"Taylor R Campbell" 
> Message-ID:  <20180630224751.777cdf...@cvs.netbsd.org>
> 
>   | Module Name:  src
>   | Committed By: riastradh
>   | Date: Sat Jun 30 22:47:51 UTC 2018
>   |
>   | Modified Files:
>   |   src/sys/kern: kern_ntptime.c kern_tc.c
> 
>   | Enables Xen to boot again.
> 
> It does indeed.  Thanks.

Sorry about the breakage with xen_machdep.c that made finding this
tricky.  Apparently I had compiled and booted a kernel from the wrong
tree.


Re: CVS commit: src/sys/kern

2018-06-30 Thread Robert Elz
Date:Sat, 30 Jun 2018 22:47:51 +
From:"Taylor R Campbell" 
Message-ID:  <20180630224751.777cdf...@cvs.netbsd.org>

  | Module Name:src
  | Committed By:   riastradh
  | Date:   Sat Jun 30 22:47:51 UTC 2018
  |
  | Modified Files:
  | src/sys/kern: kern_ntptime.c kern_tc.c

  | Enables Xen to boot again.

It does indeed.  Thanks.

kre



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

2018-06-30 Thread Jason Thorpe



> On Jun 30, 2018, at 10:50 AM, Frank Kardel  wrote:
> 
> Hi Jason !
> 
> It is not so odd as your comment suggests. The I2C address is stored in the 
> device EEPROM and perfectly survives a power off.

Ah! If the data sheet mentions this fact, I completely missed it.

I'm afraid I probably did break it, so let's figure out how to fix... can it be 
programmed to an arbitrary address, or are there a set of specific ones you can 
chose from?

> 
> All we need to be able to is to explicitly configure the device at a 
> different address. I hope this capability was not disabled with this check-in 
> as that would make my second sensor at 0x29 useless and prohibit multiple 
> sensors on a I2C bus.
> 
> For configuring the I2C address to a different value see the pkgsrc package 
> hytctl.
> 
> Thanks for re-working the attachment logic.
> 
> Frank
> 
> 
> On 06/16/18 23:24, Jason R Thorpe wrote:
>> Module Name: src
>> Committed By:thorpej
>> Date:Sat Jun 16 21:24:36 UTC 2018
>> 
>> Modified Files:
>>  src/sys/dev/i2c: hytp14.c
>> 
>> Log Message:
>> More cleanup to i2c autoconfiguration:
>> 
>> - Get all of the drivers onto the new match quality constants.
>> - Introduce a new helper function, iic_use_direct_match(), that has
>>   all of the logic for direct-config matching.  If it returns true,
>>   the driver returns the match result (which may be 0).  If it returns
>>   false, the driver does indirect-config matching.
>> - iic_compat_match() now returns a weighted match quality; matches to
>>   lower-indexed "compatible" device property are more-specific matches,
>>   and return a better match quality accordingly.
>> 
>> XXX This driver is an odd-ball with respect to the hardware device.
>> See comments in the match routine.  Unclear how best to handle it.
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.7 -r1.8 src/sys/dev/i2c/hytp14.c
>> 
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>> 
> 

-- thorpej



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

2018-06-30 Thread Frank Kardel

Hi Jason !

It is not so odd as your comment suggests. The I2C address is stored in 
the device EEPROM and perfectly survives a power off.


All we need to be able to is to explicitly configure the device at a 
different address. I hope this capability was not disabled with this 
check-in as that would make my second sensor at 0x29 useless and 
prohibit multiple sensors on a I2C bus.


For configuring the I2C address to a different value see the pkgsrc 
package hytctl.


Thanks for re-working the attachment logic.

Frank


On 06/16/18 23:24, Jason R Thorpe wrote:

Module Name:src
Committed By:   thorpej
Date:   Sat Jun 16 21:24:36 UTC 2018

Modified Files:
src/sys/dev/i2c: hytp14.c

Log Message:
More cleanup to i2c autoconfiguration:

- Get all of the drivers onto the new match quality constants.
- Introduce a new helper function, iic_use_direct_match(), that has
   all of the logic for direct-config matching.  If it returns true,
   the driver returns the match result (which may be 0).  If it returns
   false, the driver does indirect-config matching.
- iic_compat_match() now returns a weighted match quality; matches to
   lower-indexed "compatible" device property are more-specific matches,
   and return a better match quality accordingly.

XXX This driver is an odd-ball with respect to the hardware device.
See comments in the match routine.  Unclear how best to handle it.


To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/sys/dev/i2c/hytp14.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.





Re: CVS commit: src/sbin/mount_cd9660

2018-06-30 Thread Sevan Janiyan



On 06/29/18 23:24, Izumi Tsutsui wrote:
> Nowadays it should be vndconfig(8)?
>  http://netbsd.gw.com/cgi-bin/man-cgi?vnconfig++NetBSD-current

Thanks for the heads up. It should now be fixed.


Sevan