On Tue, Apr 21, 2015 at 2:12 PM, Andy Lutomirski wrote:
> On Tue, Apr 21, 2015 at 2:09 PM, Luis R. Rodriguez
> wrote:
>> On Tue, Apr 21, 2015 at 1:59 PM, Marciniszyn, Mike
>> wrote:
>>>> > This driver already makes use of ioremap_wc() on PIO buffers, so
>>
From: "Luis R. Rodriguez"
This series adds pci_ioremap_wc_bar() and makes use of it
on a few framebuffer device drivers.
Luis R. Rodriguez (4):
pci: add pci_ioremap_wc_bar()
video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
video: fbdev: kyrofb: use arch_p
From: "Luis R. Rodriguez"
This series addresses simple changes to framebuffer drivers to use
arch_phys_wc_add() and ioremap_wc() as well as fixing gbefb to add
missing mtrr_del() calls. These changes are pretty straight forward.
Luis R. Rodriguez (17):
video: fbdev: rad
From: "Luis R. Rodriguez"
This series adds pci_iomap_wc() variants and makes use of them
to framebuffer device drivers.
Luis R. Rodriguez (4):
pci: add pci_iomap_wc() variants
video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()
video: fbdev: s3fb: use arch_phys_wc
From: "Luis R. Rodriguez"
The vesafb has some theoretical uses of MTRR, in practice only
write-combining is used and since PAT replaces MTRR and MTRR's
use should be phased lets just remove such old theoretical uses
of MTRR.
Luis R. Rodriguez (3):
video: fbdev: vesaf
From: "Luis R. Rodriguez"
As we phase out MTRR we need to also prepare for the flip of
the default ioremap() behaviour from UC- to strong UC. There
are a few remaining drivers which does not allow us to make
a smooth transition over and which do not allow us to remove
MTRR use. The
From: "Luis R. Rodriguez"
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
The qib driver uses a mmap() special case for when PAT is
not used, this behaviour used to be determined with a
module parameter but since we have been ask
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
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-Christoph
From: "Luis R. Rodriguez"
MTRR use is being deprecated and should only be used
with the helper arch_phys_wc_add() when PAT is not
available and enabled. This v4 follows addresse the
removal of the PAT module parameter for the driver which
was always preferring PAT anyway.
Luis R. Ro
On Wed, Apr 15, 2015 at 09:07:37PM -0400, Andy Walls wrote:
> On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote:
> > Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
> > full range ioremap_wc() idea below.
> >
> > On Wed, Apr 15, 201
On Tue, Apr 21, 2015 at 3:02 PM, Luis R. Rodriguez wrote:
> Andy, can we live without MTRR support on this driver for future kernels? This
> would only leave ipath as the only offending driver.
Sorry to be clear, can we live with removal of write-combining on this driver?
Luis
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 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, in
On Tue, Apr 21, 2015 at 06:51:26PM -0400, Andy Walls wrote:
> Sorry for the top post; mobile work email account.
>
> Luis,
>
> You do the changes to remove MTTR and point me to your dev repo and branch.
> Also point me to the new functions/primitives I'll need.
There is nothing new actually need
On Tue, Apr 21, 2015 at 04:57:32PM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 12:46:01AM +0200, Luis R. Rodriguez wrote:
>
> > are talking about annotating the qib driver as "known to be broken without
> > PAT"
> > and since the ipath driver needs
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> > > Mike, do you think the time is right to just remove the iPath driver?
> >
> > With PAT now being default the driver effectively w
On Wed, Apr 22, 2015 at 09:44:52AM -0400, Doug Ledford wrote:
> On Tue, 2015-04-21 at 14:50 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > There is no good reason not to, we eventually delete it as well.
> >
> > Cc: Toshi Kani
On Wed, Apr 22, 2015 at 09:54:38AM -0400, Doug Ledford wrote:
> On Tue, 2015-04-21 at 14:50 -0700, Luis R. Rodriguez wrote:
>
> This:
> > + /* MTRR was used if this is non-zero */
> > + if (!dd->wc_cookie)
> > vma->vm_page_prot = pgprot_writecom
On Wed, Apr 22, 2015 at 04:45:04PM +0930, Rusty Russell wrote:
> "Luis R. Rodriguez" writes:
> > From: "Luis R. Rodriguez"
> >
> > This adds a couple of bool module_param_config_*() helpers
> > which are designed to let us easily associate a b
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
> On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> > On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> > > > Mike, do you think the time is right to just re
On Wed, Apr 22, 2015 at 8:54 AM, Luis R. Rodriguez wrote:
> On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
>> On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
>> > On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
>>
On Wed, Apr 22, 2015 at 10:17:55AM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
> > On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> > > On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
>
On Tue, Apr 21, 2015 at 01:42:51PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> There is only one user but since we're going to bury
> MTRR next out of access to drivers expose this last
> piece of API to drivers in a general fashion only
> n
From: "Luis R. Rodriguez"
There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.
Cc: Toshi Kani
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "
On Wed, Apr 22, 2015 at 09:53:03AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 22, 2015 at 8:23 AM, Luis R. Rodriguez wrote:
> > On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> >> On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> >>
On Wed, Apr 22, 2015 at 12:57:18PM -0400, Doug Ledford wrote:
> On Wed, 2015-04-22 at 17:33 +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 22, 2015 at 09:54:38AM -0400, Doug Ledford wrote:
> > > On Tue, 2015-04-21 at 14:50 -0700, Luis R. Rodriguez wrote:
> > >
> >
On Wed, Apr 22, 2015 at 01:48:27PM -0400, Doug Ledford wrote:
> On Wed, 2015-04-22 at 19:37 +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 22, 2015 at 12:57:18PM -0400, Doug Ledford wrote:
> > > On Wed, 2015-04-22 at 17:33 +0200, Luis R. Rodriguez wrote:
> > > > On W
From: "Luis R. Rodriguez"
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
The qib driver uses a mmap() special case for when PAT is
not used, this behaviour used to be determined with a
module parameter but since we have been ask
On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
> On Wed, 2015-04-22 at 10:17 -0600, Jason Gunthorpe wrote:
> > On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
> > > On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> > > &
On Wed, Apr 22, 2015 at 12:10 PM, Doug Ledford wrote:
> On Wed, 2015-04-22 at 21:05 +0200, Luis R. Rodriguez wrote:
>
>> > > I'd also love to remove the driver if it turns out there are actually
>> > > no users. qib substantially replaces it except for a few ver
From: "Luis R. Rodriguez"
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.
I
From: "Luis R. Rodriguez"
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.
I
From: "Luis R. Rodriguez"
This v2 splits out the #ifdef'ery eyesores out into separate
patches to make it clear this is a separate atomic operation
which requires review in and of itself. It also makes some
clarifications about how the module_param_config_*() can help
with eye
From: "Luis R. Rodriguez"
Most code already uses consts for the struct kernel_param_ops,
sweep the kernel for the last offending stragglers. Other than
include/linux/moduleparam.h and kernel/params.c all other changes
were generated with the following Coccinelle SmPL patch. Merge
From: "Luis R. Rodriguez"
We're directly checking and modifying sig_enforce when needed instead
of using the generic helpers. This prevents us from generalizing this
helper so that others can use it. Use indirect helpers to allow us
to generalize this code a bit and to make it a
From: "Luis R. Rodriguez"
This takes out the bool_enable_only implementation from
the module loading code and generalizes it so that others
can make use of it.
Cc: Rusty Russell
Cc: Jani Nikula
Cc: Andrew Morton
Cc: Kees Cook
Cc: Tejun Heo
Cc: Ingo Molnar
Cc: linux-kernel@vger.
From: "Luis R. Rodriguez"
This adds a couple of bool module_param_config_*() helpers
which are designed to let us easily associate a boolean
module parameter with an associated kernel configuration
option. Folks can use this to avoid what typically would
be #ifdef eyesores aro
From: "Luis R. Rodriguez"
We can avoid an ifdef over wq_power_efficient's declaration
by just using IS_ENABLED().
Cc: Rusty Russell
Cc: Jani Nikula
Cc: Andrew Morton
Cc: Kees Cook
Cc: Tejun Heo
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
Cc: co...@systeme.lip6.fr
Sign
From: "Luis R. Rodriguez"
Use the new module_param_config_on_off() for setting / disabling of
CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
Cc: Rusty Russell
Cc: Andrew Morton
Cc: Kees Cook
Cc: Tejun Heo
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
Cc: co...@systeme.lip6.fr
Signed-off-
From: "Luis R. Rodriguez"
There's no need to require an ifdef over the declaration
of sig_enforce as IS_ENABLED() can be used. While at it,
there's no harm in exposing this kernel parameter outside of
CONFIG_MODULE_SIG as it'd be a no-op on non module sig
kernels.
Now,
From: "Luis R. Rodriguez"
Cc: Rusty Russell
Cc: Andrew Morton
Cc: Kees Cook
Cc: Tejun Heo
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
Cc: co...@systeme.lip6.fr
Signed-off-by: Luis R. Rodriguez
---
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
On Thu, Apr 23, 2015 at 10:20:10AM +0200, Julia Lawall wrote:
> > @ 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,
On Thu, Apr 23, 2015 at 11:22:49AM -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 22, 2015 at 02:55:06PM -0700, Luis R. Rodriguez wrote:
> > +int param_set_bool_enable_only(const char *val, const struct kernel_param
> > *kp)
> > +{
> > + int err = 0;
>
On Thu, Apr 23, 2015 at 11:45:09AM +0930, Rusty Russell wrote:
> "Luis R. Rodriguez" writes:
> > From: "Luis R. Rodriguez"
> >
> > This adds a couple of bool module_param_config_*() helpers
> > which are designed to let us easily associate a boolean
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 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, in
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 o
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 ethe
On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote:
> On Sat, Mar 28, 2015 at 01:28:18AM +0100, Luis R. Rodriguez wrote:
> > On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
> > > On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä wrote:
> > > &
On Sat, Apr 25, 2015 at 07:12:05AM -0400, Andy Walls wrote:
> Hi Luis,
>
> Sorry for the late reply.
>
> Thank you for the patch! See my comments below:
>
> On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
From: "Luis R. Rodriguez"
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.
I
On Wed, Apr 22, 2015 at 12:26 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> 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()
&
On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> 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.
>
&
From: "Luis R. Rodriguez"
This series adds pci_iomap_wc() and the respective devm helper pcim_iomap_wc().
Luis R. Rodriguez (5):
pci: add pci_iomap_wc() variants
lib: devres: add pcim_iomap_wc() variants
video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()
video: f
From: "Luis R. Rodriguez"
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases() just
peg an IORESOURCE_WC flag for us but where exactly
video devices memory lie varies *largely* and at times things
are mixed with MMIO register
From: "Luis R. Rodriguez"
Now that we have pci_iomap_wc() add the respective devres helpers.
Cc: Toshi Kani
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Bjorn Helgaas
Cc: Antonino Daplas
From: "Luis R. Rodriguez"
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 req
From: "Luis R. Rodriguez"
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):
x86: add ioremap_uc() - force strong UC, PCD=1, PWT=1
x86: document WC MTRR effects on
From: "Luis R. Rodriguez"
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 advanta
From: "Luis R. Rodriguez"
This provides a bit of clean up on PAT and then adds addresses
the agreed upon compromise of how we will address drivers with broken
PAT support by using pat_enabled() and recommending to boot with "nopat"
kernel parameter.
With this and the rest o
From: "Luis R. Rodriguez"
ioremap_nocache() currently uses UC- by default.
Our goal is to eventually make UC the default.
Linux maps UC- to PCD=1, PWT=0 page attributes on
non-PAT systems. Linux maps UC to PCD=1, PWT=1
page attributes on non-PAT systems. On non-PAT
and PAT systems a W
From: "Luis R. Rodriguez"
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 advanta
From: "Luis R. Rodriguez"
Cc: Andy Walls
Cc: Doug Ledford
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Bjorn Helgaas
Cc: Borislav Petkov
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
Signed-off-
From: "Luis R. Rodriguez"
As part of the effort to phase out MTRR use document
write-combining MTRR effects on pages with different
non-PAT page attributes flags and different PAT entry
values. Extend arch_phys_wc_add() documentation to
clarify power of two sizes / boundary requirem
From: "Luis R. Rodriguez"
Cc: Andy Walls
Cc: Doug Ledford
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Bjorn Helgaas
Cc: Borislav Petkov
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: x...@
From: "Luis R. Rodriguez"
The size of the framebuffer to be used needs to
be fudged to account for the different type of
devices that are out there. This captures what
is required to do well, we'll resuse this later.
This has no functional changes.
Cc: Toshi Kani
Cc: Suresh S
From: "Luis R. Rodriguez"
At times all we need is an enabler / disabler.
Cc: Andy Walls
Cc: Doug Ledford
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Bjorn Helgaas
Cc: Borislav Petkov
Cc: Michael S. Tsirkin
From: "Luis R. Rodriguez"
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PC
From: "Luis R. Rodriguez"
We use pat_enabled on x86 specific code to see if PAT is
enabled or not, we however are granting full access to the
variable even though readers do not need to set it.
This uses the early_param_off() to simplify the definition of
the old pat_enabled under a
From: "Luis R. Rodriguez"
Replace a WC MTRR call followed by a UC MTRR "hole" call
with a single WC MTRR call and use strong UC to protect
the MMIO region and account for the device's architecture
and MTRR size requirements.
The atyfb driver relies on two overlappi
From: "Luis R. Rodriguez"
Two Linux device drivers cannot work with PAT and the work
required to make them work is significant. There is not
enough motivation to convert these drivers over to use
PAT properly, the compromise reached is to let drivers
that cannot be ported to PAT check
From: "Luis R. Rodriguez"
This driver uses strong UC for the MMIO region, and ioremap_wc()
for the framebuffer to whitelist for the WC MTRR what can changed
to WC. On PAT systems we don't need the MTRR call so just use
arch_phys_wc_add() there, this lets us remove all those ifdef
From: "Luis R. Rodriguez"
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.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
From: "Luis R. Rodriguez"
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.
I
On Thu, Apr 30, 2015 at 10:59:17AM -0500, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> Hi Luis,
>
> On Wed, Apr 29, 2015 at 02:36:08PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > This allows drivers to take advantage of writ
On Thu, Apr 30, 2015 at 10:03:18AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 30, 2015 at 9:52 AM, Luis R. Rodriguez wrote:
> > On Thu, Apr 30, 2015 at 10:59:17AM -0500, Bjorn Helgaas wrote:
> >> [+cc linux-pci]
> >>
> >> Hi Luis,
> >>
> >
On Thu, Apr 30, 2015 at 11:26:47AM -0500, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> Hi Luis,
>
> On Wed, Apr 29, 2015 at 02:36:09PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > Now that we have pci_iomap_wc() add the respec
From: "Luis R. Rodriguez"
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. There is IORESOURC
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_w
On Fri, Mar 20, 2015 at 4:18 PM, Luis R. Rodriguez
wrote:
> 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-
On Thu, Apr 30, 2015 at 03:56:41PM +0200, Borislav Petkov wrote:
> On Wed, Apr 29, 2015 at 02:44:20PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
>
> Please add a commit message, albeit a single trivial sentence.
>
> > Cc: Andy W
On Thu, Apr 30, 2015 at 06:00:44PM +0200, Borislav Petkov wrote:
> On Wed, Apr 29, 2015 at 02:44:21PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
>
> So this one is missing a commit message too but we need to talk about
> this. Why are we adding __re
On Thu, Apr 30, 2015 at 11:32 AM, Luis R. Rodriguez wrote:
> , we
> at run time in early boot have to disable a feature but this will typically
> happen only once.
Sorry I meant that we may need to disable a feature early at boot
time, but this typically happens only once with the
From: "Luis R. Rodriguez"
This v5 drops the addition of new early_param_*() helpers
and their use on pat_enabled as we are sticking with
__read_mostly, and as per review this should be selectively
used only on well established hot paths. pat_enabled turns
out to be a common hot path,
From: "Luis R. Rodriguez"
Use pr_info() instead of the old printk to
prefix the component where things are coming
from. With this readers will know exactly where
the message is coming from. Since pr_fmt is
already defined in this case we redefine it to
"PAT: ".
We leave
From: "Luis R. Rodriguez"
We use pat_enabled on x86 specific code to see if PAT
is enabled or not, we however are granting full access to
the variable even though readers do not need to set it.
If for instance we granted access to it to modules later
they then could override the variab
From: "Luis R. Rodriguez"
Two Linux device drivers cannot work with PAT and the work
required to make them work is significant. There is not
enough motivation to convert these drivers over to use
PAT properly, the compromise reached is to let drivers
that cannot be ported to PAT check
From: "Luis R. Rodriguez"
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.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
From: "Luis R. Rodriguez"
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.
I
On Thu, Apr 30, 2015 at 04:46:38PM -0500, Bjorn Helgaas wrote:
> On Thu, Apr 30, 2015 at 07:27:23PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Apr 30, 2015 at 11:26:47AM -0500, Bjorn Helgaas wrote:
>
> > > I don't see users of either pcim_iomap_wc() or pcim_iomap_wc_re
From: "Luis R. Rodriguez"
Here are a few simplifications on the sig_force module parameter code.
I'm digging through this as long term I'd like enable standard use of
the crypto code for module loading for firmware loading and later
any file requested (non firmware) to repla
From: "Luis R. Rodriguez"
Cc: Rusty Russell
Cc: Jani Nikula
Cc: Christoph Hellwig
Cc: Andrew Morton
Cc: Geert Uytterhoeven
Cc: Hannes Reinecke
Cc: Kees Cook
Cc: Tejun Heo
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
Cc: co...@systeme.lip6.fr
Signed-off-by: Luis R.
From: "Luis R. Rodriguez"
This adds a couple of bool module_param_config_*() helpers
which are designed to let us easily associate a booloean
module parameter with an associated kernel configuration
option, and to help us remove #ifdef'ery eyesores.
Cc: Rusty Russell
Cc:
From: "Luis R. Rodriguez"
Use the new module_param_config_on_off() for setting / disabling of
CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
Cc: Rusty Russell
Cc: Jani Nikula
Cc: Christoph Hellwig
Cc: Andrew Morton
Cc: Geert Uytterhoeven
Cc: Hannes Reinecke
Cc: Kees Cook
Cc: Tejun Heo
Generated-by: Coccinelle SmPL
Cc: co...@systeme.lip6.fr
Cc: Rusty Russell
Cc: Junio C Hamano
Cc: Jani Nikula
Cc: Christoph Hellwig
Cc: Andrew Morton
Cc: Geert Uytterhoeven
Cc: Hannes Reinecke
Cc: Kees Cook
Cc: Tejun Heo
Cc: Ingo Molnar
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis
From: "Luis R. Rodriguez"
We're directly checking and modifying sig_enforce when needed instead
of using the generic helpers. This prevents us from generalizing this
helper so that others can use it. Use indirect helpers to allow us
to generalize this code a bit and to make it a
From: "Luis R. Rodriguez"
This takes out the bool_enable_only implementation from
the module loading code and generalizes it so that others
can make use of it.
Cc: Rusty Russell
Cc: Jani Nikula
Cc: Christoph Hellwig
Cc: Andrew Morton
Cc: Geert Uytterhoeven
Cc: Hannes Reinecke
usses overlapping ioremap() calls and what we'd need
for a default shift from UC- to strong UC.
On Fri, Apr 10, 2015 at 11:25:22PM -0700, Andy Lutomirski wrote:
> On Apr 10, 2015 6:29 PM, "Luis R. Rodriguez" wrote:
> >
> > On Fri, Apr 10, 2015 at 02:22:51PM -0700, Andy Lut
On Thu, Apr 9, 2015 at 5:57 PM, Luis R. Rodriguez
wrote:
> Hey folks,
>
> next week I'd like to address replacing the need for CRDA [0] as a
> udev helper with in-kernel functionality There's a few motivations
> for this but a good one is that the kernel already has no
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> > >
> > > I tentatively put this (and the rest of the series) on
601 - 700 of 3151 matches
Mail list logo
