From: Luis R. Rodriguez mcg...@suse.com
The request_firmware*() APIs uses __getname() to iterate
over the list of paths possible for firmware to be found,
the code however never checked for failure on __getname().
Although *very unlikely*, this can still happen. Add the
missing check
From: Luis R. Rodriguez mcg...@suse.com
We currently use flexible arrays with a char at the
end for the remaining internal firmware name uses.
There are two limitations with the way we use this.
Since we're using a flexible array for a string on the
struct if we wanted to use two strings it means
From: Luis R. Rodriguez mcg...@suse.com
When direct firmware loading is used we iterate over a list
of possible firmware paths and concatenate the desired firmware
name with each path and look for the file there. Should the
passed firmware name be too long we end up truncating the
file we want
On Thu, May 07, 2015 at 08:06:35PM +0200, Paul Bolle wrote:
See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
selected, that is done for, almost always, no immediate benefit.
Changing those places to use
On Thu, May 14, 2015 at 10:31:52AM +1000, Julian Calaby wrote:
On Thu, May 14, 2015 at 4:23 AM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
+Require all firmware to be validly signed, under the same menu.
You reference the relevant Kconfig symbols above, do you want to add
it here too
From: Luis R. Rodriguez mcg...@suse.com
We'll want to reuse this same code later in order to
read two separate types of file contents. Although we
can simplify fw_read_file_contents() to do a direct
return we leave a bit of boilerplate code to make the
next changes easier to review. In this case
On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
[...] so, probably, almost
all .config files have FW_LOADER set. So I think, except for some corner
cases, either converting all select FW_LOADER to depends on
FW_LOADER or simply dropping select FW_LOADER all together, should
be
From: Luis R. Rodriguez mcg...@suse.com
This is the third iteration of RFCs for firmware signature suppport.
Upon review through discussions on the threads and IRC it seems folks are
generally OK with this now. This is rebased on top of David's latest pkcs7
branch but also depends on a series
From: Luis R. Rodriguez mcg...@suse.com
We'll want to reuse this same code later in order to
read two separate types of file contents. Although we
can simplify fw_read_file_contents() to do a direct
return we leave a bit of boilerplate code to make the
next changes easier to review. In this case
On Fri, May 15, 2015 at 08:07:55PM +0100, David Howells wrote:
Hi Luis,
As David Woodhouse pointed out to me, you don't need sign-file if you're just
going to create a detached PKCS#7 message as your signature. You can just use
openssl smime directly.
The reason that sign-file is needed
From: Luis R. Rodriguez mcg...@suse.com
Systems that have module signing currently enabled may
wish to extend vetting of firmware passed to the kernel
as well. We can re-use most of the code for module signing
for firmware signature verification and signing. This will
also later enable re-use
Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
full range ioremap_wc() idea below.
On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
Hi All,
On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
From the beginning it seems only framebuffer
On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote:
On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
c) ivtv: the driver does not have the PCI space mapped out separately, and
in fact it actually does not do the math for the framebuffer, instead
On Thu, Apr 16, 2015 at 01:18:37PM +0900, Hyong-Youb Kim wrote:
On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote:
An alternative... is to just ioremap_wc() the entire region, including
MMIO registers for these old devices. I see one ethernet driver that does
On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas bhelg...@google.com wrote:
[-cc Venkatesh (bouncing)
On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas bhelg...@google.com wrote:
Acked-by: Bjorn Helgaas bhelg
On Tue, May 19, 2015 at 4:37 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote:
On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
On Tue, 2015-05-19 at 22:02 +0200, Luis R. Rodriguez wrote:
David Howells has posted v4 of his
, Luis R. Rodriguez wrote:
David Howells has posted v4 of his series of supporting PKCS#7 for module
signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support, and
after
some review and patch shuffling I think this is ready for patch form. My
own
series however depend on quite
On Tue, May 19, 2015 at 4:29 PM, David Airlie airl...@redhat.com wrote:
On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas bhelg...@google.com wrote:
[-cc Venkatesh (bouncing)
On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Tue, May 19, 2015 at 3:44 PM
On Tue, May 12, 2015 at 02:49:39PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v3 changes patch 1 to just return -ENOMEM and remove the
unlikely() optimization. It also drops the early truncation
checks.
Luis R. Rodriguez (4):
firmware: fix __getname
I'll also mention:
---
The $DIGEST_ALGORITHM needs to be supported on the running kernel and
can differ from CONFIG_MODULE_SIG_HASH.
---
As I do no think that is quite obvious to a system integrator at first.
Luis
--
To unsubscribe from this list: send the line unsubscribe
On Tue, May 19, 2015 at 10:33:45AM +0100, David Howells wrote:
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
+ -nocerts -md $DIGEST_ALGORITHM -binary \
+ $(FIRMWARE_BLOB_NAME).p7s
Rather than using '' it might be worth using '-out' instead.
Sure, will amend
On Tue, May 19, 2015 at 11:47 AM, David Howells dhowe...@redhat.com wrote:
Luis R. Rodriguez mcg...@suse.com wrote:
I'll also mention:
---
The $DIGEST_ALGORITHM needs to be supported on the running kernel and
can differ from CONFIG_MODULE_SIG_HASH.
---
As I do no think that is quite
On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas bhelg...@google.com wrote:
Acked-by: Bjorn Helgaas bhelg...@google.com
Thanks! Who's tree should this go through?
Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
From: Luis R. Rodriguez mcg...@suse.com
Firmware licenses on linux-firmware should include an implicit
or explicit patent grant to end users for full device operation
otherwise it would start making linux-firmware useless for many
Linux distributions which have positions against patent encumbered
David Howells has posted v4 of his series of supporting PKCS#7 for module
signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support, and after
some review and patch shuffling I think this is ready for patch form. My own
series however depend on quite a bit of other pending changes, one
On Thu, May 14, 2015 at 11:29 AM, Arend van Spriel ar...@broadcom.com wrote:
On 05/14/15 19:56, Luis R. Rodriguez wrote:
diff --git a/README b/README
index f2ed92e..d2a56ec 100644
--- a/README
+++ b/README
@@ -18,7 +18,10 @@ and also cc: to related mailing lists.
Your commit should
On Wed, Apr 29, 2015 at 12:50:40PM -0700, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver could should split
up IO memory space properly
On Fri, Feb 13, 2015 at 01:15:18PM -0800, David Rientjes wrote:
On Fri, 13 Feb 2015, Luis R. Rodriguez wrote:
David,
since I'm making some Kconfig changes to Xen I think I should
fold this into that series with the modifications required
last so as to avoid other commits and have
On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote:
On Tue, 2015-05-19 at 22:02 +0200, Luis R. Rodriguez wrote:
David Howells has posted v4 of his series of supporting PKCS#7 for module
signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support, and
after
some review
On Tue, May 19, 2015 at 1:02 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Other than this last nitpick, any other concerns or recommendations ?
Oh one more thing. I think we should decide on a digest algorithm we'd
wish to be used for linux-firmware signing, distributions likely will
want
On Tue, May 19, 2015 at 4:03 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
OK I was wrong. It should still compile
Right.
So I guess you only
need the depends on/select for those that won't work without the
firmware.
Well that's be true if FW_LOADER was easy to disable, but its not.
On Tue, May 19, 2015 at 01:59:36PM -0700, Andy Lutomirski wrote:
[added cc's from the other thread]
On 05/19/2015 01:02 PM, Luis R. Rodriguez wrote:
David Howells has posted v4 of his series of supporting PKCS#7 for module
signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support
From: Luis R. Rodriguez mcg...@suse.com
Michal Marek, Xen folks (David Vrabel, Konrad, Ian), which tree should
these go through?
This v6 addresses enabling xen on i386, x86-64 and arm64 starting
from a 'make allnoconfig' setting.
Luis R. Rodriguez (2):
kconfig: clarify kvmconfig is for kvm
On Wed, May 20, 2015 at 12:52:14PM +0300, Tomi Valkeinen wrote:
Hi Luis,
On 21/04/15 23:40, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
The MTRR added was never being deleted.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo
On Wed, May 20, 2015 at 12:53 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Tomi,
the new required ioremap_uc() which was added in the initial patch set here is
now merged on linux-next but I just noticed a small issue with this atyfb
specific patch, I'll fix that and respin and send to you
On Wed, May 20, 2015 at 1:39 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Tue, May 19, 2015 at 04:45:30PM -0700, Luis R. Rodriguez wrote:
On Tue, May 19, 2015 at 4:29 PM, David Airlie airl...@redhat.com wrote:
On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas bhelg...@google.com
wrote
On Wed, May 20, 2015 at 11:00:55AM +0200, Paul Bolle wrote:
On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote:
Well that's be true if FW_LOADER was easy to disable, but its not. You
really gotta try hard to disable
On Wed, May 20, 2015 at 2:02 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Tue, Apr 21, 2015 at 01:20:31PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advantage of PAT when available. This
should help with the transition of converting video
From: Luis R. Rodriguez mcg...@suse.com
We'll be adding options for xen as well.
Cc: Josh Triplett j...@joshtriplett.org
Cc: Borislav Petkov b...@suse.de
Cc: Pekka Enberg penb...@kernel.org
Cc: David Rientjes rient...@google.com
Cc: Michal Marek mma...@suse.cz
Cc: Randy Dunlap rdun
Tomi,
the new required ioremap_uc() which was added in the initial patch set here is
now merged on linux-next but I just noticed a small issue with this atyfb
specific patch, I'll fix that and respin and send to you as v5.
Luis
--
To unsubscribe from this list: send the line unsubscribe
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests on i386, x86-64 and arm64 by just using:
make xenconfig
You can start from an allnoconfig and then switch to xenconfig.
This also splits out the options which are available currently
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
Bjorn, this v6 respins the introduction of pci_iomap_wc() and
its users onto Bjorn's pci tree [0] on the next branch. It goes
with your own Acked-by on the PCI part as well as the framebuffer
subsystem maintainer's own Acked-bys for the framebuffer driver
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers to take advantage of write-combining
when possible. The PCI specification does not allow for us
to automatically identify a memory region which needs
write-combining so drivers have to identify these areas
on their own
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
On Fri, May 29, 2015 at 1:23 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets
On Wed, Apr 29, 2015 at 2:44 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This series addresses one commend fix on the table for mtrr_add()
effect on the PAT case when UC- is used. Other than that it is
the same as v4.
Luis R. Rodriguez (6
On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
Hi Luis,
Sorry for delay in response. Actually I was looking for the history of
this section of code but I couldn't find it. Anyway this is dead code
and we are fine with removing this dead code.
James,
Please consider
On Thu, May 28, 2015 at 2:50 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote:
Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a):
From: Luis R. Rodriguez
On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Ville,
the x86 patches are in and on their way to the next version of Linux.
Can I trouble you for your review of the atyfb driver changes?
Hey Ville, just a friendly *poke*.
Luis
--
To unsubscribe from this list: send
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void
On Tue, Jun 2, 2015 at 11:42 AM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
All the ia64 pvops code is now dead code since both
xen and kvm support have been ripped out [0] [1]. Just
that no one had troubled to rip this stuff out. The only
useful
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc
From: Luis R. Rodriguez mcg...@suse.com
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Boris,
provided the outcome of the above maintainer's preference for you
to merge
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void
On Fri, Jun 05, 2015 at 05:17:08PM +0530, Sreekanth Reddy wrote:
On Thu, Jun 4, 2015 at 11:11 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
Hi Luis,
Sorry for delay in response. Actually I was looking for the history
From: Luis R. Rodriguez mcg...@suse.com
This is needed the following modules:
Linux Kernel Dump Test Tool Module
CONFIG_LKDTMdrivers/misc/lkdtm.c
Since:
mcgrof@ergon ~/linux-next (git::master)$ git describe --contains aac416fc38cdf
v3.15-rc1~141^2~84
CONFIG_STI_CONSOLE drivers
From: Luis R. Rodriguez mcg...@suse.com
This is needed the following modules:
Linux Kernel Dump Test Tool Module
CONFIG_LKDTMdrivers/misc/lkdtm.c
Since:
mcgrof@ergon ~/linux-next (git::master)$ git describe --contains aac416fc38cdf
v3.15-rc1~141^2~84
CONFIG_STI_CONSOLE drivers
From: Luis R. Rodriguez mcg...@suse.com
All the ia64 pvops code is now dead code since both
xen and kvm support have been ripped out [0] [1]. Just
that no one had troubled to rip this stuff out. The only
useful remaining pieces were the old pvops docs but that
was recently also generalized
On Tue, Jun 02, 2015 at 12:46:48PM -0600, Toshi Kani wrote:
On Tue, 2015-06-02 at 18:21 +0200, Luis R. Rodriguez wrote:
On Mon, Jun 01, 2015 at 01:36:23PM -0600, Toshi Kani wrote:
This patchset adds support of Write-Through (WT) mapping on x86.
The study below shows that using WT mapping
On Tue, Jun 02, 2015 at 12:50:09PM -0700, Andy Lutomirski wrote:
On Tue, Jun 2, 2015 at 12:43 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Jun 02, 2015 at 12:46:48PM -0600, Toshi Kani wrote:
On Tue, 2015-06-02 at 18:21 +0200, Luis R. Rodriguez wrote:
On Mon, Jun 01, 2015 at 01:36
On Wed, Jun 3, 2015 at 10:55 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 20/05/15 22:46, Luis R. Rodriguez wrote:
On Wed, May 20, 2015 at 12:52:14PM +0300, Tomi Valkeinen wrote:
Hmm, this looks a bit odd... You're removing the pseudo_palette, and
using its memory for mtrr cookie
From: Luis R. Rodriguez mcg...@suse.com
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB,
the other MTRR types were implemented and supported here but with
no real good reason. The ioremap() APIs are architecture agnostic and
at least on x86 PAT is a new design that extends MTRRs
From: Luis R. Rodriguez mcg...@suse.com
Tomi,
This v4 fixes the issue of the use of the old use of
info-par for the pseudo_palette and our need to extend
it for the MTRR cookie by extending our proposed new
struct vesafb_par with the pseudo_palette and later
pointing info-pseudo_palette
From: Luis R. Rodriguez mcg...@suse.com
The MTRR added was never being deleted, in order to store the
MTRR cookie we need to make use of the private info-par so we
create a struct for this. This driver was already using the extra
space typically used for info-par for the info-pseudo_palette
which
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails.
ioremap_wc() API is already used to take advantage of architecture
write-combining when available.
Convert the driver
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver could should split
up IO memory space properly and that is quite a bit of work.
Just remove the uncommented dead MTRR code then.
There are a few motivations for this:
a) Take advantage of PAT when available
b
On Mon, Jun 22, 2015 at 09:06:41AM +0200, Borislav Petkov wrote:
On Mon, Jun 22, 2015 at 03:01:38AM +0200, Luis R. Rodriguez wrote:
We can certainly replace the WARN() with pr_warn(), I don't see
how its confusing though as its a run time real issue. Either
way whatever you recommend
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels this will always splat. Fix that.
Reported-by: Fengguang Wu fengguang...@intel.com [0-day test robot]
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
1 file changed, 4
From: Luis R. Rodriguez mcg...@suse.com
Mauro, Doug,
The 0-day robot found using WARN() on built-in kernels confusing. Upon
further thought pr_warn() is better and will likely also not confuse
humans too.
Boris, provided maintainers Ack, please consider these patches.
These depend
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels this will always splat. Fix that.
Reported-by: Fengguang Wu fengguang...@intel.com [0-day test robot]
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/media/pci/ivtv/ivtvfb.c | 6 --
1 file changed, 4 insertions(+), 2
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
When working on collateral evolutions often times by definition
we end up having to go and transform existing drivers to new APIs
tree wide. You have a few options when this happens:
0) *If* you're lucky your collateral evolution is very specific to
a subsystem and you get to only work with
On Tue, Jun 16, 2015 at 3:20 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Tue, Jun 16, 2015 at 2:16 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez mcg
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advantage of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache
From: Luis R. Rodriguez mcg...@suse.com
Now that we have pci_iomap_wc() add the respective devres helpers.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.
Add pci_iomap_wc
On Tue, Jun 16, 2015 at 12:31 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Mon, Jun 8, 2015 at 4:43 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Ville,
the x86 patches are in and on their way to the next version
On Sun, Jun 21, 2015 at 10:41:20PM +0200, Borislav Petkov wrote:
On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote:
Nope, well the driver requires huge amounts of work to work with PAT,
that work will likely never be done, so hence the warning. Its our
compromise as only 2
From: Luis R. Rodriguez mcg...@suse.com
Arnd,
After a long-winded conversation with Bjorn over use of
EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() he's noted he'd
be OK if this goes through you as an alternative. This series
goes unmodified from the last posted v6 series, I am just
reposting
From: Luis R. Rodriguez mcg...@suse.com
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
commit 1bf1735b478008c30acaff18ec6f4a3ff211c28a
Author: Luis R. Rodriguez mcg...@suse.com
AuthorDate: Mon Jun 15 10:28:16 2015 +0200
Commit: Ingo Molnar mi...@kernel.org
CommitDate: Thu Jun 18 11:23:41 2015 +0200
x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add
On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement
On Thu, Jun 25, 2015 at 8:09 AM, Borislav Petkov b...@suse.de wrote:
+void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
+ int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+
On Thu, Jun 25, 2015 at 08:59:45AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Jun 19, 2015 at 3:22 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Tomi, Dave, Andy,
Its' been one month now since posting the last unmodified version
(other than
On Thu, Jun 25, 2015 at 8:40 AM, Borislav Petkov b...@suse.de wrote:
On Wed, Jun 24, 2015 at 06:22:19PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Now that we have pci_iomap_wc() add the respective
devres helpers. These go unexported for now but
note that should
On Thu, Jun 25, 2015 at 08:49:22AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
WARN() may confuse users, fix that. ipath_init_one() is part the
device's probe so this would only be triggered if a corresponding
On Wed, Jun 24, 2015 at 06:34:17PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Andrew,
Andrew, as Ingo noted please disregard these patches as it seems we'll be
preferring for this to go through the x86 tree.
Luis
--
To unsubscribe from this list: send the line
On Wed, Jun 24, 2015 at 4:32 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Jun 16, 2015 at 12:40 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Detangle
From: Luis R. Rodriguez mcg...@suse.com
Rename dma_*_writecombine() to dma_*_wc(), so that the naming
is coherent across the various write-combining APIs.
The following Coccinelle SmPL patch was used for this simple
transformation:
@ rename_dma_alloc_writecombine @
expression dev, size
From: Luis R. Rodriguez mcg...@suse.com
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Detangle both calls as we're used to.
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams dan.j.willi...@intel.com
Cc: dmaeng...@vger.kernel.org
Cc: linux-kernel
From: Luis R. Rodriguez mcg...@suse.com
Boris, Ingo,
Ingo had asked for this to be kept in my tree until the end of the
merge window. It seems its that time now so sending this out. I'll
note that there are a few outstanding series related to MTRR, but
those do not have conflicts
On Thu, Jun 25, 2015 at 4:04 PM, Ville Syrjälä syrj...@sci.fi wrote:
it doesn't hurt too much
since smem_len gets overwritten later in aty_init().
That's the idea, we set it with a default as it will be overwritten
later anyway.
Luis
--
To unsubscribe from this list: send the line unsubscribe
On Fri, Jun 26, 2015 at 02:11:03AM +0300, Ville Syrjälä wrote:
On Thu, Jun 25, 2015 at 04:06:45PM -0700, Luis R. Rodriguez wrote:
On Thu, Jun 25, 2015 at 4:04 PM, Ville Syrjälä syrj...@sci.fi wrote:
it doesn't hurt too much
since smem_len gets overwritten later in aty_init().
That's
On Wed, Jun 24, 2015 at 3:05 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2015-06-24 at 18:38 +0200, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis
1001 - 1100 of 6292 matches
Mail list logo
