linux-kernel - Re: [PATCH 04/15] libnvdimm, nfit, nd_blk: driver for BLK-mode access persistent memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPcyv4hYsq4C70C9+jTH-L38-uVbhwOWjr7SfZpzGnxw7nMoFQ@mail.gmail.com>
Date:	Sun, 21 Jun 2015 07:39:58 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Christoph Hellwig <hch@....de>
Cc:	Jens Axboe <axboe@...nel.dk>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Boaz Harrosh <boaz@...xistor.com>,
	"Kani, Toshimitsu" <toshi.kani@...com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Jens Axboe <axboe@...com>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 04/15] libnvdimm, nfit, nd_blk: driver for BLK-mode access
 persistent memory

On Sun, Jun 21, 2015 at 6:56 AM, Christoph Hellwig <hch@....de> wrote:
> On Sun, Jun 21, 2015 at 06:31:38AM -0700, Dan Williams wrote:
>> > As mentioned last time only arch asm/ headers may include asm-generic
>> > headers.
>>
>> No, not in this case, there's no other way to define readq()/writeq()
>> on 32-bit builds.  See:
>
> Oh my god.  I think we're both right: no driver should use asm-generic,
> but because someone totally messed this abstraction up you have no choice.
>
> We really should have a linux/*.h header for these that just does the
> right thing.
>
> Btw, what's the reason you're using the hi-lo ordering unlikely everyone
> else?  IMHO that should be an arch and not a driver choice.

If the hardware latches the register on writing the hi or lo bits
first then it matters, otherwise it's arbitrary like it is in this
case.  It's hard to have an arch default because different devices
care about different orderings, so it must be a driver choice afaics.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/