mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Don Dutile <ddutile@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>,
	x86@kernel.org, iommu@lists.linux-foundation.org,
	Greg KH <greg@kroah.com>
Subject: Re: [PATCH v3 0/5] enhance DMA CMA on x86
Date: Wed, 1 Oct 2014 01:45:44 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1410010131380.4455@nanos> (raw)
In-Reply-To: <542ABF77.1020402@hurleysoftware.com>

On Tue, 30 Sep 2014, Peter Hurley wrote:
> I read the UFS Unified Memory Extension v1.0 (JESD220-1) specification and
> it is not clear to me that using DMA mapping is the right approach to
> supporting UM, at least on x86.
> 
> And without a mainline user, the merits of this approach are not evident.
> I cannot even find a production x86 UFS controller, much less one that
> supports UME.
> 
> The only PCI UFS controller I could find (and that mainline supports) is
> Samsung's x86 FPGA-based test unit for developing UFS devices in a x86 test
> environment, and not a production x86 design.

And how is that relevant? That device exists and you have no reason to
deny it to be supported just because you are not interested in it.
 
> Unless there's something else I've missed, I don't think these patches
> belong in mainline.

You missed that there is no reason WHY such a device should not be
supported in mainline.

> Samsung's own roadmap
> (http://www.slideshare.net/linaroorg/next-gen-mobilestorageufs)
> mentions nothing about bringing UFS to x86 designs.

And that's telling you what? 

   - That we should deny Samsung proper support for their obviously
     x86 based test card

   - That we should ignore a JEDEC Standard which is obviously never
     going to hit x86 land just because you decide it?

Your argumentation is just ass backwards. Linux wants to support the
full zoo of hardware including this particular PCI card. Period.

Whether the proposed patchset is the correct solution to support it is
a completely different question.

So either you stop this right now and help Akinobu to find the proper
solution or you just go back in your uncontaminated x86 cave and STFU.

Thanks,

	tglx

  parent reply	other threads:[~2014-09-30 23:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 13:08 Akinobu Mita
2014-04-15 13:08 ` [PATCH v3 1/5] x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled Akinobu Mita
2014-04-16 19:44   ` Andrew Morton
2014-04-17 15:40     ` Akinobu Mita
2014-04-15 13:08 ` [PATCH v3 2/5] x86: enable DMA CMA with swiotlb Akinobu Mita
2014-04-15 13:08 ` [PATCH v3 3/5] intel-iommu: integrate DMA CMA Akinobu Mita
2014-04-15 13:08 ` [PATCH v3 4/5] memblock: introduce memblock_alloc_range() Akinobu Mita
2014-04-15 13:08 ` [PATCH v3 5/5] cma: add placement specifier for "cma=" kernel parameter Akinobu Mita
2014-09-27 14:30 ` [PATCH v3 0/5] enhance DMA CMA on x86 Peter Hurley
2014-09-28  0:31   ` Akinobu Mita
2014-09-29 12:09     ` Peter Hurley
2014-09-29 14:32       ` Akinobu Mita
2014-09-30 14:34         ` Peter Hurley
2014-09-30 23:23           ` Akinobu Mita
2014-09-30 23:45           ` Thomas Gleixner [this message]
2014-09-30 23:49             ` Peter Hurley
2014-10-01  1:49             ` Peter Hurley
2014-10-01  9:05               ` Thomas Gleixner
2014-10-02 16:41               ` Konrad Rzeszutek Wilk
2014-10-02 22:03                 ` Peter Hurley
2014-10-02 23:08                   ` Akinobu Mita
2014-10-03 13:40                     ` Konrad Rzeszutek Wilk
2014-10-03 14:27                     ` Peter Hurley
2014-10-03 16:06                       ` Akinobu Mita
2014-10-03 16:33                         ` konrad wilk
2014-10-03 16:39                         ` Peter Hurley
2014-10-05  6:01                           ` Akinobu Mita

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1410010131380.4455@nanos \
    --to=tglx@linutronix.de \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=ddutile@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=greg@kroah.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mingo@redhat.com \
    --cc=peter@hurleysoftware.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®