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

2020-10-21 Thread Rin Okuyama
Hi, On 2020/10/21 15:42, Michael wrote: Hello, On Sun, 18 Oct 2020 11:54:21 + "Rin Okuyama" wrote: Module Name:src Committed By: rin Date: Sun Oct 18 11:54:21 UTC 2020 Modified Files: src/sys/dev/wsfb: genfb.c Log Message: For WSDISPLAYIO_GET_FBINFO ioctl, set

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

2020-10-21 Thread Michael
Hello, On Sun, 18 Oct 2020 11:54:21 + "Rin Okuyama" wrote: > Module Name: src > Committed By: rin > Date: Sun Oct 18 11:54:21 UTC 2020 > > Modified Files: > src/sys/dev/wsfb: genfb.c > > Log Message: > For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags >

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

2020-10-18 Thread Rin Okuyama
On 2020/10/18 21:18, Jared McNeill wrote: I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get when you mmap the device. When shadow FB is used, that is generally only used for rasops and mmap bypasses the shadow and uses device memory directly. So I think this could

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

2020-10-18 Thread Jared McNeill
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get when you mmap the device. When shadow FB is used, that is generally only used for rasops and mmap bypasses the shadow and uses device memory directly. So I think this could cause performance regressions on such

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

2020-10-16 Thread SAITOH Masanobu
On 2020/10/16 14:53, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Fri Oct 16 05:53:40 UTC 2020 Modified Files: src/sys/dev/pci: if_wm.c Log Message: Fixes a problem that the attach function reported "wm_gmii_setup_phytype: Unknown PHY model.

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

2020-10-12 Thread Michael
Hello, On Sun, 11 Oct 2020 21:41:57 + "Julian Coleman" wrote: > Module Name: src > Committed By: jdc > Date: Sun Oct 11 21:41:57 UTC 2020 > > Modified Files: > src/sys/dev/pci: radeonfb.c > > Log Message: ... > don't ignore the bottom 200 lines of the display (for no

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

2020-10-02 Thread Rin Okuyama
On 2020/10/02 22:42, Jonathan A. Kollasch wrote: On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Sun Jul 21 15:57:24 UTC 2019 Modified Files: src/sys/dev/fdt: dw_apb_uart.c Log Message: The device cannot recognize

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

2020-10-02 Thread Jonathan A. Kollasch
On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote: > Module Name: src > Committed By: rin > Date: Sun Jul 21 15:57:24 UTC 2019 > > Modified Files: > src/sys/dev/fdt: dw_apb_uart.c > > Log Message: > The device cannot recognize break signal. Use + (five plus signs) as

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

2020-09-19 Thread Kimmo Suominen
I don't think this should be reverted, because LUN 0 must exist, but if there is no device on it, it will report "NOT PRESENT". We do not want the scan to stop in this case, but it should continue with other LUNs (such as those found through REPORT LUNS in the future). Kind regards, + Kimmo On

Re: CVS commit: src/sys/dev/mii (PR/kern 55538)

2020-08-27 Thread Frank Kardel
Hi Martin ! That is strange - I didn't expect that, especially as the previous code was wrong with respect to state tracking. Can you check whether the addresses do not have the DEtACHED flag? You could try the dtrace script from the PR - it shows a little bit what is going on. There was also

Re: CVS commit: src/sys/dev/mii (PR/kern 55538)

2020-08-27 Thread Martin Husemann
On Mon, Aug 24, 2020 at 12:46:04PM +, Frank Kardel wrote: > Module Name: src > Committed By: kardel > Date: Mon Aug 24 12:46:04 UTC 2020 > > Modified Files: > src/sys/dev/mii: mii_physubr.c > > Log Message: > Keep the change check invariant intact. The previous code could miss

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

2020-08-03 Thread Valery Ushakov
On Tue, Aug 04, 2020 at 07:12:54 +0300, Valery Ushakov wrote: > On Tue, Aug 04, 2020 at 12:50:11 +0900, SAITOH Masanobu wrote: > > > On 2020/08/03 23:00, Valeriy E. Ushakov wrote: > > > Module Name: src > > > Committed By: uwe > > > Date: Mon Aug 3 14:00:41 UTC 2020 > > >

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

2020-08-03 Thread SAITOH Masanobu
On 2020/08/04 12:50, SAITOH Masanobu wrote: Hi. On 2020/08/03 23:00, Valeriy E. Ushakov wrote: Module Name:    src Committed By:    uwe Date:    Mon Aug  3 14:00:41 UTC 2020 Modified Files: src/sys/dev/mii: miidevs_data.h Log Message: mii_knowndevs[] is de facto const, define it as

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

2020-08-03 Thread Valery Ushakov
On Tue, Aug 04, 2020 at 12:50:11 +0900, SAITOH Masanobu wrote: > On 2020/08/03 23:00, Valeriy E. Ushakov wrote: > > Module Name:src > > Committed By: uwe > > Date: Mon Aug 3 14:00:41 UTC 2020 > > > > Modified Files: > > src/sys/dev/mii: miidevs_data.h > > > >

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

2020-08-03 Thread SAITOH Masanobu
Hi. On 2020/08/03 23:00, Valeriy E. Ushakov wrote: Module Name:src Committed By: uwe Date: Mon Aug 3 14:00:41 UTC 2020 Modified Files: src/sys/dev/mii: miidevs_data.h Log Message: mii_knowndevs[] is de facto const, define it as such. To generate a diff of this

re: CVS commit: src/sys/dev

2020-07-28 Thread matthew green
"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Tue Jul 28 09:36:05 UTC 2020 > > Modified Files: > src/sys/dev/ic: nvmevar.h > src/sys/dev/pci: nvme_pci.c > > Log Message: > add a quirk to disable MSI, and enable it for Intel SSD DC P4500 > >

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

2020-07-17 Thread Jaromír Doleček
One of the things which need to be done is calling the if_ioctl always with the IFNET_LOCK() held. Right now it sometimes is, and other times it is not, so it's not possible to rely on it and KASSERT(). As for bnx(4) I did just some basic fixes around making it work with MSI(-X), since I don't

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

2020-07-17 Thread Jason Thorpe
> On Jul 17, 2020, at 3:50 PM, matthew green wrote: > > any chance you can look at NET_MPSAFE here etc? :) I have a bunch of local changes for this in one of my trees, and I hope to get back to it after netbsd-10 branches. -- thorpej

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

2020-07-17 Thread matthew green
"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Fri Jul 17 09:48:21 UTC 2020 > > Modified Files: > src/sys/dev/pci: if_bnx.c > > Log Message: > re-enable MSI/MSI-X, the TX timeouts were caused by the IFF_OACTIVE handling, > which was fixed in previous

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

2020-07-12 Thread Kimmo Suominen
Hi Michael, Perhaps your commit missed some changes? The code no longer compiles. Cheers, + Kimmo /p/netbsd/cvs/src/sys/dev/i2c/dbcool.c: In function 'dbcool_attach': /p/netbsd/cvs/src/sys/dev/i2c/dbcool.c:778:4: error: 'struct dbcool_softc' has no member named 'sc_prop' sc->sc_prop =

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

2020-07-11 Thread Kimmo Suominen
On Sun, Jul 12, 2020 at 12:05:37AM +0700, Robert Elz wrote: > Just to make things clear here, the LUN you're talking about is not > the scsi unit number (which is what I think Martin was referring to) > but a sub-device number within a single scsi ID. Right? Correct. I should have written "SCSI

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

2020-07-11 Thread Robert Elz
Date:Sat, 11 Jul 2020 18:24:51 +0300 From:Kimmo Suominen Message-ID: <20200711152451.ga1...@homeworld.netbsd.org> | On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote: | > I don't understand the change. When was this broken? This has always worked

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

2020-07-11 Thread Martin Husemann
On Sat, Jul 11, 2020 at 06:24:51PM +0300, Kimmo Suominen wrote: > I think all real SCSI hardware I've had has always just only had LUN 0, > and each disk has been on its own SCSI ID (target). Yes, I confused ID and LUN here - just ignore me. Martin

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

2020-07-11 Thread Kimmo Suominen
On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote: > I don't understand the change. When was this broken? This has always worked > for me e.g. with the sd0 at LUN 3 and the controller at 6 or 7. I think all real SCSI hardware I've had has always just only had LUN 0, and each disk

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

2020-07-11 Thread Martin Husemann
On Sat, Jul 11, 2020 at 05:57:46PM +0300, Kimmo Suominen wrote: > On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote: > > I'd reckon a pullup to NetBSD 9 would be in order? > > Yes, I was just waiting to be able to link to mail-index. I had > already checked that the patch applies

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

2020-07-11 Thread Kimmo Suominen
On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote: > I'd reckon a pullup to NetBSD 9 would be in order? Yes, I was just waiting to be able to link to mail-index. I had already checked that the patch applies cleanly to both netbsd-9 and netbsd-8.

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

2020-07-11 Thread Jukka Ruohonen
On Sat, Jul 11, 2020 at 02:31:46PM +, Kimmo Suominen wrote: > Use case 2: A Linode boot profile with multiple disks results in > the first disk ("sda") on LUN 1, while the second disk ("sdb") is > on LUN 0, each on their own bus. As Linode is quite popular, and supposedly uses a rather

re: CVS commit: src/sys/dev/ofw

2020-06-27 Thread matthew green
"Martin Husemann" writes: > Module Name: src > Committed By: martin > Date: Fri Jun 26 10:14:32 UTC 2020 > > Modified Files: > src/sys/dev/ofw: ofw_subr.c > > Log Message: > Remove !cold KASSERT - it does not compile on all kernels, and it is not the > right thing to test for

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

2020-06-25 Thread Christos Zoulas
In article <18083.1593053...@splode.eterna.com.au>, matthew green wrote: >"Jaromir Dolecek" writes: >> Module Name: src >> Committed By:jdolecek >> Date:Wed Jun 24 19:55:25 UTC 2020 >> >> Modified Files: >> src/sys/dev/ic: ibm561.c >> >> Log Message: >> avoid

re: CVS commit: src/sys/dev/ic

2020-06-24 Thread matthew green
"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Wed Jun 24 19:55:25 UTC 2020 > > Modified Files: > src/sys/dev/ic: ibm561.c > > Log Message: > avoid allocating almost 5k struct ibm561data on stack in ibm561_cninit(); > it's too early for kmem_alloc(),

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

2020-06-23 Thread Jukka Ruohonen
On Mon, Jun 22, 2020 at 04:14:18PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Mon Jun 22 16:14:18 UTC 2020 > > Modified Files: > src/sys/dev/acpi: acpi.c > > Log Message: > Fix memory leak. Found by kLSan. > + > + default: > +

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

2020-06-07 Thread Nick Hudson
On 10/08/2018 18:11, Taylor R Campbell wrote: Module Name:src Committed By: riastradh Date: Fri Aug 10 17:11:56 UTC 2018 Modified Files: src/sys/dev/acpi: acpi_bat.c Log Message: Don't hold up boot: defer acpibat(4) inquiry until threads are running. ok jmcneill@

Re: [virtio] Re: CVS commit: src/sys/dev/pci

2020-05-31 Thread Maxime Villard
Le 01/06/2020 à 03:23, Shoichi Yamaguchi a écrit : Hi, On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote: I modified virtio(4) not to allocate unused memory. I guess it fixes the issue. Could you check this? I confirmed your closing the report on syzbot.

Re: [virtio] Re: CVS commit: src/sys/dev/pci

2020-05-31 Thread Shoichi Yamaguchi
Hi, On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote: > > I modified virtio(4) not to allocate unused memory. > I guess it fixes the issue. > > Could you check this? I confirmed your closing the report on syzbot.

Re: CVS commit: src/sys/dev

2020-05-30 Thread Alexander Nasonov
Jaromir Dolecek wrote: > Index: src/sys/dev/ic/bwfmvar.h > diff -u src/sys/dev/ic/bwfmvar.h:1.9 src/sys/dev/ic/bwfmvar.h:1.10 > --- src/sys/dev/ic/bwfmvar.h:1.9 Sat May 30 13:41:58 2020 > +++ src/sys/dev/ic/bwfmvar.h Sat May 30 15:55:47 2020 > @@ -1,4 +1,4 @@ > -/* $NetBSD: bwfmvar.h,v 1.9

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

2020-05-30 Thread nia
On Sat, May 30, 2020 at 09:48:36PM +0900, Tetsuya Isaki wrote: > I will do it on next weekend. > > Thanks, > --- > Tetsuya Isaki Thank you.

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

2020-05-30 Thread Tetsuya Isaki
At Fri, 29 May 2020 12:32:39 +, nia wrote: > OK... Can you request a pullup to ensure resuming with a stream > playing doesn't panic on 9.1? I will do it on next weekend. Thanks, --- Tetsuya Isaki

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

2020-05-29 Thread nia
OK... Can you request a pullup to ensure resuming with a stream playing doesn't panic on 9.1? Playing audio is very distorted on resume, but that can be resolved by killing the streams...

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

2020-05-28 Thread Tetsuya Isaki
At Wed, 27 May 2020 13:19:22 +, nia wrote: > I think this is because audio_rmixer_start is used unguarded > in audio_open (it doesn't check for the sc_rbusy flag). > This isn't the case for pmixer. > > So, if the audio device is opened for recording for the > first time after system

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

2020-05-27 Thread Paul Goyette
On Wed, 27 May 2020, Taylor R Campbell wrote: Not really, because we just need to know whether usb_once_init has been run. OK, great! Now, should we use something other than RUN_ONCE, which can both set up and tear down? Sure, that might be better in principle, but there probably aren't

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

2020-05-27 Thread Taylor R Campbell
> Date: Wed, 27 May 2020 05:28:41 -0700 (PDT) > From: Paul Goyette > > Do you also need to decrement the number of busses when one is > detached? Not really, because we just need to know whether usb_once_init has been run. Now, should we use something other than RUN_ONCE, which can both set up

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

2020-05-27 Thread nia
On Wed, May 27, 2020 at 09:46:04PM +0900, Tetsuya Isaki wrote: > Why are playback and recording asymmetric? > > Thanks, I think this is because audio_rmixer_start is used unguarded in audio_open (it doesn't check for the sc_rbusy flag). This isn't the case for pmixer. So, if the audio device

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

2020-05-27 Thread Tetsuya Isaki
nia, At Tue, 26 May 2020 15:20:16 +, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Tue May 26 15:20:16 UTC 2020 > > Modified Files: > src/sys/dev/audio: audio.c > > Log Message: > audio: Only restart recording mixer on resume if it's already been started >

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

2020-05-27 Thread Paul Goyette
Do you also need to decrement the number of busses when one is detached? On Wed, 27 May 2020, Nick Hudson wrote: Module Name:src Committed By: skrll Date: Wed May 27 07:17:45 UTC 2020 Modified Files: src/sys/dev/usb: usb.c Log Message: Don't allow open of /dev/usb if

Re: [virtio] Re: CVS commit: src/sys/dev/pci

2020-05-27 Thread Shoichi Yamaguchi
Hi, On Wed, May 27, 2020 at 2:20 AM Maxime Villard wrote: > > Hi, > I don't know if this is related to your changes, but kMSan detected one uninit > variable in virtio 3h ago: > > https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610 > > [ 153.4370851] panic: MSan:

[virtio] Re: CVS commit: src/sys/dev/pci

2020-05-26 Thread Maxime Villard
Hi, I don't know if this is related to your changes, but kMSan detected one uninit variable in virtio 3h ago: https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610 [ 153.4370851] panic: MSan: Uninitialized Kmem Memory From virtio_pci_setup_interrupts() [

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

2020-05-20 Thread Sevan Janiyan
On 20/05/2020 21:18, Sevan Janiyan wrote: > Bump rcs tag which was missed in r1.9 That should've been r1.10 Sevan

Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread David Brownlee
On Sat, 2 May 2020, 20:10 Jason Thorpe, wrote: > > > On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote: > > > > Hi, > > > > Have you missed this thread? > > > > If the problem requires more time to investigate, > > could you consider to revert ata change for a while? > > > > Thank you. > > I backed

Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread Jason Thorpe
> On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote: > > Hi, > > Have you missed this thread? > > If the problem requires more time to investigate, > could you consider to revert ata change for a while? > > Thank you. I backed it out, but would appreciate some help tracking down the issue

Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-01 Thread Ryo ONODERA
Hi, Have you missed this thread? If the problem requires more time to investigate, could you consider to revert ata change for a while? Thank you. Alexander Nasonov writes: > David Brownlee wrote: >> Just another data point - seeing this same panic on a T480 with the >> latest kernel from

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

2020-05-01 Thread David Brownlee
Plus to confirm reverting just this commit from today's github copy of current (d5b32e03eac8b05d38a143ee0ec615efb2233201) boots fine on the T480 Thanks On Thu, 30 Apr 2020 at 00:12, Alexander Nasonov wrote: > > David Brownlee wrote: > > Just another data point - seeing this same panic on a T480

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

2020-04-29 Thread Alexander Nasonov
David Brownlee wrote: > Just another data point - seeing this same panic on a T480 with the > latest kernel from nyftp Same problem on T470. -- Alex

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

2020-04-29 Thread David Brownlee
Just another data point - seeing this same panic on a T480 with the latest kernel from nyftp

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

2020-04-27 Thread Ryo ONODERA
Ryo ONODERA writes: > Hi, > > After this commit, NetBSD/amd64-current on my HP Spectre x360 > freezes after acpiacad0 detection (before ld0 detection). > Reverting this commit in latest tree fixes my freeze problem. > > Could you take a look at my problem? > > Thank you. > > === === === > cpu7:

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

2020-04-27 Thread Ryo ONODERA
Hi, After this commit, NetBSD/amd64-current on my HP Spectre x360 freezes after acpiacad0 detection (before ld0 detection). Reverting this commit in latest tree fixes my freeze problem. Could you take a look at my problem? Thank you. === === === cpu7: CPU max freq 40 Hz cpu7: TSC freq

[disk changes] CVS commit: src/sys/dev/dkwedge

2020-04-13 Thread Maxime Villard
> Module Name:src > Committed By: jdolecek > Date: Sat Apr 11 16:00:34 UTC 2020 > > Modified Files: > src/sys/dev/dkwedge: dkwedge_apple.c dkwedge_bsdlabel.c dkwedge_gpt.c > dkwedge_mbr.c dkwedge_rdb.c It appears that since your recent changes, there is a

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

2020-04-02 Thread sc dying
On Thu, Apr 2, 2020 at 8:37 PM Nick Hudson wrote: > > Module Name:src > Committed By: skrll > Date: Thu Apr 2 11:37:23 UTC 2020 > > Modified Files: > src/sys/dev/usb: xhci.c xhcivar.h > > Log Message: > Reduce the memory footprint by allocating a ring per endpoint/pipe on

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

2020-03-23 Thread SAITOH Masanobu
On 2020/03/24 12:45, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Tue Mar 24 03:45:26 UTC 2020 > > Modified Files: > src/sys/dev/ic: spdmem.c spdmemvar.h > > Log Message: > - Define some new parameters of DDR3 SPD ROM. > - Use fine timebase parameters

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

2020-03-23 Thread Maxime Villard
Le 23/03/2020 à 04:07, Roy Marples a écrit : > On 22/03/2020 08:30, Maxime Villard wrote: >> Overall "From OpenBSD" is a redflag for buggy and vulnerable code.. > > We should be above this, no software is perfect, not even ours. > > Roy You seem to be confusing one-off defects and structural

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

2020-03-22 Thread Roy Marples
On 22/03/2020 08:30, Maxime Villard wrote: Overall "From OpenBSD" is a redflag for buggy and vulnerable code.. We should be above this, no software is perfect, not even ours. Roy

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

2020-03-22 Thread Maxime Villard
Le 19/03/2020 à 08:49, Pierre Pronchery a écrit : > Module Name: src > Committed By: khorben > Date: Thu Mar 19 07:49:29 UTC 2020 > > Modified Files: > src/sys/dev/usb: if_umb.c > > Log Message: > When there is no network around the state timeout fires over and over again. >

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

2020-03-18 Thread Nick Hudson
On 18/03/2020 11:33, Robert Elz wrote: > Module Name: src > Committed By: kre > Date: Wed Mar 18 11:33:32 UTC 2020 > > Modified Files: > src/sys/dev/usb: if_aue.c > > Log Message: > This was still not correct,. USB_DEBUG is what mattered, not AUE_DEBUG, > the two are orthogonal.

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

2020-03-17 Thread Robert Elz
Date:Tue, 17 Mar 2020 22:58:24 -0400 From:"Christos Zoulas" Message-ID: <20200318025824.93b28f...@cvs.netbsd.org> | Log Message: | define un (pointed out by kre@) The reason I didn't suggest that change, is that now un is unused when USB_DEBUG is not defined.

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

2020-03-14 Thread Christos Zoulas
In article <20200314143238.gr5...@pony.stderr.spb.ru>, Valery Ushakov wrote: >How is is affected by the decision to change (or not) 0x%x to %#x? > This was in response to the statement: ... with a bit of patience might have been less drastic and as effective. christos

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

2020-03-14 Thread Valery Ushakov
On Sat, Mar 14, 2020 at 10:27:27 -0400, Christos Zoulas wrote: > > I don't belive that "if". It's like claiming you got rid of a stain > > on a wallpaper after you demolish a wall (not load-bearing, > > fortunately) and have to put it back and put new wallpaper. :) Get rid > > of the stain,

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

2020-03-14 Thread Christos Zoulas
> I don't belive that "if". It's like claiming you got rid of a stain > on a wallpaper after you demolish a wall (not load-bearing, > fortunately) and have to put it back and put new wallpaper. :) Get rid > of the stain, sure; but may be looking closely with a bit of patience > might have been

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

2020-03-14 Thread Valery Ushakov
On Sat, Mar 14, 2020 at 09:57:36 -0400, Christos Zoulas wrote: > > Even for the ones without the widths specified. E.g. I personally > > prefer zero printed as 0x0, not as 0, so I assume that when people > > choose either one that reflects their preference. Why mess with it? > > It's all so

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

2020-03-14 Thread Christos Zoulas
> Even for the ones without the widths specified. E.g. I personally > prefer zero printed as 0x0, not as 0, so I assume that when people > choose either one that reflects their preference. Why mess with it? > It's all so unnecessary. Yes, now we are discussing cosmetics (if 0 should be printed

re: CVS commit: src/sys/dev/usb

2020-03-14 Thread matthew green
> As I wrote in a follow up email, it changes formatting b/c you didn't > change field widths and IMO using %# with a field width is mostly > trouble to begin with. It's not the first time someone tries to do > this without actually understanding the consequences of the change. > Please, can we

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

2020-03-13 Thread Valery Ushakov
On Fri, Mar 13, 2020 at 22:26:05 -0400, Christos Zoulas wrote: > > On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote: > > > > As I wrote in a follow up email, it changes formatting b/c you didn't > > change field widths and IMO using %# with a field width is mostly > > trouble to begin with.

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

2020-03-13 Thread Christos Zoulas
> On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote: > > As I wrote in a follow up email, it changes formatting b/c you didn't > change field widths and IMO using %# with a field width is mostly > trouble to begin with. It's not the first time someone tries to do > this without actually

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

2020-03-13 Thread Valery Ushakov
On Fri, Mar 13, 2020 at 22:15:31 -0400, Christos Zoulas wrote: > > This was not a part of the PR and is completely cosmetic (surely it > > supports plain %x if it does support %#x). Why was this necessary? > > (I know I would be quite miffed if someone made a change like that to > > my code). >

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

2020-03-13 Thread Christos Zoulas
> This was not a part of the PR and is completely cosmetic (surely it > supports plain %x if it does support %#x). Why was this necessary? > (I know I would be quite miffed if someone made a change like that to > my code). Yes, that %x formatting change was not part of the PR, but I only

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

2020-03-13 Thread Valery Ushakov
On Fri, Mar 13, 2020 at 17:09:14 -0700, Paul Goyette wrote: > On Sat, 14 Mar 2020, Valery Ushakov wrote: > > > On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote: > > > > > Log Message: > > > PR/55068: sc.dying: Fix printf formats: > > [...] > > > - 0x% -> %# > > > > This was not a

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

2020-03-13 Thread Paul Goyette
On Sat, 14 Mar 2020, Valery Ushakov wrote: On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote: Log Message: PR/55068: sc.dying: Fix printf formats: [...] - 0x% -> %# This was not a part of the PR and is completely cosmetic (surely it supports plain %x if it does support %#x).

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

2020-03-13 Thread Valery Ushakov
On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote: > Log Message: > PR/55068: sc.dying: Fix printf formats: [...] > - 0x% -> %# This was not a part of the PR and is completely cosmetic (surely it supports plain %x if it does support %#x). Why was this necessary? (I know I would be

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

2020-03-08 Thread Martin Husemann
On Sun, Mar 08, 2020 at 02:16:00PM -, Christos Zoulas wrote: > >Log Message: > >Use unsigned to avoid undefined behavior. Found by kUBSan. > > I think it is better to add U to all the HUP_ constants for consistency. > It looks funny this way. Yes, please keep it consistent. Martin

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

2020-03-08 Thread Christos Zoulas
In article <20200308140933.1b842f...@cvs.netbsd.org>, SAITOH Masanobu wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: msaitoh >Date: Sun Mar 8 14:09:33 UTC 2020 > >Modified Files: > src/sys/dev/hid: hid.h > >Log Message: >Use unsigned to avoid undefined behavior. Found

Re: CVS commit: src/sys/dev

2020-03-03 Thread Christos Zoulas
Yes, I thought about providing an ioctl to do this, but it would mean that everything that talks to those devices would need to be modified to issue the ioctl. Raw mode means to call the underlying uhidev write which is the raw usb writes instead of using the report mechanism. My devices did not

re: CVS commit: src/sys/dev

2020-03-03 Thread matthew green
Martin Husemann writes: > On Tue, Mar 03, 2020 at 03:26:47PM +1100, matthew green wrote: > > without really understanding, it seems that there should be > > a uhid ioctl to enable this mode, and then your userland code > > sets it, instead of this hack. > > Or make uhid not attach at all on FIDO

Re: CVS commit: src/sys/dev

2020-03-02 Thread Martin Husemann
On Tue, Mar 03, 2020 at 03:26:47PM +1100, matthew green wrote: > without really understanding, it seems that there should be > a uhid ioctl to enable this mode, and then your userland code > sets it, instead of this hack. Or make uhid not attach at all on FIDO devices and instead use ugen from

re: CVS commit: src/sys/dev

2020-03-02 Thread matthew green
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Mon Mar 2 18:15:29 UTC 2020 > > Modified Files: > src/sys/dev/hid: hid.h > src/sys/dev/usb: uhid.c > > Log Message: > Add fido constants, and turn hid "raw" mode for fido devices. this is gross.

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

2020-02-26 Thread Masanobu SAITOH
On 2020/02/27 15:17, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Thu Feb 27 06:17:28 UTC 2020 > > Modified Files: > src/sys/dev/mii: miidevs > > Log Message: > Use xxVIA instead of VIA. > > 0x004063 is VIA's official OUI but VT6103 use 0x0002c6. >

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

2020-02-26 Thread Izumi Tsutsui
> Modified Files: > src/sys/dev/pckbport: synaptics.c > > Log Message: > Messages in pms_synaptics_input() should not start with "pms_input" > > Use "pms_synaptics_input" instead. Maybe it's better to use ("%s", __func__) C99 predefined identifier. --- Izumi Tsutsui

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

2020-01-14 Thread Masanobu SAITOH
On 2020/01/10 15:59, Jason Thorpe wrote: > > >> On Jan 9, 2020, at 9:02 PM, Masanobu SAITOH wrote: >> >> The reason why I moved stge_softc to if_stgereg.h was that ipgphy.c >> required to check stge's chip revision. So, if there is no any objection, >> I'll make new if_stgevar.h and share it

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

2020-01-09 Thread Jason Thorpe
> On Jan 9, 2020, at 9:02 PM, Masanobu SAITOH wrote: > > The reason why I moved stge_softc to if_stgereg.h was that ipgphy.c > required to check stge's chip revision. So, if there is no any objection, > I'll make new if_stgevar.h and share it with if_stge.c and ipgphy.c. That seems fine.

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

2020-01-09 Thread Masanobu SAITOH
On 2020/01/10 13:13, Jason Thorpe wrote: > > >> On Jan 9, 2020, at 6:11 PM, Masanobu SAITOH wrote: >> >> >> Before my change, struct stge_softc is already in if_stgereg.h, >> so I had thought it would be OK to move to it. > > Ah, I don't think I would have put it there when I wrote the driver

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

2020-01-09 Thread Jason Thorpe
> On Jan 9, 2020, at 6:11 PM, Masanobu SAITOH wrote: > > > Before my change, struct stge_softc is already in if_stgereg.h, > so I had thought it would be OK to move to it. Ah, I don't think I would have put it there when I wrote the driver originally, so it must have been moved there at

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

2020-01-09 Thread matthew green
> Two options: > > a) Move some structs (including struct stge_softc) and defines > to if_stge.c > > b) Move them to new if_stgevar.h i've always preferred: - fooreg.h and foovar.h exist only when more than 1 file use them - fooreg.h ONLY has hardware constructs - foovar.h

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

2020-01-09 Thread Masanobu SAITOH
On 2020/01/09 23:08, Jason Thorpe wrote: > > >> On Jan 9, 2020, at 2:54 AM, SAITOH Masanobu wrote: >> >> Module Name: src >> Committed By:msaitoh >> Date:Thu Jan 9 10:54:16 UTC 2020 >> >> Modified Files: >> src/sys/dev/pci: if_stge.c if_stgereg.h >> >> Log Message:

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

2020-01-09 Thread Jason Thorpe
> On Jan 9, 2020, at 2:54 AM, SAITOH Masanobu wrote: > > Module Name: src > Committed By: msaitoh > Date: Thu Jan 9 10:54:16 UTC 2020 > > Modified Files: > src/sys/dev/pci: if_stge.c if_stgereg.h > > Log Message: > Reduce diff against OpenBSD. No functional change. > > -

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

2019-12-24 Thread Ryo ONODERA
Hi, "Jason R Thorpe" writes: > Module Name: src > Committed By: thorpej > Date: Sun Dec 22 16:44:35 UTC 2019 > > Modified Files: > src/sys/dev/i2c: ihidev.c ihidev.h > > Log Message: > The hid-over-i2c spec specifies that compliant devices use level-sensitive > interrupts.

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

2019-12-14 Thread maya
On Tue, Dec 03, 2019 at 05:01:45AM +, Taylor R Campbell wrote: > Module Name: src > Committed By: riastradh > Date: Tue Dec 3 05:01:45 UTC 2019 > > Modified Files: > src/sys/dev/usb: usbnet.c > > Log Message: > Fix order of nulling un->un_pri->unp_ec.ec_mii. > > Can't null

CVS commit: src/sys/dev/onewire

2019-11-30 Thread Andrew Doran
Module Name:src Committed By: ad Date: Sat Nov 30 23:06:52 UTC 2019 Modified Files: src/sys/dev/onewire: owtemp.c Log Message: Make owtemp reliable for me: - Don't do the calculation if there is a CRC error. - If we get any kind of error during a refresh, retry up to

CVS commit: src/sys/dev/onewire

2019-11-30 Thread Andrew Doran
Module Name:src Committed By: ad Date: Sat Nov 30 23:06:52 UTC 2019 Modified Files: src/sys/dev/onewire: owtemp.c Log Message: Make owtemp reliable for me: - Don't do the calculation if there is a CRC error. - If we get any kind of error during a refresh, retry up to

CVS commit: src/sys/dev

2019-11-30 Thread Andrew Doran
Module Name:src Committed By: ad Date: Sat Nov 30 23:04:12 UTC 2019 Modified Files: src/sys/dev/gpio: gpioow.c src/sys/dev/onewire: onewire.c onewire_bitbang.c onewirevar.h Log Message: onewire: - Re-do the signalling to be a little more forgiving and efficient.

CVS commit: src/sys/dev

2019-11-30 Thread Andrew Doran
Module Name:src Committed By: ad Date: Sat Nov 30 23:04:12 UTC 2019 Modified Files: src/sys/dev/gpio: gpioow.c src/sys/dev/onewire: onewire.c onewire_bitbang.c onewirevar.h Log Message: onewire: - Re-do the signalling to be a little more forgiving and efficient.

CVS commit: src/sys/dev/dm

2019-11-29 Thread Tomohiro Kusumi
Module Name:src Committed By: tkusumi Date: Sat Nov 30 05:35:57 UTC 2019 Modified Files: src/sys/dev/dm: dm_ioctl.c Log Message: dm: Always initialize target's status string Explicitly clear status string to prevent dmsetup(8) from printing binary junk to stdout. Similar

CVS commit: src/sys/dev/dm

2019-11-29 Thread Tomohiro Kusumi
Module Name:src Committed By: tkusumi Date: Sat Nov 30 05:35:57 UTC 2019 Modified Files: src/sys/dev/dm: dm_ioctl.c Log Message: dm: Always initialize target's status string Explicitly clear status string to prevent dmsetup(8) from printing binary junk to stdout. Similar

CVS commit: src/sys/dev/pci

2019-11-29 Thread SAITOH Masanobu
Module Name:src Committed By: msaitoh Date: Fri Nov 29 15:17:14 UTC 2019 Modified Files: src/sys/dev/pci: if_mcx.c Log Message: Set if_baudrate. To generate a diff of this commit: cvs rdiff -u -r1.8 -r1.9 src/sys/dev/pci/if_mcx.c Please note that diffs are not public

  1   2   3   4   5   6   7   8   9   10   >