Re: [PATCH] treewide: remove duplicate includes

2017-12-03 Thread Luis R. Rodriguez 
On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Unit Testing:
> 
> - build successful
> - LTP testsuite passes.
> - checkpatch.pl passes

Can you get 0day to test it?

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

2018-06-27 Thread Luis R. Rodriguez 
On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote:
> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote:
> 
> > On 7 June 2018 at 20:21, Bjorn Andersson  wrote:
> > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote:
> [..]
> > >>
> > >> Why not just use kmalloc, it will always return a DMAable buffer.
> > >>
> > >
> > > For the buffers being targeted by request_firmware_into_buf() the
> > > problem is that some of them has requirements of physical placement and
> > > they are all too big for kmalloc() (i.e. tens of mb).
> > >
> > >
> > > For the dma_alloc_coherent() buffer that was mentioned earlier, which is
> > > not related to the firmware loading, it's not used because the buffer is
> > > passed to secure world, which temporarily locks Linux out from the
> > > memory region. Traditionally this region was kmalloc'ed downstream, but
> > > due to speculative access violations this code moved to use the DMA
> > > streaming API, although there's no actual DMA going on.
> > >
> > 
> > OK, so you are relying on the fact that dma_alloc_coherent() gives you
> > a device mapping (because the qcom_scm device is described as non
> > cache coherent), but this sounds risky to me. The linear alias of that
> > memory will still be mapped cacheable, and could potentially still be
> > accessed speculatively AFAIK.
> > 
> 
> Yes and we are aware of the risk of having the linear alias present, but
> have yet to find a suitable way to handle this.
> 
> The proposed mechanism was to use reserved-memory and memremap() the
> region while it should be available in Linux,

That's still IO memory, and so it would be up to the specific device if
or not it could access the memory before a full write is done.

> but while this would work
> for some cases (e.g. memory regions for semi-static firmware executed by
> co-processors) it doesn't handle the scenarios where the memory-need is
> dynamic.
> 
> So suggestions are very welcome on how to better handle this.

I *believe* Vlastimil's seems to suggest kvmalloc(), but note that if getting 
the
memory to be contiguous fails, it would fallback to a non-contiguous (vmalloc)
allocation.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

2018-06-27 Thread Luis R. Rodriguez 
On Thu, Jun 28, 2018 at 12:21:47AM +0200, Ard Biesheuvel wrote:
> On 27 June 2018 at 20:00, Luis R. Rodriguez  wrote:
> > On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote:
> >> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote:
> >>
> >> > On 7 June 2018 at 20:21, Bjorn Andersson  
> >> > wrote:
> >> > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote:
> >> [..]
> >> > >>
> >> > >> Why not just use kmalloc, it will always return a DMAable buffer.
> >> > >>
> >> > >
> >> > > For the buffers being targeted by request_firmware_into_buf() the
> >> > > problem is that some of them has requirements of physical placement and
> >> > > they are all too big for kmalloc() (i.e. tens of mb).
> >> > >
> >> > >
> >> > > For the dma_alloc_coherent() buffer that was mentioned earlier, which 
> >> > > is
> >> > > not related to the firmware loading, it's not used because the buffer 
> >> > > is
> >> > > passed to secure world, which temporarily locks Linux out from the
> >> > > memory region. Traditionally this region was kmalloc'ed downstream, but
> >> > > due to speculative access violations this code moved to use the DMA
> >> > > streaming API, although there's no actual DMA going on.
> >> > >
> >> >
> >> > OK, so you are relying on the fact that dma_alloc_coherent() gives you
> >> > a device mapping (because the qcom_scm device is described as non
> >> > cache coherent), but this sounds risky to me. The linear alias of that
> >> > memory will still be mapped cacheable, and could potentially still be
> >> > accessed speculatively AFAIK.
> >> >
> >>
> >> Yes and we are aware of the risk of having the linear alias present, but
> >> have yet to find a suitable way to handle this.
> >>
> >> The proposed mechanism was to use reserved-memory and memremap() the
> >> region while it should be available in Linux,
> >
> > That's still IO memory, and so it would be up to the specific device if
> > or not it could access the memory before a full write is done.
> >
> 
> The risk here is about having aliases with mismatched attributes,
> which may result in loss of coherency and corrupt your data.

That risk is a perhaps a practical risk.

> This is
> not about the risk of loading a file with an invalid signature

This is a theoretical risk LSMs wish to determine and based on information
assess what to do.

> And what do you mean by 'IO memory'? Bus masters that are not behind
> an IOMMU can access all of the kernel's memory all of the time,
> regardless of whether and how it chooses to use it. So from a security
> perspective, there is no distinction, and you can only distinguish
> between before and after informing the device where it can find the
> firmware buffer in memory.

I mean that using memremap() or ioremap() will is designed to give
hardware access to memory for IO purposes, and how writes occur
will vary, and as such we cannot give LSMs guarantees over that
the firmware API will finish a write and that the data provided
really is correct.

> So given that we are dealing here with other masters that can change
> all of your memory behind your back, including the actual code you are
> running that implements the signature check, 

LSMs have the option to trust the kernel, its about context and letting LSMs
decide. They have the right to not trust IO devices to a memory segment, as it
could break guarantees the kernel is making, so this is not about trust or
not, its about *information* and letting LSMs choose.

> I wonder if there is a
> point to obsessing about this use case from a validation point of
> view. The higher privilege level protects itself by doing its own
> signature check, and doing the same at a lower privilege level seems
> redundant to me.

Its up to LSMs to implement the policy.

> >> but while this would work
> >> for some cases (e.g. memory regions for semi-static firmware executed by
> >> co-processors) it doesn't handle the scenarios where the memory-need is
> >> dynamic.
> >>
> >> So suggestions are very welcome on how to better handle this.
> >
> > I *believe* Vlastimil's seems to suggest kvmalloc(), but note that if 
> > getting the
> > memory to be contiguous fails, it would fallback to a non-contiguous 
> > (vmalloc)
> > allocation.

I gave this some though and this obviously is just as good as trying to just use
kmalloc() as that is what is desired, the issue however *ensuring* that the 
allocation
will succeed. The only thing that I can think of there is somehow hinting upon 
boot
to reserve a special allocation for later use. If not at boot, perhaps a hint to
eventually give back the desired contigious allocation, but its beyond me if any
of this is in fact possible.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

2018-06-27 Thread Luis R. Rodriguez 
On Thu, Jun 28, 2018 at 01:42:52AM +0200, Ard Biesheuvel wrote:
> But what point is there to letting LSMs decide that they do not trust
> an I/O device if there is nothing we can do about it? How can we
> prevent such an I/O device from modifying our memory?

Simply LSMs can opt to not trust such setup. Its their choice.
The solution to addressing the concern is orthogonal to their
choice.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

2018-04-25 Thread Luis R. Rodriguez 
On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
> On Tue, 2018-04-24 at 23:42 +0000, Luis R. Rodriguez wrote:
> > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > > > On 23-04-18 23:11, Luis R. Rodriguez wrote:
> > > > > Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need 
> > > > > a new ID
> > > > > and security for this type of request so IMA can reject it if the 
> > > > > policy is
> > > > > configured for it.
> > > > 
> > > > Hmm, interesting, actually it seems like the whole existence
> > > > of READING_FIRMWARE_PREALLOC_BUFFER is a mistake, 
> > 
> > request_firmware_into_buf() was merged without my own review, however,
> > the ID thing did get review from Mimi:
> > 
> > https://patchwork.kernel.org/patch/9074611/
> > 
> > The ID is not for IMA alone, its for any LSM to decide what to do.
> > Note Mimi asked for READING_FIRMWARE_DMA if such buffer was in DMA,
> > otherise READING_FIRMWARE_PREALLOC_BUFFER was suggested.
> > 
> > Mimi why did you want a separate ID for it back before?
> 
> The point of commit a098ecd2fa7d ("firmware: support loading into a
> pre-allocated buffer") is to avoid reading the firmware into kernel
> memory and then copying it "to it's final resting place".  My concern
> is that if the device driver has access to the buffer, it could access
> the buffer prior to the firmware's signature having been verified by
> the kernel.

If request_firmware_into_buf() is used and the firmware was found in
/lib/firmware/ paths then the driver will *not* use the firmware prior
to any LSM doing any firmware signature verification because
kernel_read_file_from_path() and in turn security_kernel_read_file().

The firmware API has a fallback mechanism [0] though, and if that is used then
security_kernel_post_read_file() is used once the firmware is loaded through
the sysfs interface *prior* to handing the firmware data to the driver. As
Hans noted though security_kernel_post_read_file() currently *only* uses
READING_FIRMWARE, so this needs to be fixed. Also note though that LSMs
get a hint of what is going to happen *soon* prior to the fallback
mechanism kicking on as we travere the /lib/firmware/ paths for direct
filesystem loading.

If this is not sufficient to cover LSM appraisals *one* option could be to
have security_kernel_read_file() return a special error of some sort
for READING_FIRMWARE_PREALLOC_BUFFER so that kernel_read_file_from_path()
users could *know* to fatally give up.

Currently the device drivers using request_firmware_into_buf() can end up
getting the buffer with firmware stashed in it without having the kernel do any
firmware signature verification at all through its LSMs. The LSM hooks added to
the firmware loader long ago by Kees via commit 6593d9245bc66 ("firmware_class:
perform new LSM checks") on v3.17 added an LSM for direct filesystem lookups,
but on the fallback mechanism seems to have only added a post LSM hook
security_kernel_fw_from_file().

There is also a custom fallback mechanism [1] which can be used if the path to
the firmware may be out of the /lib/firmware/ paths or perhaps the firmware
requires some very custom fetching of some sort. The only thing this does
though is just *not* issue a uevent when we don't find the firmware and also
sets the timeout to a practically never-ending value. The custom fallback
mechanism is only usable for request_firmware_nowait() though. In retrospect
the custom fallback mechanism is pure crap and these days we've acknowledged
that even in crazy custom firmware fetching cases folks should be able to
accomplish this by relying on uevents and using the firmwared [2] or forking
it, or a different similar proprietary similar solution, which would just
monitor for uevents for firmware and just Do The Right Thing (TM).

Consider some mobile devices which may want to fetch it from some custom
partition which only it can know how to get.

There is a kernel config option which enables the fallback mechanism always,
This is now easily readable as follows:

drivers/base/firmware_loader/fallback_table.c

struct firmware_fallback_config fw_fallback_config = {
.force_sysfs_fallback = 
IS_ENABLED(CONFIG_FW_LOADER_USER_HELPER_FALLBACK),
.loading_timeout = 60,
.old_timeout = 60,
};

Even if this is used we always do direct fs lookups first.

Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.

It would be good for us to hear from Android folks if their current use of
request_firmware_into_buf() is designed in practice to *never* use the direct
filesystem firmware loading interface, and always rely instead on th

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

2018-05-03 Thread Luis R. Rodriguez 
Android folks, poke below. otherwise we'll have no option but to seriously
consider Mimi's patch to prevent these calls when IMA appraisal is enforced:

http://lkml.kernel.org/r/1525182503-13849-7-git-send-email-zo...@linux.vnet.ibm.com

Please read below

On Wed, Apr 25, 2018 at 05:55:57PM +0000, Luis R. Rodriguez wrote:
> On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
> > On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
> > > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > > If its of any help --
> > > 
> > > drivers/soc/qcom/mdt_loader.c is the only driver currently using
> > > request_firmware_into_buf() however I'll note qcom_mdt_load() is used in 
> > > many
> > > other drivers so they are wrappers around request_firmware_into_buf():
> > > 
> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:   * adreno_request_fw() handles 
> > > this, but qcom_mdt_load() does
> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
> > > fw, fwname, GPU_PAS_ID,
> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
> > > fw, newname, GPU_PAS_ID,
> > > drivers/media/platform/qcom/venus/firmware.c:   ret = qcom_mdt_load(dev, 
> > > mdt, fwname, VENUS_PAS_ID, mem_va, mem_phys,
> > > drivers/remoteproc/qcom_adsp_pil.c: return qcom_mdt_load(adsp->dev, 
> > > fw, rproc->firmware, adsp->pas_id,
> > > drivers/remoteproc/qcom_wcnss.c:return qcom_mdt_load(wcnss->dev, 
> > > fw, rproc->firmware, WCNSS_PAS_ID,
> > > 
> > > > > As such the current IMA code (from v4.17-rc2) actually does
> > > > > not handle READING_FIRMWARE_PREALLOC_BUFFER at all, 
> > > > 
> > > > Right, it doesn't yet address READING_FIRMWARE_PREALLOC_BUFFER, but
> > > > should.
> > > > 
> > > > Depending on whether the device requesting the firmware has access to
> > > > the DMA memory, before the signature verification, 
> > > 
> > > It would seem from the original patch review about 
> > > READING_FIRMWARE_PREALLOC_BUFFER
> > > that this is not a DMA buffer.

To be very clear I believe Stephen implied this was not DMA buffer. Mimi
asked for READING_FIRMWARE_DMA if it was:

https://patchwork.kernel.org/patch/9074611/

> > The call sequence:
> > qcom_mdt_load() -> qcom_scm_pas_init_image() -> dma_alloc_coherent()
> > 
> > If dma_alloc_coherent() isn't allocating a DMA buffer, then the
> > function name is misleading/confusing.
> 
> Hah, by *definition* the device *and* processor has immediate access
> to data written *immediately* when dma_alloc_coherent() is used. From
> Documentation/DMA-API.txt:
> 
> ---
> Part Ia - Using large DMA-coherent buffers
>   
> --
>   
>   
>   
> ::
>   
>   
>   
> void *
>   
> dma_alloc_coherent(struct device *dev, size_t size,   
>   
>dma_addr_t *dma_handle, gfp_t flag)
>   
>   
>   
> Consistent memory is memory for which a write by either the device or 
>   
> the processor can immediately be read by the processor or device  
>   
> without having to worry about caching effects.  (You may however need 
>   
> to make sure to flush the processor's write buffers before telling
>   
> devices to read that memory.)  
> 
> 
> Is ptr below
> 
>   ret = request_firmware_into_buf(&seg_fw, fw_name, dev,  
>   ptr, phdr->p_filesz); 
> 
> Also part of the DMA buffer allocated earlier via:
> 
> ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
>   
> 
> Android folks?

Android folks?

> > > The device driver should have access to the buffer pointer with write 
> > > given
> > > t

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

2018-05-08 Thread Luis R. Rodriguez 
On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez  wrote:
> > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
> >
> > It would be good for us to hear from Android folks if their current use of
> > request_firmware_into_buf() is designed in practice to *never* use the 
> > direct
> > filesystem firmware loading interface, and always rely instead on the
> > fallback mechanism.
> 
> It's hard to answer this question for Android in general. As far as I
> can tell the reasons we use CONFIG_FW_LOADER_USER_HELPER(_FALLBACK)
> are:
> 1) We have multiple different paths on our devices where firmware can
> be located, and the direct loader only supports one custom path
> 2) Most of those paths are not mounted by the time the corresponding
> drivers are loaded, because pretty much all Android kernels today are
> built without module support, and therefore drivers are loaded well
> before the firmware partition is mounted
> 3) I think we use _FALLBACK because doing this with uevents is just
> the easiest thing to do; our init code has a firmware helper that
> deals with this and searches the paths that we care about
> 
> 2) will change at some point, because Android is moving towards a
> model where device-specific peripheral drivers will be loaded as
> modules, and since those modules would likely come from the same
> partition as the firmware, it's possible that the direct load would
> succeed (depending on whether the custom path is configured there or
> not). But I don't think we can rely on the direct loader even in those
> cases, unless we could configure it with multiple custom paths.
> 
> I have no reason to believe request_firmware_into_buf() is special in
> this regard; drivers that depend on it may have their corresponding
> firmware in different locations, so just depending on the direct
> loader would not be good enough.

Thanks! This is very useful! This provides yet-another justification and use
case to document for the fallback mechanism. I'll go and extend it.

> >
> > Is ptr below
> >
> > ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
> > ptr, phdr->p_filesz);
> >
> > Also part of the DMA buffer allocated earlier via:
> >
> > ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
> >
> > Android folks?
> 
> I think the Qualcomm folks owning this (Andy, David, Bjorn, already
> cc'd here) are better suited to answer that question.

Andy, David, Bjorn?

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

2018-05-08 Thread Luis R. Rodriguez 
On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez  
> > wrote:
> > > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
> > >
> > > It would be good for us to hear from Android folks if their current use of
> > > request_firmware_into_buf() is designed in practice to *never* use the 
> > > direct
> > > filesystem firmware loading interface, and always rely instead on the
> > > fallback mechanism.
> > 
> > It's hard to answer this question for Android in general. As far as I
> > can tell the reasons we use CONFIG_FW_LOADER_USER_HELPER(_FALLBACK)
> > are:
> > 1) We have multiple different paths on our devices where firmware can
> > be located, and the direct loader only supports one custom path

FWIW I'd love to consider patches to address this, if this is something
you may find a need for in the future to *avoid* the fallback, however
would like a clean solution.

> > 2) Most of those paths are not mounted by the time the corresponding
> > drivers are loaded, because pretty much all Android kernels today are
> > built without module support, and therefore drivers are loaded well
> > before the firmware partition is mounted

I've given this some more thought and you can address this with initramfs,
this is how other Linux distributions are addressing this. One way to
address this automatically is to scrape the drivers built-in or needed early on
boot in initamfs and if the driver has a MODULE_FIRMWARE() its respective
firmware is added to initramfs as well.

If you *don't* use initramfs, then yes you can obviously run into issues
where your firmware may not be accessible if the driver is somehow loaded
early.

> > 3) I think we use _FALLBACK because doing this with uevents is just
> > the easiest thing to do; our init code has a firmware helper that
> > deals with this and searches the paths that we care about
> > 
> > 2) will change at some point, because Android is moving towards a
> > model where device-specific peripheral drivers will be loaded as
> > modules, and since those modules would likely come from the same
> > partition as the firmware, it's possible that the direct load would
> > succeed (depending on whether the custom path is configured there or
> > not). But I don't think we can rely on the direct loader even in those
> > cases, unless we could configure it with multiple custom paths.

Using initramfs will help, but because of the custom path needs -- you're
right, we don't have anything for that yet, its also a bit unclear if
something nice and clean can be drawn up for it. So perhaps dealing with
the fallback mechanism is the way to go for this for sure, since we already
have support for it.

Just keep in mind that the fallback mechanism costs you about ~13436 bytes.

So, if someone comes up with a clean interface for custom paths I'd love
to consider it to avoid those 13436 bytes.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

2018-06-01 Thread Luis R. Rodriguez 
On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez  
> > wrote:
> > > Is ptr below
> > >
> > > ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
> > > ptr, phdr->p_filesz);
> > >
> > > Also part of the DMA buffer allocated earlier via:
> > >
> > > ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
> > >
> > > Android folks?
> > 
> > I think the Qualcomm folks owning this (Andy, David, Bjorn, already
> > cc'd here) are better suited to answer that question.
> 
> Andy, David, Bjorn?

Andy, David, Bjorn?

Note: as-is we have no option but to assume this is DMA memory for now.
We cannot keep IMA's guarantees with the current prealloc firmware API
buffer, so I've suggested:

a) The prealloc buffer API be expanded to enable the caller to descrbe it
b) Have the qcom driver say this is DMA
c) IMA would reject it to ensure it stays true to what it needs to gaurantee

d) Future platforms which want to use IMA but want to trust DMA buffers
   would need to devise a way to describe IMA can trust some of these
   calls.

I'll leave it up to you guys (Andy, David, Bjorn) to come up with the code for
d) once and if you guys want to use IMA later.  But since what is pressing here
is to stay to true to IMA, with a-c IMA would reject such calls for now.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

2018-06-06 Thread Luis R. Rodriguez 
On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote:
> On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote:
> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > > 
> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already
> > > cc'd here) are better suited to answer that question.
> > 
> > Andy, David, Bjorn?
> 
> Andy, David, Bjorn?

A month now with no answer...

Perhaps someone who has this hardware can find out empirically for us, as
follows (mm folks is this right?):

page = virt_to_page(address);
if (!page)
   fail closed...
if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32)
this is a DMA buffer
else
not DMA!

Note that when request_firmware_into_buf() was being reviewed Mimi had asked 
back
in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA 
should be
used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine.

If it is a DMA buffer *now*, why / how did this change?

[0] https://patchwork.kernel.org/patch/9074611/

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

2018-06-06 Thread Luis R. Rodriguez 
On Wed, Jun 06, 2018 at 10:41:07PM +0200, Ard Biesheuvel wrote:
> On 6 June 2018 at 22:32, Luis R. Rodriguez  wrote:
> > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote:
> >> On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> >> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> >> > >
> >> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already
> >> > > cc'd here) are better suited to answer that question.
> >> >
> >> > Andy, David, Bjorn?
> >>
> >> Andy, David, Bjorn?
> >
> > A month now with no answer...
> >
> > Perhaps someone who has this hardware can find out empirically for us, as
> > follows (mm folks is this right?):
> >
> > page = virt_to_page(address);
> > if (!page)
> >fail closed...
> > if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32)
> > this is a DMA buffer
> > else
> > not DMA!
> >
> 
> As I replied in the other thread, this code makes no sense.

OK thanks. If we can't figure it out in code we will have no option
but to expect the worst, specially considering the silence.

> In general, any address covered by the kernel direct mapping can be
> passed to the streaming DMA api and be mapped for device read xor
> device write.

Right, thanks for the details -- on the other thread [0] you've clarified
that with streaming DMA API the CPU *should not* use the buffer and so
*should *be "safe", however that's still a judgement and design call.

[0] https://lkml.kernel.org/r/20180606220605.gj4...@wotan.suse.de

> Only DMA mappings that will be accessed randomly by the
> device and the CPU at the same time require the use of
> dma_alloc_coherent(), so it can take special precautions (e.g, create
> an uncached mapping if DMA is non cache coherent)

Right and the qcom drivers *does not* use the streaming DMA API, it uses
use dma_alloc_coherent() which explicitly allows the CPU to *immediately*
have access the buffer. We have no control over the CPU and have no ways
to vet that the data we give is complete and correct.

> The DMA zone thing is primarily about reserving low memory ranges for
> DMA because some hardware may not have sufficient address lines wired
> up to access all of DRAM.

Right.

The point to all this is that it is up to LSMs to decide and trust something,
and in this case, even with the streaming DMA API in mind, it is up to LSMs
to decide. In this case we have only *one* user of request_firmware_into_buf()
and code inspection is finding that very likely the dma_alloc_coherent() calls
on the path is actually using this same coherent DMA buffer for firmware.

> > Note that when request_firmware_into_buf() was being reviewed Mimi had 
> > asked back
> > in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA 
> > should be
> > used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine.
> >
> > If it is a DMA buffer *now*, why / how did this change?
> >
> > [0] https://patchwork.kernel.org/patch/9074611/

So it is *specially* very odd and disappointing that even though Mimi
*specifically* asked a long time ago that if a DMA buffer would be used it
should be annotated as such with READING_FIRMWARE_DMA, why the annotation
continued forward with READING_FIRMWARE_PREALLOC_BUFFER instead.

Just as Mimi asked for READING_FIRMWARE_DMA it would seem we could reasonably 
also
ask now or READING_FIRMWARE_DMA_COHERENT and READING_FIRMWARE_DMA_STREAM and 
some
LSMs will just reject these calls. We don't need READING_FIRMWARE_DMA_STREAM now
as request_firmware_into_buf() users are using dma_alloc_coherent() so we are
trying to determine if request_firmware_into_buf() should pass:

READING_FIRMWARE_DMA_COHERENT

Given no one is providing a clear answer, and we cannot easily describe the
buffer at run time we'll just move forward with READING_FIRMWARE_DMA_COHERENT.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

2018-06-06 Thread Luis R. Rodriguez 
On Thu, Jun 07, 2018 at 12:41:12AM +0200, Ard Biesheuvel wrote:
> On 7 June 2018 at 00:29, Luis R. Rodriguez  wrote:
> > Given no one is providing a clear answer, and we cannot easily describe the
> > buffer at run time we'll just move forward with 
> > READING_FIRMWARE_DMA_COHERENT.
> 
> I seriously wonder whether the QCOM code cannot switch to the
> streaming API instead. That is generally preferred anyway (for
> performance, although that should not matter for loading firmware) but
> also removes this single wart for which we have to invent new flags
> and new security code plus the associated validation overhead.

Given 1 month and no response I don't think we can count on that at this point.

  Luis

-- 
Do not panic
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

2018-06-07 Thread Luis R. Rodriguez 
On Thu, Jun 07, 2018 at 09:49:50AM -0700, Bjorn Andersson wrote:
> On Tue 08 May 09:10 PDT 2018, Luis R. Rodriguez wrote:
> 
> > On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote:
> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > > > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez  
> > > > wrote:
> [..]
> > > > 2) Most of those paths are not mounted by the time the corresponding
> > > > drivers are loaded, because pretty much all Android kernels today are
> > > > built without module support, and therefore drivers are loaded well
> > > > before the firmware partition is mounted
> > 
> > I've given this some more thought and you can address this with initramfs,
> > this is how other Linux distributions are addressing this. One way to
> > address this automatically is to scrape the drivers built-in or needed 
> > early on
> > boot in initamfs and if the driver has a MODULE_FIRMWARE() its respective
> > firmware is added to initramfs as well.
> > 
> 
> That could be done, but it would not change the fact that the
> /sys/class/firmware is ABI and you may not break it.

Right, this is now well documented and also the latest changes to the firmware
API have made the sysfs fallback loader an option through a sysctl knob. The
code should be much easier to follow and test now.

> And it doesn't change the fact that the ramdisk would have to be over
> 100mb to facilitate this.

Indeed, this is now acknowledged in the latest Kconfig for the firmware loader.

> > If you *don't* use initramfs, then yes you can obviously run into issues
> > where your firmware may not be accessible if the driver is somehow loaded
> > early.
> > 
> 
> This is still a problem that lacks a solution.

The firmwared solution capturing uevents and using the sysfs fallback
mechanism should resolve this. Its also now properly documented on the
firmware loader Kconfig.

> > > > 3) I think we use _FALLBACK because doing this with uevents is just
> > > > the easiest thing to do; our init code has a firmware helper that
> > > > deals with this and searches the paths that we care about
> > > > 
> > > > 2) will change at some point, because Android is moving towards a
> > > > model where device-specific peripheral drivers will be loaded as
> > > > modules, and since those modules would likely come from the same
> > > > partition as the firmware, it's possible that the direct load would
> > > > succeed (depending on whether the custom path is configured there or
> > > > not). But I don't think we can rely on the direct loader even in those
> > > > cases, unless we could configure it with multiple custom paths.
> > 
> > Using initramfs will help, but because of the custom path needs -- you're
> > right, we don't have anything for that yet, its also a bit unclear if
> > something nice and clean can be drawn up for it. So perhaps dealing with
> > the fallback mechanism is the way to go for this for sure, since we already
> > have support for it.
> > 
> > Just keep in mind that the fallback mechanism costs you about ~13436 bytes.
> > 
> 
> Remember that putting the firmware in the ramdisk would cost about
> 1x (yes, ten thousand times) more ram.

Indeed, this is now documented on the Kconfig too.

> > So, if someone comes up with a clean interface for custom paths I'd love
> > to consider it to avoid those 13436 bytes.
> > 
> 
> Combined with a way of synchronizing this with the availability of the
> firmware, this would be a nice thing!

The firmwared solution seems to be the way to go for now.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

2018-06-18 Thread Luis R. Rodriguez 
On Thu, Jun 07, 2018 at 11:06:11AM -0700, Bjorn Andersson wrote:
> On Thu 07 Jun 09:23 PDT 2018, Ard Biesheuvel wrote:
> 
> > On 7 June 2018 at 18:18, Bjorn Andersson  wrote:
> > > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote:
> > >
> > >> On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote:
> > >> > On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> > >> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > >> > > >
> > >> > > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already
> > >> > > > cc'd here) are better suited to answer that question.
> > >> > >
> > >> > > Andy, David, Bjorn?
> > >> >
> > >> > Andy, David, Bjorn?
> > >>
> > >> A month now with no answer...
>
> So it's this memremap() region that we pass to
> request_firmware_into_buf() currently, the previously mentioned
> dma_alloc_coherent() region is used as we invoke the secure world
> operation to set up the firmware authentication.

memremap() is for IO memory, and in that sense it is also not much different
from DMA memory in terms of the concerns Mimi has for LSMs and what guarantees
LSMs can make to users.

Regardless of the device, once you write certain data to the IO memory we cannot
be sure the device will wait for all IO to be written, this will be device 
specific.

As such I would suggest READING_IOMEM for this case have 
request_firmware_into_buf()
use it.

With that said, since we have only one user of this caller, a future rename
to reflect its current actual use would be good. The rename can wait though.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()

2015-04-21 Thread Luis R. Rodriguez 
From: "Luis R. Rodriguez" 

The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Sudip Mukherjee 
Cc: Teddy Wang 
Cc: Greg Kroah-Hartman 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: de...@driverdev.osuosl.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/staging/sm750fb/sm750.c| 36 
 drivers/staging/sm750fb/sm750.h|  3 ---
 drivers/staging/sm750fb/sm750_hw.c |  3 +--
 3 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 3c7ea95..cf57e3e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -16,9 +16,6 @@
 #include
 #include
 #include 
-#ifdef CONFIG_MTRR
-#include 
-#endif
 #include 
 #include "sm750.h"
 #include "sm750_hw.h"
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*, struct 
pci_dev*);
 /* common var for all device */
 static int g_hwcursor = 1;
 static int g_noaccel;
-#ifdef CONFIG_MTRR
 static int g_nomtrr;
-#endif
 static const char *g_fbmode[] = {NULL, NULL};
 static const char *g_def_fbmode = "800x600-16@60";
 static char *g_settings = NULL;
@@ -1126,11 +1121,8 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
 
pr_info("share->revid = %02x\n", share->revid);
share->pdev = pdev;
-#ifdef CONFIG_MTRR
share->mtrr_off = g_nomtrr;
share->mtrr.vram = 0;
-   share->mtrr.vram_added = 0;
-#endif
share->accel_off = g_noaccel;
share->dual = g_dualview;
spin_lock_init(&share->slock);
@@ -1158,22 +1150,9 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
goto err_map;
}
 
-#ifdef CONFIG_MTRR
-   if (!share->mtrr_off) {
-   pr_info("enable mtrr\n");
-   share->mtrr.vram = mtrr_add(share->vidmem_start,
-   share->vidmem_size,
-   MTRR_TYPE_WRCOMB, 1);
-
-   if (share->mtrr.vram < 0) {
-   /* don't block driver with the failure of MTRR */
-   pr_err("Unable to setup MTRR.\n");
-   } else {
-   share->mtrr.vram_added = 1;
-   pr_info("MTRR added succesfully\n");
-   }
-   }
-#endif
+   if (!share->mtrr_off)
+   share->mtrr.vram = arch_phys_wc_add(share->vidmem_start,
+   share->vidmem_si

[PATCH v3] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()

2015-04-21 Thread Luis R. Rodriguez 
From: "Luis R. Rodriguez" 

The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Sudip Mukherjee 
Cc: Teddy Wang 
Cc: Greg Kroah-Hartman 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: de...@driverdev.osuosl.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/staging/sm750fb/sm750.c| 36 
 drivers/staging/sm750fb/sm750.h|  3 ---
 drivers/staging/sm750fb/sm750_hw.c |  3 +--
 3 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 3c7ea95..cf57e3e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -16,9 +16,6 @@
 #include
 #include
 #include 
-#ifdef CONFIG_MTRR
-#include 
-#endif
 #include 
 #include "sm750.h"
 #include "sm750_hw.h"
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*, struct 
pci_dev*);
 /* common var for all device */
 static int g_hwcursor = 1;
 static int g_noaccel;
-#ifdef CONFIG_MTRR
 static int g_nomtrr;
-#endif
 static const char *g_fbmode[] = {NULL, NULL};
 static const char *g_def_fbmode = "800x600-16@60";
 static char *g_settings = NULL;
@@ -1126,11 +1121,8 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
 
pr_info("share->revid = %02x\n", share->revid);
share->pdev = pdev;
-#ifdef CONFIG_MTRR
share->mtrr_off = g_nomtrr;
share->mtrr.vram = 0;
-   share->mtrr.vram_added = 0;
-#endif
share->accel_off = g_noaccel;
share->dual = g_dualview;
spin_lock_init(&share->slock);
@@ -1158,22 +1150,9 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
goto err_map;
}
 
-#ifdef CONFIG_MTRR
-   if (!share->mtrr_off) {
-   pr_info("enable mtrr\n");
-   share->mtrr.vram = mtrr_add(share->vidmem_start,
-   share->vidmem_size,
-   MTRR_TYPE_WRCOMB, 1);
-
-   if (share->mtrr.vram < 0) {
-   /* don't block driver with the failure of MTRR */
-   pr_err("Unable to setup MTRR.\n");
-   } else {
-   share->mtrr.vram_added = 1;
-   pr_info("MTRR added succesfully\n");
-   }
-   }
-#endif
+   if (!share->mtrr_off)
+   share->mtrr.vram = arch_phys_wc_add(share->vidmem_start,
+   share->vidmem_si

Re: [PATCH v3] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()

2015-04-30 Thread Luis R. Rodriguez 
On Tue, Apr 21, 2015 at 1:13 PM, Luis R. Rodriguez
 wrote:
> From: "Luis R. Rodriguez" 
>
> The same area used for ioremap() is used for the MTRR area.
> Convert the driver from using the x86 specific MTRR code to
> the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
> will avoid MTRR if write-combining is available, in order to
> take advantage of that also ensure the ioremap'd area is requested
> as write-combining.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
>x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>de33c442e titled "x86 PAT: fix performance drop for glx,
>use UC minus for ioremap(), ioremap_nocache() and
>pci_mmap_page_range()")
>
> The conversion done is expressed by the following Coccinelle
> SmPL patch, it additionally required manual intervention to
> address all the #ifdery and removal of redundant things which
> arch_phys_wc_add() already addresses such as verbose message
> about when MTRR fails and doing nothing when we didn't get
> an MTRR.
>
> @ mtrr_found @
> expression index, base, size;
> @@
>
> -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> +index = arch_phys_wc_add(base, size);
>
> @ mtrr_rm depends on mtrr_found @
> expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> @@
>
> -mtrr_del(index, base, size);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_zero_arg depends on mtrr_found @
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, 0, 0);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_fb_info depends on mtrr_found @
> struct fb_info *info;
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> +arch_phys_wc_del(index);
>
> @ ioremap_replace_nocache depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap_nocache(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> @ ioremap_replace_default depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> Generated-by: Coccinelle SmPL
> Cc: Sudip Mukherjee 
> Cc: Teddy Wang 
> Cc: Greg Kroah-Hartman 
> Cc: Suresh Siddha 
> Cc: Ingo Molnar 
> Cc: Thomas Gleixner 
> Cc: Juergen Gross 
> Cc: Daniel Vetter 
> Cc: Andy Lutomirski 
> Cc: Dave Airlie 
> Cc: Antonino Daplas 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: de...@driverdev.osuosl.org
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez 

Hey folks, just a follow up. Can this be considered to be merged?

 Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()

2015-05-04 Thread Luis R. Rodriguez 
On Sun, May 03, 2015 at 09:24:59PM +0200, Greg KH wrote:
> On Tue, Apr 21, 2015 at 01:12:03PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" 
> > 
> > The same area used for ioremap() is used for the MTRR area.
> > Convert the driver from using the x86 specific MTRR code to
> > the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
> > will avoid MTRR if write-combining is available, in order to
> > take advantage of that also ensure the ioremap'd area is requested
> > as write-combining.
> > 
> > There are a few motivations for this:
> > 
> > a) Take advantage of PAT when available
> > 
> > b) Help bury MTRR code away, MTRR is architecture specific and on
> >x86 its replaced by PAT
> > 
> > c) Help with the goal of eventually using _PAGE_CACHE_UC over
> >_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> >de33c442e titled "x86 PAT: fix performance drop for glx,
> >use UC minus for ioremap(), ioremap_nocache() and
> >pci_mmap_page_range()")
> > 
> > The conversion done is expressed by the following Coccinelle
> > SmPL patch, it additionally required manual intervention to
> > address all the #ifdery and removal of redundant things which
> > arch_phys_wc_add() already addresses such as verbose message
> > about when MTRR fails and doing nothing when we didn't get
> > an MTRR.
> > 
> > @ mtrr_found @
> > expression index, base, size;
> > @@
> > 
> > -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> > +index = arch_phys_wc_add(base, size);
> > 
> > @ mtrr_rm depends on mtrr_found @
> > expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> > @@
> > 
> > -mtrr_del(index, base, size);
> > +arch_phys_wc_del(index);
> > 
> > @ mtrr_rm_zero_arg depends on mtrr_found @
> > expression mtrr_found.index;
> > @@
> > 
> > -mtrr_del(index, 0, 0);
> > +arch_phys_wc_del(index);
> > 
> > @ mtrr_rm_fb_info depends on mtrr_found @
> > struct fb_info *info;
> > expression mtrr_found.index;
> > @@
> > 
> > -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> > +arch_phys_wc_del(index);
> > 
> > @ ioremap_replace_nocache depends on mtrr_found @
> > struct fb_info *info;
> > expression base, size;
> > @@
> > 
> > -info->screen_base = ioremap_nocache(base, size);
> > +info->screen_base = ioremap_wc(base, size);
> > 
> > @ ioremap_replace_default depends on mtrr_found @
> > struct fb_info *info;
> > expression base, size;
> > @@
> > 
> > -info->screen_base = ioremap(base, size);
> > +info->screen_base = ioremap_wc(base, size);
> > 
> > Generated-by: Coccinelle SmPL
> > Cc: Sudip Mukherjee 
> > Cc: Teddy Wang 
> > Cc: Greg Kroah-Hartman 
> > Cc: Suresh Siddha 
> > Cc: Ingo Molnar 
> > Cc: Thomas Gleixner 
> > Cc: Juergen Gross 
> > Cc: Daniel Vetter 
> > Cc: Andy Lutomirski 
> > Cc: Dave Airlie 
> > Cc: Antonino Daplas 
> > Cc: Jean-Christophe Plagniol-Villard 
> > Cc: Tomi Valkeinen 
> > Cc: de...@driverdev.osuosl.org
> > Cc: linux-fb...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  drivers/staging/sm750fb/sm750.c| 36 
> > 
> >  drivers/staging/sm750fb/sm750.h|  3 ---
> >  drivers/staging/sm750fb/sm750_hw.c |  3 +--
> >  3 files changed, 5 insertions(+), 37 deletions(-)
> 
> This doesn't apply to my staging-next branch :(

OK I'll resend a v4 now.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v4] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()

2015-05-04 Thread Luis R. Rodriguez 
From: "Luis R. Rodriguez" 

The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Sudip Mukherjee 
Cc: Teddy Wang 
Cc: Greg Kroah-Hartman 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: de...@driverdev.osuosl.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/staging/sm750fb/sm750.c| 36 
 drivers/staging/sm750fb/sm750.h|  3 ---
 drivers/staging/sm750fb/sm750_hw.c |  3 +--
 3 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 3c7ea95..cf57e3e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -16,9 +16,6 @@
 #include
 #include
 #include 
-#ifdef CONFIG_MTRR
-#include 
-#endif
 #include 
 #include "sm750.h"
 #include "sm750_hw.h"
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*, struct 
pci_dev*);
 /* common var for all device */
 static int g_hwcursor = 1;
 static int g_noaccel;
-#ifdef CONFIG_MTRR
 static int g_nomtrr;
-#endif
 static const char *g_fbmode[] = {NULL, NULL};
 static const char *g_def_fbmode = "800x600-16@60";
 static char *g_settings = NULL;
@@ -1126,11 +1121,8 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
 
pr_info("share->revid = %02x\n", share->revid);
share->pdev = pdev;
-#ifdef CONFIG_MTRR
share->mtrr_off = g_nomtrr;
share->mtrr.vram = 0;
-   share->mtrr.vram_added = 0;
-#endif
share->accel_off = g_noaccel;
share->dual = g_dualview;
spin_lock_init(&share->slock);
@@ -1158,22 +1150,9 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
goto err_map;
}
 
-#ifdef CONFIG_MTRR
-   if (!share->mtrr_off) {
-   pr_info("enable mtrr\n");
-   share->mtrr.vram = mtrr_add(share->vidmem_start,
-   share->vidmem_size,
-   MTRR_TYPE_WRCOMB, 1);
-
-   if (share->mtrr.vram < 0) {
-   /* don't block driver with the failure of MTRR */
-   pr_err("Unable to setup MTRR.\n");
-   } else {
-   share->mtrr.vram_added = 1;
-   pr_info("MTRR added succesfully\n");
-   }
-   }
-#endif
+   if (!share->mtrr_off)
+   share->mtrr.vram = arch_phys_wc_add(share->vidmem_start,
+   share->vidmem_si

Re: [PATCH v4] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()

2015-05-14 Thread Luis R. Rodriguez 
On Sun, May 10, 2015 at 03:09:03PM +0200, Greg KH wrote:
> On Mon, May 04, 2015 at 05:15:51PM -0700, Luis R. Rodriguez wrote:
> > ---
> >  drivers/staging/sm750fb/sm750.c| 36 
> > 
> >  drivers/staging/sm750fb/sm750.h|  3 ---
> >  drivers/staging/sm750fb/sm750_hw.c |  3 +--
> >  3 files changed, 5 insertions(+), 37 deletions(-)
> 
> Still doesn't apply to my tree:

I did base it on that day's staging tree, staging is just a fast
moving tree. In the future use of SmPL, when provided, to address merge
conflicts might help us on git.

Meanwhile I've addressed the conflict and will send v5 based on today's
tree outlook.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()

2015-05-14 Thread Luis R. Rodriguez 
From: "Luis R. Rodriguez" 

The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Sudip Mukherjee 
Cc: Teddy Wang 
Cc: Greg Kroah-Hartman 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: de...@driverdev.osuosl.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/staging/sm750fb/sm750.c| 36 
 drivers/staging/sm750fb/sm750.h|  3 ---
 drivers/staging/sm750fb/sm750_hw.c |  3 +--
 3 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 5529905..97fe04a 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -16,9 +16,6 @@
 #include
 #include
 #include 
-#ifdef CONFIG_MTRR
-#include 
-#endif
 #include 
 #include "sm750.h"
 #include "sm750_hw.h"
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*, struct 
pci_dev*);
 /* common var for all device */
 static int g_hwcursor = 1;
 static int g_noaccel;
-#ifdef CONFIG_MTRR
 static int g_nomtrr;
-#endif
 static const char *g_fbmode[] = {NULL, NULL};
 static const char *g_def_fbmode = "800x600-16@60";
 static char *g_settings = NULL;
@@ -1126,11 +1121,8 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
 
pr_info("share->revid = %02x\n", share->revid);
share->pdev = pdev;
-#ifdef CONFIG_MTRR
share->mtrr_off = g_nomtrr;
share->mtrr.vram = 0;
-   share->mtrr.vram_added = 0;
-#endif
share->accel_off = g_noaccel;
share->dual = g_dualview;
spin_lock_init(&share->slock);
@@ -1158,22 +1150,9 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
goto err_map;
}
 
-#ifdef CONFIG_MTRR
-   if (!share->mtrr_off) {
-   pr_info("enable mtrr\n");
-   share->mtrr.vram = mtrr_add(share->vidmem_start,
-   share->vidmem_size,
-   MTRR_TYPE_WRCOMB, 1);
-
-   if (share->mtrr.vram < 0) {
-   /* don't block driver with the failure of MTRR */
-   pr_err("Unable to setup MTRR.\n");
-   } else {
-   share->mtrr.vram_added = 1;
-   pr_info("MTRR added successfully\n");
-   }
-   }
-#endif
+   if (!share->mtrr_off)
+   share->mtrr.vram = arch_phys_wc_add(share->vidmem_start,
+   share->vidmem_size);
 
memset_io(share-

[PATCH REPOST] staging: xgifb: use arch_phys_wc_add() and ioremap_wc()

2015-05-28 Thread Luis R. Rodriguez 
From: "Luis R. Rodriguez" 

The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Arnaud Patard 
Cc: Greg Kroah-Hartman 
Cc: Aaro Koskinen 
Cc: Brian Vandre 
Cc: Thomas Gummerer 
Cc: Aya Mahfouz 
Cc: Lubomir Rintel 
Cc: Vitor Braga 
Cc: Sudip Mukherjee 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: de...@driverdev.osuosl.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---

Greg, this is a respost from my March 20th submission which seems
to have fallen through the cracks likely due to me not directing it
to you. Apologies for that. This repost goes unchanged and is rebased
on top of linux-next next-20150528.

 drivers/staging/xgifb/XGI_main_26.c | 27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/xgifb/XGI_main_26.c 
b/drivers/staging/xgifb/XGI_main_26.c
index 74e8820..943d463 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -8,10 +8,7 @@
 
 #include 
 #include 
-
-#ifdef CONFIG_MTRR
-#include 
-#endif
+#include 
 
 #include "XGI_main.h"
 #include "vb_init.h"
@@ -1770,7 +1767,7 @@ static int xgifb_probe(struct pci_dev *pdev,
}
 
xgifb_info->video_vbase = hw_info->pjVideoMemoryAddress =
-   ioremap(xgifb_info->video_base, xgifb_info->video_size);
+   ioremap_wc(xgifb_info->video_base, xgifb_info->video_size);
xgifb_info->mmio_vbase = ioremap(xgifb_info->mmio_base,
xgifb_info->mmio_size);
 
@@ -2014,12 +2011,8 @@ static int xgifb_probe(struct pci_dev *pdev,
 
fb_alloc_cmap(&fb_info->cmap, 256, 0);
 
-#ifdef CONFIG_MTRR
-   xgifb_info->mtrr = mtrr_add(xgifb_info->video_base,
-   xgifb_info->video_size, MTRR_TYPE_WRCOMB, 1);
-   if (xgifb_info->mtrr >= 0)
-   dev_info(&pdev->dev, "Added MTRR\n");
-#endif
+   xgifb_info->mtrr = arch_phys_wc_add(xgifb_info->video_base,
+   xgifb_info->video_size);
 
if (register_framebuffer(fb_info) < 0) {
ret = -EINVAL;
@@ -2031,11 +2024,7 @@ static int xgifb_probe(struct pci_dev *pdev,
return 0;
 
 error_mtrr:
-#ifdef CONFIG_MTRR
-   if (xgifb_info->mtrr >= 0)
-   mtrr_del(xgifb_info->mtrr, xgifb_info->video_base,
-   xgifb_info->video_size);
-#endif /* CONFIG_MTRR */
+   arch_phys_wc_del(xgifb_info->mtrr);
 error_1:
iounmap(xgifb_info->mmio_vbase);
iounmap(xgifb_info->video_vbase);
@@ -2059,11 +2048,7 @@ stati

[PATCH 0/2] wireless: move prism54 to staging

2017-08-03 Thread Luis R. Rodriguez 
Kalle, Greg,

This moves the prism54 diver to staging. The reason for this are
stated on the driver's own commit log. Let me know what tree you'd
prefer this to go through.

Luis R. Rodriguez (2):
  wireless: move prism54 out to staging
  MAINTAINERS: update email address for mcgrof for few straggling
drivers

 MAINTAINERS  |  8 
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 21 files changed, 7 insertions(+), 25 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] MAINTAINERS: update email address for mcgrof for few straggling drivers

2017-08-03 Thread Luis R. Rodriguez 
This will ensure I get emails on my work and personal email address.

Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 97cf436e6750..49ae596584e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2212,7 +2212,7 @@ F:drivers/gpio/gpio-ath79.c
 F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt
 
 ATHEROS ATH GENERIC UTILITIES
-M: "Luis R. Rodriguez" 
+M:     "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 S: Supported
 F: drivers/net/wireless/ath/*
@@ -2220,7 +2220,7 @@ F:drivers/net/wireless/ath/*
 ATHEROS ATH5K WIRELESS DRIVER
 M: Jiri Slaby 
 M: Nick Kossifidis 
-M:     "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/ath5k
 S: Maintained
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] wireless: move prism54 out to staging

2017-08-03 Thread Luis R. Rodriguez 
prism54 is deprecated in favor of the p54pci device driver. Although
only *one soul* had reported issues with it long ago Linux most Linux
distributions these days just disable the device driver given the
conflicts with the PCI IDs of p54pci and the *very* unlikely situation
of folks really need this driver anymore.

Before trying to due away with prism54 once more stuff it into staging,
which is our hospice for dying drivers.

Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS  |  4 ++--
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 21 files changed, 5 insertions(+), 23 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index ef340b9aeb98..97cf436e6750 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10666,11 +10666,11 @@ F:kernel/printk/
 F:     include/linux/printk.h
 
 PRISM54 WIRELESS DRIVER
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/p54
 S:     Obsolete
-F:     drivers/net/wireless/intersil/prism54/
+F: drivers/staging/prism54/
 
 PROC SYSCTL
 M: "Luis R. Rodriguez" 
diff --git a/drivers/net/wireless/intersil/Kconfig 
b/drivers/net/wireless/intersil/Kconfig
index 9da136049955..2b056b6daef8 100644
--- a/drivers/net/wireless/intersil/Kconfig
+++ b/drivers/net/wireless/intersil/Kconfig
@@ -15,24 +15,4 @@ source "drivers/net/wireless/intersil/hostap/Kconfig"
 source "drivers/net/wireless/intersil/orinoco/Kconfig"
 source "drivers/net/wireless/intersil/p54/Kconfig"
 
-config PRISM54
-   tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (DEPRECATED)'
-   depends on PCI
-   select WIRELESS_EXT
-   select WEXT_SPY
-   select WEXT_PRIV
-   select FW_LOADER
-   ---help---
- This enables support for FullMAC PCI/Cardbus prism54 devices. This
- driver is now deprecated in favor for the SoftMAC driver, p54pci.
- p54pci supports FullMAC PCI/Cardbus devices as well.
-
- For more information refer to the p54 wiki:
-
- http://wireless.kernel.org/en/users/Drivers/p54
-
- Note: You need a motherboard with DMA support to use any of these 
cards
-
- When built as module you get the module prism54
-
 endif # WLAN_VENDOR_INTERSIL
diff --git a/drivers/net/wireless/intersil/Makefile 
b/drivers/net/wireless/intersil/Makefile
index 9a8cbfee3ea5..aedb713

Re: [PATCH 1/2] wireless: move prism54 out to staging

2017-08-04 Thread Luis R. Rodriguez 
On Thu, Aug 03, 2017 at 05:42:15PM -0700, Greg KH wrote:
> On Thu, Aug 03, 2017 at 04:59:36PM -0700, Luis R. Rodriguez wrote:
> > prism54 is deprecated in favor of the p54pci device driver. Although
> > only *one soul* had reported issues with it long ago Linux most Linux
> > distributions these days just disable the device driver given the
> > conflicts with the PCI IDs of p54pci and the *very* unlikely situation
> > of folks really need this driver anymore.
> > 
> > Before trying to due away with prism54 once more stuff it into staging,
> > which is our hospice for dying drivers.
> > 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  MAINTAINERS  |  4 ++--
> >  drivers/net/wireless/intersil/Kconfig| 20 
> > 
> >  drivers/net/wireless/intersil/Makefile   |  1 -
> >  drivers/staging/Kconfig  |  2 ++
> >  drivers/staging/Makefile |  1 +
> 
> Can I get a TODO file that says it will be deleted in a kernel release
> or two so don't worry about touching anything in these files?

Sure, will respin with it.

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 0/2] prism54: move to staging

2017-08-07 Thread Luis R. Rodriguez 
Greg,

This v2 adds the TODO you requested to clarify prism54 will be removed in
two kernel releases from now, and so no further cleanup is needed other
than to ensure the driver compiles.

This is based on linux-next tag next-20170807.

  Luis

Luis R. Rodriguez (2):
  wireless: move prism54 out to staging
  MAINTAINERS: update email address for mcgrof for few straggling
drivers

  Luis

 MAINTAINERS  |  8 
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 drivers/staging/prism54/TODO |  5 +
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 22 files changed, 12 insertions(+), 25 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 create mode 100644 drivers/staging/prism54/TODO
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/2] wireless: move prism54 out to staging

2017-08-07 Thread Luis R. Rodriguez 
prism54 is deprecated in favor of the p54pci device driver. Although
only *one soul* had reported issues with it long ago Linux most Linux
distributions these days just disable the device driver given the
conflicts with the PCI IDs of p54pci and the *very* unlikely situation
of folks really need this driver anymore.

Before trying to due away with prism54 once more stuff it into staging,
which is our hospice for dying drivers.

Acked-by: Kalle Valo 
Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS  |  4 ++--
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 drivers/staging/prism54/TODO |  5 +
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 22 files changed, 10 insertions(+), 23 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 create mode 100644 drivers/staging/prism54/TODO
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 672b5d5402f0..3deaddc8c578 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10674,11 +10674,11 @@ F:kernel/printk/
 F:     include/linux/printk.h
 
 PRISM54 WIRELESS DRIVER
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/p54
 S:     Obsolete
-F:     drivers/net/wireless/intersil/prism54/
+F: drivers/staging/prism54/
 
 PROC SYSCTL
 M: "Luis R. Rodriguez" 
diff --git a/drivers/net/wireless/intersil/Kconfig 
b/drivers/net/wireless/intersil/Kconfig
index 9da136049955..2b056b6daef8 100644
--- a/drivers/net/wireless/intersil/Kconfig
+++ b/drivers/net/wireless/intersil/Kconfig
@@ -15,24 +15,4 @@ source "drivers/net/wireless/intersil/hostap/Kconfig"
 source "drivers/net/wireless/intersil/orinoco/Kconfig"
 source "drivers/net/wireless/intersil/p54/Kconfig"
 
-config PRISM54
-   tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (DEPRECATED)'
-   depends on PCI
-   select WIRELESS_EXT
-   select WEXT_SPY
-   select WEXT_PRIV
-   select FW_LOADER
-   ---help---
- This enables support for FullMAC PCI/Cardbus prism54 devices. This
- driver is now deprecated in favor for the SoftMAC driver, p54pci.
- p54pci supports FullMAC PCI/Cardbus devices as well.
-
- For more information refer to the p54 wiki:
-
- http://wireless.kernel.org/en/users/Drivers/p54
-
- Note: You need a motherboard with DMA support to use any of these 
cards
-
- When built as module you get the module prism54
-
 endif # WLAN_V

[PATCH v2 2/2] MAINTAINERS: update email address for mcgrof for few straggling drivers

2017-08-07 Thread Luis R. Rodriguez 
This will ensure I get emails on my work and personal email address.

Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3deaddc8c578..997b8062397a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2212,7 +2212,7 @@ F:drivers/gpio/gpio-ath79.c
 F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt
 
 ATHEROS ATH GENERIC UTILITIES
-M: "Luis R. Rodriguez" 
+M:     "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 S: Supported
 F: drivers/net/wireless/ath/*
@@ -2220,7 +2220,7 @@ F:drivers/net/wireless/ath/*
 ATHEROS ATH5K WIRELESS DRIVER
 M: Jiri Slaby 
 M: Nick Kossifidis 
-M:     "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/ath5k
 S: Maintained
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/22] Add and use pci_zalloc_consistent

2014-06-23 Thread Luis R. Rodriguez 
On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
> Adding the helper reduces object code size as well as overall
> source size line count.
> 
> It's also consistent with all the various zalloc mechanisms
> in the kernel.
> 
> Done with a simple cocci script and some typing.

Awesome, any chance you can paste in the SmPL? Also any chance
we can get this added to a make coccicheck so that maintainers
moving forward can use that to ensure that no new code is
added that uses the old school API?

  Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel