* Re: [PATCH 1/2] OMAPDSS: dss-of: Fix node refcount leak in omapdss_of_get_next_port()
From: Tomi Valkeinen @ 2015-08-07 10:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <2641bae47b15795f2a697e69c72ad1b7424d2178.1438885638.git.jsarha@ti.com>
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
On 06/08/15 21:41, Jyri Sarha wrote:
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
Please always fill in the patch description. In simplest cases it may be
the same as in the subject.
> ---
> drivers/video/fbdev/omap2/dss/dss-of.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c b/drivers/video/fbdev/omap2/dss/dss-of.c
> index 928ee63..ab6ef16 100644
> --- a/drivers/video/fbdev/omap2/dss/dss-of.c
> +++ b/drivers/video/fbdev/omap2/dss/dss-of.c
> @@ -60,6 +60,7 @@ omapdss_of_get_next_port(const struct device_node *parent,
> }
> prev = port;
> } while (of_node_cmp(port->name, "port") != 0);
> + of_node_put(ports);
I think a blank line is needed above of_node_put().
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: atmel: fix warning for const return value
From: Sudip Mukherjee @ 2015-08-07 5:34 UTC (permalink / raw)
To: Rob Herring
Cc: Tomi Valkeinen, linux-kernel, linux-fbdev, Nicolas Ferre,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1438011701-18423-1-git-send-email-robh@kernel.org>
On Mon, Jul 27, 2015 at 10:41:41AM -0500, Rob Herring wrote:
> A const on a return value is meaningless and generates a warning on some
> versions of gcc:
>
> drivers/video/fbdev/atmel_lcdfb.c:1003: warning: type qualifiers ignored on function return type
maybe this one should have been static instead of const.
regards
sudip
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: Toshi Kani @ 2015-08-06 22:58 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jan Beulich, Andy Lutomirski, Bjorn Helgaas, Jej B, X86 ML,
Andrew Morton, Ville Syrjälä, Julia Lawall, xen-devel,
Dave Airlie, Ville Syrjälä, Juergen Gross,
Borislav Petkov, Tomi Valkeinen, linux-fbdev,
linux-kernel@vger.kernel.org, linux-media,
linux-pci@vger.kernel.org
In-Reply-To: <CAB=NE6W3=SFTqabeD6gq7JCqFZ7+SBZh7Xa=RteO_8-3P7fbdw@mail.gmail.com>
On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote:
> On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
> > > > > > On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
> > > > There are two usages on MTRRs:
> > > > 1) MTRR entries set by firmware
> > > > 2) MTRR entries set by OS drivers
> > > >
> > > > We can obsolete 2), but we have no control over 1). As UEFI
> > > > firmwares
> > > > also set this up, this usage will continue to stay. So, we should
> > > > not
> > > > get rid of the MTRR code that looks up the MTRR entries, while we
> > > > have
> > > > no need to modify them.
> > > >
> > > > Such MTRR entries provide safe guard to /dev/mem, which allows
> > > > privileged user to access a range that may require UC mapping while
> > > > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to
> > > > UC in
> > > > such a case.
> > >
> > > But it wouldn't be impossible to simply read the MTRRs upon boot,
> > > store the information, disable MTRRs, and correctly use PAT to
> > > achieve the same effect (i.e. the "blindly maps" part of course
> > > would need fixing).
> >
> > It could be done, but I do not see much benefit of doing it. One of the
> > reasons platform vendors set MTRRs is so that a system won't hit a
> > machine check when an OS bug leads an access with a wrong cache type.
> >
> > A machine check is hard to analyze and can be seen as a hardware issue
> > by customers. Emulating MTRRs with PAT won't protect from such a bug.
>
> That's seems like a fair and valid concern. This could only happen if
> the OS would have code that would use MTRR, in the case of Linux we'll
> soon be able to vet that this cannot happen.
No, there is no OS support necessary to use MTRR. After firmware sets it
up, CPUs continue to use it without any OS support. I think the Linux
change you are referring is to obsolete legacy interfaces that modify the
MTRR setup. I agree that Linux should not modify MTRR.
> For those type of OSes...
> could it be possible to negotiate or hint to the platform through an
> attribute somehow that the OS has such capability to not use MTRR?
The OS can disable MTRR. However, this can also cause a problem in
firmware, which may rely on MTRR.
> Then, only if this bit is set, the platform could then avoid such MTRR
> settings, and if we have issues you can throw rocks at us.
> And if that's not possible how about a new platform setting that would
> need to be set at the platform level to enable disabling this junk?
> Then only folks who know what they are doing would enable it, and if
> the customer set it, the issue would not be on the platform.
> Could this also be used to prevent SMIs with MTRRs?
ACPI _OSI could be used for firmware to implement some OS-specific features,
but it may be too late for firmware to make major changes and is generally
useless unless OS requirements are described in a spec backed by logo
certification. SMIs are also used for platform management, such as fan
speed control.
Is there any issue for Linux to use MTRR set by firmware?
Thanks,
-Toshi
^ permalink raw reply
* Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez @ 2015-08-06 21:45 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Ingo Molnar, Luis R. Rodriguez, bp, arnd, luto, akpm, linux-pci,
linux-kernel, tomi.valkeinen, mst, toshi.kani, linux-fbdev,
xen-devel, benh
In-Reply-To: <20150722134348.GA10966@google.com>
On Wed, Jul 22, 2015 at 08:43:48AM -0500, Bjorn Helgaas wrote:
> Hi Ingo,
>
> On Wed, Jul 22, 2015 at 10:38:45AM +0200, Ingo Molnar wrote:
> >
> > * Bjorn Helgaas <bhelgaas@google.com> wrote:
> >
> > > > > > Let me know if these are OK or if there are any questions.
> > > > > >
> > > > > > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > > > > > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> > > > >
> > > > > Ingo,
> > > > >
> > > > > Just a friendly reminder. Let me know if there are any issues or questions.
> > > >
> > > > It would be nice to get an Acked-by from Bjorn for the PCI API bits.
> > >
> > > I think the actual code of pci_ioremap_wc() and pci_ioremap_wc_bar() is fine
> > > (although I might have named it pci_ioremap_bar_wc() for consistency).
> > >
> > > I declined to merge or ack them myself because they're obvious extensions of
> > > pci_ioremap() and pci_ioremap_bar(), and I would prefer that they be exported
> > > the same way, i.e., with EXPORT_SYMBOL(), not EXPORT_SYMBOL_GPL().
> >
> > Huh? AFAICS pci_ioremap_bar() has been a _GPL export for a long time:
> > ...
> > (ioremap_wc() is EXPORT_SYMBOL() mostly by accident, it's the odd one out.)
>
> You're right, I was mistaken about pci_ioremap_bar(). But I'm not
> convinced yet that ioremap_wc() is the odd one out. All the interfaces I
> found, with the exception of ioremap_uc() on x86 and pci_ioremap_bar(), are
> EXPORT_SYMBOL(), even the _wc and _wt flavors.
The documentation update I provided on EXPORT_SYMBOL_GPL() which is now
upstream, at *your request* specifically for this series, *acknowledges* these
differences in opinions about new features, but it also clarifies that
positions on EXPORT_SYMBOL_GPL() can be up to developers and maintainers then,
so long as its for *new features*.
So this can be a position to take, and the guidence is there now. You asked for
this.
I acknowledge a subtle topic we seem to have stumbled upon here is what happens
if there is old "related technology" APIs with EXPORT_SYMBPOL(). Let me
elaborate on that, in my effort to provide guidence to reflect some historical
baggage while being apolagetic for those who hold a position of exclusive use
for *any* new functionality with EXPORT_SYMBOL_GPL(), like myself.
You seem to be taking a position of not allowing patches in that express the
freedom to use EXPORT_SYMBOL() because "related technology APIs had used
EXPORT_SYMBOL()". This is rather unfair for a few reasons:
0) This assumes that folks who wrote some old ioremap() calls had a position to
green light proprietary drivers to use them and embrace the idea that
EXPORT_SYMBOL_GPL() is the whitelist. As discussed in *many places* this
cannot be a reasonably general assumption as it does a *huge disservice* to many
people who always have held the position over their code always to not be
usable by proprietary drivers, and in even some cases that EXPORT_SYMBOL_GPL()
is pointless and does more harm than good, to the point they want to throw
tables at you for trying to add EXPORT_SYMBOL_GPL() code. Please consider
this *seriously*, not doing so is unfair to them.
1) Regardless of 0) its unfair to developers who do not want to deal with bug
reports for new features *at all*. Now this is important: one reason to take a
position to use EXPORT_SYMBOL_GPL() for new features even on *related
technology* APIs can be that we *cannot* change older APIs, *even* if consensus
is gathered that we don't want bug reports for certain functionality or
features. That is, even if you think 0) is dodgy there can be a general
consensus and position by maintainers to not want bug reports on certain area
in the kernel. Also using your argument one could always negate this freedom
since EXPORT_SYMBOL() is historically spread out thorugh the entire kernel, so
one could make the argument that "related technology" APIs exist all over the
kernel, thereby denying any use of EXPORT_SYMBOL_GPL() everywhere. This is
really unfair for new developers who start contributing who *do not want*
proprietary drivers to make use of their own new features.
2) Even if you consider 0 and 1) dodgy... we have positions expressed from developers
and maintainers on PAT interfaces with consensus that we don't want to deal with bug
reports for new PAT interfaces for proprietary drivers.
> > Also, FWIIW: I personally got essentially zero feedback and help from proprietary
> > binary kernel module vendors in the past couple of years as x86 maintainer,
> > despite a fair chunk of kernel crashes reported on distro kernels occuring in
> > them...
> >
> > Based on that very negative experience, when we introduce something as complex and
> > as critical as new caching APIs, the last thing I want is to have obscure bugs in
> > binary modules I cannot fix in any reasonable fashion. So even if the parent APIs
> > of new APIs weren't already _GPL exports (as in this case), I'd export them as
> > _GPL in this case.
> >
> > > I think using EXPORT_SYMBOL_GPL to express individual political aims rather than
> > > as a hint about what might be derived work makes us look like zealots, and
> > > that's not my style.
> >
> > As far as I'm concerned it's a pure technological choice: I don't want to export
> > certain types of hard to fix and critical functionality to drivers that I cannot
> > then fix.
>
> That's a good argument that I hadn't heard before (or possibly it was there
> and I missed it).
Actually, that's likely the most common reason for these positions... so yes,
you missed it, but I don't blame you. Another strong reason is the strong
legal value over EXPORT_SYMBOL_GPL(). So folks in old camp 0) above may feel
now the need to be explicit due to the legal value of EXPORT_SYMBOL_GPL().
So let me re-iterate: camp 0) folks may have taken a slightly different
position these days. Also some folks who were maybe on the fence over
"related technology" positions may simply be fed up with proprietary drivers
in general, and they have the freedom to do so and if EXPORT_SYMBOL_GPL()
is a good technical stop-gap that's their choice.
> It would be stronger still if we could change the parent APIs similarly.
Sorry, that cannot happen. It is widely accepted that this was something we
would not do, in fact Linus has held a *strong* position that this would be
highly frowned upon. So think about this -- if you acknowledge that its
sensible for developers or maintainers to not want to deal with bug reports for
hard to fix functionality and we cannot change old APIs to EXPORT_SYMBOL_GPL()
then that in and of itself is a reason then for why some developers and
maintainers have taken the position to accept *new features* to go in with
EXPORT_SYMBOL_GPL(), as a compromise.
Those who do not want to deal with the implications of proprietary drivers only
have the option to make new features EXPORTS_SYMBOL_GPL(). Denying them this
means allowing a slew of crap reports for new features for all of us. It also
is denying anyone the sentiment or change of heart that perhaps enabling
proprietary drivers was a bad idea. Letting them use EXPORTS_SYMBOL_GPL()
enables them to express this sentiment.
> If a proprietary driver can't use pci_ioremap_wc() because
> it's exported _GPL, it's trivial to use ioremap_wc() directly.
That's under the assumption again that people who wrote ioremap_wc()
meant to enable such use. And again, the documentation today does
let folks add new *features* under EXPORT_SYMBOL_GPL() so if it makes
proprietary folks just do a bit more work, why not.
Luis
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: Luis R. Rodriguez @ 2015-08-06 19:55 UTC (permalink / raw)
To: Toshi Kani
Cc: Jan Beulich, Andy Lutomirski, Bjorn Helgaas, Jej B, X86 ML,
Andrew Morton, Ville Syrjälä, Julia Lawall, xen-devel,
Dave Airlie, Ville Syrjälä, Juergen Gross,
Borislav Petkov, Tomi Valkeinen, linux-fbdev,
linux-kernel@vger.kernel.org, linux-media,
linux-pci@vger.kernel.org
In-Reply-To: <CAB=NE6W3=SFTqabeD6gq7JCqFZ7+SBZh7Xa=RteO_8-3P7fbdw@mail.gmail.com>
On Thu, Aug 6, 2015 at 12:53 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> For those type of OSes...
> could it be possible to negotiate or hint to the platform through an
> attribute somehow that the OS has such capability to not use MTRR?
And if that's not possible how about a new platform setting that would
need to be set at the platform level to enable disabling this junk?
Then only folks who know what they are doing would enable it, and if
the customer set it, the issue would not be on the platform.
Luis
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: Luis R. Rodriguez @ 2015-08-06 19:53 UTC (permalink / raw)
To: Toshi Kani
Cc: Jan Beulich, Andy Lutomirski, Bjorn Helgaas, Jej B, X86 ML,
Andrew Morton, Ville Syrjälä, Julia Lawall, xen-devel,
Dave Airlie, Ville Syrjälä, Juergen Gross,
Borislav Petkov, Tomi Valkeinen, linux-fbdev,
linux-kernel@vger.kernel.org, linux-media,
linux-pci@vger.kernel.org
In-Reply-To: <1434128306.11808.97.camel@misato.fc.hp.com>
On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani <toshi.kani@hp.com> wrote:
> On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
>> >>> On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
>> > There are two usages on MTRRs:
>> > 1) MTRR entries set by firmware
>> > 2) MTRR entries set by OS drivers
>> >
>> > We can obsolete 2), but we have no control over 1). As UEFI firmwares
>> > also set this up, this usage will continue to stay. So, we should not
>> > get rid of the MTRR code that looks up the MTRR entries, while we have
>> > no need to modify them.
>> >
>> > Such MTRR entries provide safe guard to /dev/mem, which allows
>> > privileged user to access a range that may require UC mapping while
>> > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
>> > such a case.
>>
>> But it wouldn't be impossible to simply read the MTRRs upon boot,
>> store the information, disable MTRRs, and correctly use PAT to
>> achieve the same effect (i.e. the "blindly maps" part of course
>> would need fixing).
>
> It could be done, but I do not see much benefit of doing it. One of the
> reasons platform vendors set MTRRs is so that a system won't hit a
> machine check when an OS bug leads an access with a wrong cache type.
>
> A machine check is hard to analyze and can be seen as a hardware issue by
> customers. Emulating MTRRs with PAT won't protect from such a bug.
That's seems like a fair and valid concern. This could only happen if
the OS would have code that would use MTRR, in the case of Linux we'll
soon be able to vet that this cannot happen. For those type of OSes...
could it be possible to negotiate or hint to the platform through an
attribute somehow that the OS has such capability to not use MTRR?
Then, only if this bit is set, the platform could then avoid such MTRR
settings, and if we have issues you can throw rocks at us.
Could this also be used to prevent SMIs with MTRRs?
Luis
^ permalink raw reply
* [PATCH 2/2] OMAPDSS: of-dss: omap_dss_find_output_by_port_node() keep port refcount
From: Jyri Sarha @ 2015-08-06 18:41 UTC (permalink / raw)
To: linux-fbdev
The only user of dss_of_port_get_parent_device() function is
omap_dss_find_output_by_port_node() and it assumes the refcount of the
port parameter is not decremented by the call.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/video/fbdev/omap2/dss/dss-of.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c b/drivers/video/fbdev/omap2/dss/dss-of.c
index ab6ef16..43f999d 100644
--- a/drivers/video/fbdev/omap2/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/dss/dss-of.c
@@ -95,7 +95,7 @@ struct device_node *dss_of_port_get_parent_device(struct device_node *port)
if (!port)
return NULL;
- np = of_get_next_parent(port);
+ np = of_get_parent(port);
for (i = 0; i < 2 && np; ++i) {
struct property *prop;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] OMAPDSS: dss-of: Fix node refcount leak in omapdss_of_get_next_port()
From: Jyri Sarha @ 2015-08-06 18:41 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/video/fbdev/omap2/dss/dss-of.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c b/drivers/video/fbdev/omap2/dss/dss-of.c
index 928ee63..ab6ef16 100644
--- a/drivers/video/fbdev/omap2/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/dss/dss-of.c
@@ -60,6 +60,7 @@ omapdss_of_get_next_port(const struct device_node *parent,
}
prev = port;
} while (of_node_cmp(port->name, "port") != 0);
+ of_node_put(ports);
}
return port;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] OMAPDSS: Fix of-node refcount issues
From: Jyri Sarha @ 2015-08-06 18:41 UTC (permalink / raw)
To: linux-fbdev
I found couple of refcounting issues related to OMAP DSS of-node
handling. Second patch should fix the "ERROR: Bad of_node_put() on
/encoder@0/ports/port@1" -problem.
In the long run it would make sense start using of_graph_*() functions
in OMAP DSS too. However the semantics of of_graph_*() functions are
quite different from omapdss_of_*() counterparts. So it better to just
fix these bugs first.
Jyri Sarha (2):
OMAPDSS: dss-of: Fix node refcount leak in omapdss_of_get_next_port()
OMAPDSS: of-dss: omap_dss_find_output_by_port_node() keep port
refcount
drivers/video/fbdev/omap2/dss/dss-of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v2] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
From: Jingoo Han @ 2015-08-06 15:37 UTC (permalink / raw)
To: 'Bjorn Andersson'
Cc: 'Rob Herring', 'Pawel Moll',
'Mark Rutland', 'Ian Campbell',
'Kumar Gala', 'Bryan Wu',
'Richard Purdie', 'Jacek Anaszewski',
'Lee Jones', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', 'Rob Clark', devicetree,
linux-kernel, linux-leds, linux-fbdev, linux-arm-msm,
'Jingoo Han'
In-Reply-To: <1437525889-24928-1-git-send-email-bjorn.andersson@sonymobile.com>
On Wednesday, July 22, 2015 9:45 AM, Bjorn Andersson wrote:
>
> The Qualcomm PM8941 WLED block is used for backlight and should therefor
> be in the backlight framework and not in the LED framework. This moves
> the driver and adapts to the backlight api instead.
>
> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
> Tested-by: Rob Clark <robdclark@gmail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> ---
> .../backlight/pm8941-wled.txt} | 5 +-
> drivers/leds/Kconfig | 8 ---
> drivers/leds/Makefile | 1 -
> drivers/video/backlight/Kconfig | 7 +++
> drivers/video/backlight/Makefile | 1 +
> .../backlight/pm8941-wled.c} | 60 ++++++++++------------
> 6 files changed, 35 insertions(+), 47 deletions(-)
> rename Documentation/devicetree/bindings/{leds/leds-pm8941-wled.txt => video/backlight/pm8941-
> wled.txt} (84%)
> rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c} (90%)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> similarity index 84%
> rename from Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> rename to Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> index a85a964d61f5..424f8444a6cd 100644
> --- a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> @@ -5,10 +5,7 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> -- label: The label for this led
> - See Documentation/devicetree/bindings/leds/common.txt
> -- linux,default-trigger: Default trigger assigned to the LED
> - See Documentation/devicetree/bindings/leds/common.txt
> +- label: The name of the backlight device
> - qcom,cs-out: bool; enable current sink output
> - qcom,cabc: bool; enable content adaptive backlight control
> - qcom,ext-gen: bool; use externally generated modulator signal to dim
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 9ad35f72ab4c..b8d4b965ca2a 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -578,14 +578,6 @@ config LEDS_VERSATILE
> This option enabled support for the LEDs on the ARM Versatile
> and RealView boards. Say Y to enabled these.
>
> -config LEDS_PM8941_WLED
> - tristate "LED support for the Qualcomm PM8941 WLED block"
> - depends on LEDS_CLASS
> - select REGMAP
> - help
> - This option enables support for the 'White' LED block
> - on Qualcomm PM8941 PMICs.
> -
> comment "LED Triggers"
> source "drivers/leds/trigger/Kconfig"
>
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 8d6a24a2f513..abe96d960ebe 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -63,7 +63,6 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> -obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
> obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
>
> # LED SPI Drivers
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 0505b796d743..5ffa4b4e26c0 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -299,6 +299,13 @@ config BACKLIGHT_TOSA
> If you have an Sharp SL-6000 Zaurus say Y to enable a driver
> for its backlight
>
> +config BACKLIGHT_PM8941_WLED
> + tristate "Qualcomm PM8941 WLED Driver"
> + select REGMAP
> + help
> + If you have the Qualcomm PM8941, say Y to enable a driver for the
> + WLED block.
> +
> config BACKLIGHT_SAHARA
> tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
> depends on X86
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index d67073f9d421..16ec534cff30 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
> obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
> obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
> obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> +obj-$(CONFIG_BACKLIGHT_PM8941_WLED) += pm8941-wled.o
> obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
> obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
> obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
> diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
> similarity index 90%
> rename from drivers/leds/leds-pm8941-wled.c
> rename to drivers/video/backlight/pm8941-wled.c
> index bf64a593fbf1..c704c3236034 100644
> --- a/drivers/leds/leds-pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -11,7 +11,7 @@
> */
>
> #include <linux/kernel.h>
> -#include <linux/leds.h>
> +#include <linux/backlight.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> @@ -76,30 +76,29 @@ struct pm8941_wled_config {
> };
>
> struct pm8941_wled {
> + const char *name;
> struct regmap *regmap;
> u16 addr;
>
> - struct led_classdev cdev;
> -
> struct pm8941_wled_config cfg;
> };
>
> -static int pm8941_wled_set(struct led_classdev *cdev,
> - enum led_brightness value)
> +static int pm8941_wled_update_status(struct backlight_device *bl)
> {
> - struct pm8941_wled *wled;
> + struct pm8941_wled *wled = bl_get_data(bl);
> + u16 val = bl->props.brightness;
> u8 ctrl = 0;
> - u16 val;
> int rc;
> int i;
>
> - wled = container_of(cdev, struct pm8941_wled, cdev);
> + if (bl->props.power != FB_BLANK_UNBLANK ||
> + bl->props.fb_blank != FB_BLANK_UNBLANK ||
> + bl->props.state & BL_CORE_FBBLANK)
> + val = 0;
>
> - if (value != 0)
> + if (val != 0)
> ctrl = PM8941_WLED_REG_MOD_EN_BIT;
>
> - val = value * PM8941_WLED_REG_VAL_MAX / LED_FULL;
> -
> rc = regmap_update_bits(wled->regmap,
> wled->addr + PM8941_WLED_REG_MOD_EN,
> PM8941_WLED_REG_MOD_EN_MASK, ctrl);
> @@ -128,16 +127,6 @@ static int pm8941_wled_set(struct led_classdev *cdev,
> return rc;
> }
>
> -static void pm8941_wled_set_brightness(struct led_classdev *cdev,
> - enum led_brightness value)
> -{
> - if (pm8941_wled_set(cdev, value)) {
> - dev_err(cdev->dev, "Unable to set brightness\n");
> - return;
> - }
> - cdev->brightness = value;
> -}
> -
> static int pm8941_wled_setup(struct pm8941_wled *wled)
> {
> int rc;
> @@ -336,12 +325,9 @@ static int pm8941_wled_configure(struct pm8941_wled *wled, struct device *dev)
> }
> wled->addr = val;
>
> - rc = of_property_read_string(dev->of_node, "label", &wled->cdev.name);
> + rc = of_property_read_string(dev->of_node, "label", &wled->name);
> if (rc)
> - wled->cdev.name = dev->of_node->name;
> -
> - wled->cdev.default_trigger = of_get_property(dev->of_node,
> - "linux,default-trigger", NULL);
> + wled->name = dev->of_node->name;
>
> *cfg = pm8941_wled_config_defaults;
> for (i = 0; i < ARRAY_SIZE(u32_opts); ++i) {
> @@ -377,8 +363,14 @@ static int pm8941_wled_configure(struct pm8941_wled *wled, struct device *dev)
> return 0;
> }
>
> +static const struct backlight_ops pm8941_wled_ops = {
> + .update_status = pm8941_wled_update_status,
> +};
> +
> static int pm8941_wled_probe(struct platform_device *pdev)
> {
> + struct backlight_properties props;
> + struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> int rc;
> @@ -403,13 +395,14 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> if (rc)
> return rc;
>
> - wled->cdev.brightness_set = pm8941_wled_set_brightness;
> -
> - rc = devm_led_classdev_register(&pdev->dev, &wled->cdev);
> - if (rc)
> - return rc;
> -
> - platform_set_drvdata(pdev, wled);
> + memset(&props, 0, sizeof(struct backlight_properties));
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> + bl = devm_backlight_device_register(&pdev->dev, wled->name,
> + &pdev->dev, wled,
> + &pm8941_wled_ops, &props);
> + if (IS_ERR(bl))
> + return PTR_ERR(bl);
>
> return 0;
> };
> @@ -432,4 +425,3 @@ module_platform_driver(pm8941_wled_driver);
>
> MODULE_DESCRIPTION("pm8941 wled driver");
> MODULE_LICENSE("GPL v2");
> -MODULE_ALIAS("platform:pm8941-wled");
> --
> 1.8.2.2
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Stefano Stabellini @ 2015-08-06 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C34250.3040801@citrix.com>
On Thu, 6 Aug 2015, Julien Grall wrote:
> On 06/08/15 12:06, Stefano Stabellini wrote:
> > On Thu, 6 Aug 2015, Julien Grall wrote:
> >> Hi,
> >>
> >>
> >> On 04/08/15 19:12, Julien Grall wrote:
> >>> diff --git a/include/xen/page.h b/include/xen/page.h
> >>> index c5ed20b..e7e1425 100644
> >>> --- a/include/xen/page.h
> >>> +++ b/include/xen/page.h
> >>> @@ -3,9 +3,9 @@
> >>>
> >>> #include <asm/xen/page.h>
> >>>
> >>> -static inline unsigned long page_to_mfn(struct page *page)
> >>> +static inline unsigned long page_to_gfn(struct page *page)
> >>> {
> >>> - return pfn_to_mfn(page_to_pfn(page));
> >>> + return pfn_to_gfn(page_to_pfn(page));
> >>> }
> >>
> >> I've just noticed that there is a function gfn_to_page used for KVM.
> >>
> >> Maybe I should rename page_to_gfn to xen_page_to_gfn to avoid confusion
> >> with KVM one?
> >
> > Yeah, prepending xen would help to avoid namespace pollution.
>
> Will do. May I keep your Reviewed-by for this mechanical change?
Yes
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-08-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1508061205190.11337@kaball.uk.xensource.com>
On 06/08/15 12:06, Stefano Stabellini wrote:
> On Thu, 6 Aug 2015, Julien Grall wrote:
>> Hi,
>>
>>
>> On 04/08/15 19:12, Julien Grall wrote:
>>> diff --git a/include/xen/page.h b/include/xen/page.h
>>> index c5ed20b..e7e1425 100644
>>> --- a/include/xen/page.h
>>> +++ b/include/xen/page.h
>>> @@ -3,9 +3,9 @@
>>>
>>> #include <asm/xen/page.h>
>>>
>>> -static inline unsigned long page_to_mfn(struct page *page)
>>> +static inline unsigned long page_to_gfn(struct page *page)
>>> {
>>> - return pfn_to_mfn(page_to_pfn(page));
>>> + return pfn_to_gfn(page_to_pfn(page));
>>> }
>>
>> I've just noticed that there is a function gfn_to_page used for KVM.
>>
>> Maybe I should rename page_to_gfn to xen_page_to_gfn to avoid confusion
>> with KVM one?
>
> Yeah, prepending xen would help to avoid namespace pollution.
Will do. May I keep your Reviewed-by for this mechanical change?
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Stefano Stabellini @ 2015-08-06 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C33E4E.4050704@citrix.com>
On Thu, 6 Aug 2015, Julien Grall wrote:
> Hi,
>
>
> On 04/08/15 19:12, Julien Grall wrote:
> > diff --git a/include/xen/page.h b/include/xen/page.h
> > index c5ed20b..e7e1425 100644
> > --- a/include/xen/page.h
> > +++ b/include/xen/page.h
> > @@ -3,9 +3,9 @@
> >
> > #include <asm/xen/page.h>
> >
> > -static inline unsigned long page_to_mfn(struct page *page)
> > +static inline unsigned long page_to_gfn(struct page *page)
> > {
> > - return pfn_to_mfn(page_to_pfn(page));
> > + return pfn_to_gfn(page_to_pfn(page));
> > }
>
> I've just noticed that there is a function gfn_to_page used for KVM.
>
> Maybe I should rename page_to_gfn to xen_page_to_gfn to avoid confusion
> with KVM one?
Yeah, prepending xen would help to avoid namespace pollution.
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-08-06 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438711972-18752-5-git-send-email-julien.grall@citrix.com>
Hi,
On 04/08/15 19:12, Julien Grall wrote:
> diff --git a/include/xen/page.h b/include/xen/page.h
> index c5ed20b..e7e1425 100644
> --- a/include/xen/page.h
> +++ b/include/xen/page.h
> @@ -3,9 +3,9 @@
>
> #include <asm/xen/page.h>
>
> -static inline unsigned long page_to_mfn(struct page *page)
> +static inline unsigned long page_to_gfn(struct page *page)
> {
> - return pfn_to_mfn(page_to_pfn(page));
> + return pfn_to_gfn(page_to_pfn(page));
> }
I've just noticed that there is a function gfn_to_page used for KVM.
Maybe I should rename page_to_gfn to xen_page_to_gfn to avoid confusion
with KVM one?
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix sparse warning for lock
From: Dan Carpenter @ 2015-08-05 22:34 UTC (permalink / raw)
To: Peng Fan
Cc: sudipm.mukherjee, teddy.wang, gregkh, devel, linux-fbdev,
linux-kernel
In-Reply-To: <1438781204-13283-1-git-send-email-van.freenix@gmail.com>
On Wed, Aug 05, 2015 at 09:26:44PM +0800, Peng Fan wrote:
> Use __acquire() and __release() in the right place to silence the sparse
> lock checking warning.
>
> drivers/staging/sm750fb/sm750.c:177:13: warning: context imbalance in 'lynxfb_ops_fillrect' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:243:9: warning: context imbalance in 'lynxfb_ops_copyarea' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:247:13: warning: context imbalance in 'lynxfb_ops_imageblit' - different lock contexts for basic block
>
Sparse is really bad at locking stuff. Smatch is also really bad for
locking and I have been promising to re-write that check for years, but
I take comfort always in the fact that at least it's not as bad as
Sparse.
You should pretty much ignore Sparse locking warnings.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix sparse warning for lock
From: Greg KH @ 2015-08-05 19:01 UTC (permalink / raw)
To: Peng Fan; +Cc: sudipm.mukherjee, teddy.wang, devel, linux-fbdev, linux-kernel
In-Reply-To: <1438781204-13283-1-git-send-email-van.freenix@gmail.com>
On Wed, Aug 05, 2015 at 09:26:44PM +0800, Peng Fan wrote:
> Use __acquire() and __release() in the right place to silence the sparse
> lock checking warning.
>
> drivers/staging/sm750fb/sm750.c:177:13: warning: context imbalance in 'lynxfb_ops_fillrect' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:243:9: warning: context imbalance in 'lynxfb_ops_copyarea' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:247:13: warning: context imbalance in 'lynxfb_ops_imageblit' - different lock contexts for basic block
>
> Signed-off-by: Peng Fan <van.freenix@gmail.com>
> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> Cc: Teddy Wang <teddy.wang@siliconmotion.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/staging/sm750fb/sm750.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 8e201f1..5ba1c06 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -203,6 +203,8 @@ static void lynxfb_ops_fillrect(struct fb_info *info,
> */
> if (share->dual)
> spin_lock(&share->slock);
> + else
> + __acquire(&share->slock);
That's horrid, please don't do stuff like this just to make a static
checker "quiet".
greg k-h
^ permalink raw reply
* Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Wei Liu @ 2015-08-05 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438711972-18752-5-git-send-email-julien.grall@citrix.com>
On Tue, Aug 04, 2015 at 07:12:48PM +0100, Julien Grall wrote:
[...]
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 7d50711..3b7b7c3 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
> } else {
> copy_gop->source.domid = DOMID_SELF;
> copy_gop->source.u.gmfn > - virt_to_mfn(page_address(page));
> + virt_to_gfn(page_address(page));
> }
> copy_gop->source.offset = offset;
>
> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>
> queue->tx_copy_ops[*copy_ops].dest.u.gmfn > - virt_to_mfn(skb->data);
> + virt_to_gfn(skb->data);
> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> queue->tx_copy_ops[*copy_ops].dest.offset > offset_in_page(skb->data);
Acked-by: Wei Liu <wei.liu2@citrix.com>
^ permalink raw reply
* Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Dmitry Torokhov @ 2015-08-05 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1508051108100.11337@kaball.uk.xensource.com>
On Wed, Aug 05, 2015 at 11:08:55AM +0100, Stefano Stabellini wrote:
> On Tue, 4 Aug 2015, Julien Grall wrote:
> > Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
> > is meant, I suspect this is because the first support for Xen was for
> > PV. This resulted in some misimplementation of helpers on ARM and
> > confused developers about the expected behavior.
> >
> > For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
> > Although, if we look at the implementation on x86, it's returning a GFN.
> >
> > For clarity and avoid new confusion, replace any reference to mfn with
> > gfn in any helpers used by PV drivers. The x86 code will still keep some
> > reference of pfn_to_mfn but exclusively for PV (a BUG_ON has been added
> > to ensure this). No changes as been made in the hypercall field, even
> > though they may be invalid, in order to keep the same as the defintion
> > in xen repo.
> >
> > Take also the opportunity to simplify simple construction such
> > as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
> > will come in follow-up patches.
> >
> > [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;hç58ed14f390342513405dd766e874934573e6cb
> >
> > Signed-off-by: Julien Grall <julien.grall@citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Cc: David Vrabel <david.vrabel@citrix.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: x86@kernel.org
> > Cc: "Roger Pau Monné" <roger.pau@citrix.com>
> > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Juergen Gross <jgross@suse.com>
> > Cc: "James E.J. Bottomley" <JBottomley@odin.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Jiri Slaby <jslaby@suse.com>
> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: linux-input@vger.kernel.org
> > Cc: netdev@vger.kernel.org
> > Cc: linux-scsi@vger.kernel.org
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
>
> Aside from the x86 bits:
>
> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Not really important, but just in case anyone waits for my ack on input
bits:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] staging: sm750fb: fix sparse warning for lock
From: Peng Fan @ 2015-08-05 13:26 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, devel, linux-kernel, van.freenix
In-Reply-To: <1425934628-3717-1-git-send-email-lstoakes@gmail.com>
Use __acquire() and __release() in the right place to silence the sparse
lock checking warning.
drivers/staging/sm750fb/sm750.c:177:13: warning: context imbalance in 'lynxfb_ops_fillrect' - different lock contexts for basic block
drivers/staging/sm750fb/sm750.c:243:9: warning: context imbalance in 'lynxfb_ops_copyarea' - different lock contexts for basic block
drivers/staging/sm750fb/sm750.c:247:13: warning: context imbalance in 'lynxfb_ops_imageblit' - different lock contexts for basic block
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/sm750fb/sm750.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 8e201f1..5ba1c06 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -203,6 +203,8 @@ static void lynxfb_ops_fillrect(struct fb_info *info,
*/
if (share->dual)
spin_lock(&share->slock);
+ else
+ __acquire(&share->slock);
share->accel.de_fillrect(&share->accel,
base, pitch, Bpp,
@@ -211,6 +213,8 @@ static void lynxfb_ops_fillrect(struct fb_info *info,
color, rop);
if (share->dual)
spin_unlock(&share->slock);
+ else
+ __release(&share->slock);
}
static void lynxfb_ops_copyarea(struct fb_info *info,
@@ -235,6 +239,8 @@ static void lynxfb_ops_copyarea(struct fb_info *info,
*/
if (share->dual)
spin_lock(&share->slock);
+ else
+ __acquire(&share->slock);
share->accel.de_copyarea(&share->accel,
base, pitch, region->sx, region->sy,
@@ -242,6 +248,8 @@ static void lynxfb_ops_copyarea(struct fb_info *info,
region->width, region->height, HW_ROP2_COPY);
if (share->dual)
spin_unlock(&share->slock);
+ else
+ __release(&share->slock);
}
static void lynxfb_ops_imageblit(struct fb_info *info,
@@ -282,6 +290,8 @@ _do_work:
*/
if (share->dual)
spin_lock(&share->slock);
+ else
+ __acquire(&share->slock);
share->accel.de_imageblit(&share->accel,
image->data, image->width>>3, 0,
@@ -291,6 +301,8 @@ _do_work:
fgcol, bgcol, HW_ROP2_COPY);
if (share->dual)
spin_unlock(&share->slock);
+ else
+ __release(&share->slock);
}
static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
--
1.8.4
^ permalink raw reply related
* Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Boris Ostrovsky @ 2015-08-05 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C2029C.9030705@citrix.com>
On 08/05/2015 08:33 AM, Julien Grall wrote:
> On 05/08/15 13:19, Boris Ostrovsky wrote:
>> On 08/05/2015 06:51 AM, Julien Grall wrote:
>>>>> diff --git a/drivers/video/fbdev/xen-fbfront.c
>>>>> b/drivers/video/fbdev/xen-fbfront.c
>>>>> index 09dc447..25e3cce 100644
>>>>> --- a/drivers/video/fbdev/xen-fbfront.c
>>>>> +++ b/drivers/video/fbdev/xen-fbfront.c
>>>>> @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
>>>>> static unsigned long vmalloc_to_mfn(void *address)
>>>>> {
>>>>> - return pfn_to_mfn(vmalloc_to_pfn(address));
>>>>> + return pfn_to_gfn(vmalloc_to_pfn(address));
>>>>> }
>>>> Are you sure? This will return vmalloc_to_pfn(address)).
>>> I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
>>>
>>> If so, it will be only the case on auto-translated case (because pfn =
>>> gfn). In the case of PV, the mfn will be returned.
>> How will mfn be returned on PV when pfn_to_gfn() is an identity function?
>>
>> static inline unsigned long pfn_to_gfn(unsigned long pfn)
>> {
>> return pfn;
>> }
> The identity function is only for ARM guest which are always
> auto-translated (arch/arm/include/asm/xen/page.h).
>
> The x86 version contains a check if the guest is auto-translated or not
> (arch/x86/include/asm/xen/page.):
>
> static inline unsigned long pfn_to_gfn(unsigned long pfn)
> {
> if (xen_feature(XENFEAT_auto_translated_physmap))
> return pfn;
> else
> return pfn_to_mfn(pfn);
> }
Of course --- I was looking at the top of the patch and didn't realize
it was ARM changes. Sorry for the noise.
-boris
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-08-05 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C1FF54.8060409@oracle.com>
On 05/08/15 13:19, Boris Ostrovsky wrote:
> On 08/05/2015 06:51 AM, Julien Grall wrote:
>>
>>>> diff --git a/drivers/video/fbdev/xen-fbfront.c
>>>> b/drivers/video/fbdev/xen-fbfront.c
>>>> index 09dc447..25e3cce 100644
>>>> --- a/drivers/video/fbdev/xen-fbfront.c
>>>> +++ b/drivers/video/fbdev/xen-fbfront.c
>>>> @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
>>>> static unsigned long vmalloc_to_mfn(void *address)
>>>> {
>>>> - return pfn_to_mfn(vmalloc_to_pfn(address));
>>>> + return pfn_to_gfn(vmalloc_to_pfn(address));
>>>> }
>>> Are you sure? This will return vmalloc_to_pfn(address)).
>> I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
>>
>> If so, it will be only the case on auto-translated case (because pfn =
>> gfn). In the case of PV, the mfn will be returned.
>
> How will mfn be returned on PV when pfn_to_gfn() is an identity function?
>
> static inline unsigned long pfn_to_gfn(unsigned long pfn)
> {
> return pfn;
> }
The identity function is only for ARM guest which are always
auto-translated (arch/arm/include/asm/xen/page.h).
The x86 version contains a check if the guest is auto-translated or not
(arch/x86/include/asm/xen/page.):
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_auto_translated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Boris Ostrovsky @ 2015-08-05 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C1EA95.5060504@citrix.com>
On 08/05/2015 06:51 AM, Julien Grall wrote:
>
>>> diff --git a/drivers/video/fbdev/xen-fbfront.c
>>> b/drivers/video/fbdev/xen-fbfront.c
>>> index 09dc447..25e3cce 100644
>>> --- a/drivers/video/fbdev/xen-fbfront.c
>>> +++ b/drivers/video/fbdev/xen-fbfront.c
>>> @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
>>> static unsigned long vmalloc_to_mfn(void *address)
>>> {
>>> - return pfn_to_mfn(vmalloc_to_pfn(address));
>>> + return pfn_to_gfn(vmalloc_to_pfn(address));
>>> }
>> Are you sure? This will return vmalloc_to_pfn(address)).
> I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
>
> If so, it will be only the case on auto-translated case (because pfn =
> gfn). In the case of PV, the mfn will be returned.
How will mfn be returned on PV when pfn_to_gfn() is an identity function?
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
return pfn;
}
-boris
>
> Although, this function is misnamed. It's fixed in a follow-up patch
> (see #6) because it's required more renaming than this function. I
> didn't want to add such changes within this patch.
>
> Regards,
>
^ permalink raw reply
* Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-08-05 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C147DD.7000600@oracle.com>
Hi Boris,
On 05/08/15 00:16, Boris Ostrovsky wrote:
> On 08/04/2015 02:12 PM, Julien Grall wrote:
>> /*
>> * We detect special mappings in one of two ways:
>> @@ -217,9 +232,13 @@ static inline unsigned long
>> bfn_to_local_pfn(unsigned long mfn)
>> /* VIRT <-> MACHINE conversion */
>> #define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v))))
>> -#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
>> #define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
>> #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
>> +#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
>
> This looks like unnecessary change.
Right, I made the mistake when I re-introduced virt_to_mfn in this
version. It was dropped in the previous one.
>> diff --git a/drivers/video/fbdev/xen-fbfront.c
>> b/drivers/video/fbdev/xen-fbfront.c
>> index 09dc447..25e3cce 100644
>> --- a/drivers/video/fbdev/xen-fbfront.c
>> +++ b/drivers/video/fbdev/xen-fbfront.c
>> @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
>> static unsigned long vmalloc_to_mfn(void *address)
>> {
>> - return pfn_to_mfn(vmalloc_to_pfn(address));
>> + return pfn_to_gfn(vmalloc_to_pfn(address));
>> }
>
> Are you sure? This will return vmalloc_to_pfn(address)).
I guess you mean vmalloc_to_mfn will return vmalloc_to_pfn?
If so, it will be only the case on auto-translated case (because pfn =
gfn). In the case of PV, the mfn will be returned.
Although, this function is misnamed. It's fixed in a follow-up patch
(see #6) because it's required more renaming than this function. I
didn't want to add such changes within this patch.
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Stefano Stabellini @ 2015-08-05 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438711972-18752-5-git-send-email-julien.grall@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 22710 bytes --]
On Tue, 4 Aug 2015, Julien Grall wrote:
> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
> is meant, I suspect this is because the first support for Xen was for
> PV. This resulted in some misimplementation of helpers on ARM and
> confused developers about the expected behavior.
>
> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
> Although, if we look at the implementation on x86, it's returning a GFN.
>
> For clarity and avoid new confusion, replace any reference to mfn with
> gfn in any helpers used by PV drivers. The x86 code will still keep some
> reference of pfn_to_mfn but exclusively for PV (a BUG_ON has been added
> to ensure this). No changes as been made in the hypercall field, even
> though they may be invalid, in order to keep the same as the defintion
> in xen repo.
>
> Take also the opportunity to simplify simple construction such
> as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
> will come in follow-up patches.
>
> [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
>
> Signed-off-by: Julien Grall <julien.grall@citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: "Roger Pau Monné" <roger.pau@citrix.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: "James E.J. Bottomley" <JBottomley@odin.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-input@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-scsi@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Aside from the x86 bits:
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Note that I've re-introduced mfn_to_pfn & co only for x86 PV code.
> The helpers contain a BUG_ON to ensure that it's never called for
> auto-translated guests. I did as best as my can to determine whether
> mfn or gfn helpers should be used. Although, I haven't tried to boot
> it.
>
> It may be possible to do further cleanup in the mmu.c where I found
> some check to auto-translated. I'm not sure why given that the pvmmu
> callback are only used for non-auto translated guest.
>
> Finally, given those changes, I didn't retain the Reviewed-by/Acked-by.
>
> Changes in v2:
> - Give directly the URL to the commit rather than the commit ID
> - xenstored_local_init: keep the cast to void *
> - Typoes
> - Keep pfn_to_mfn for x86 and PV-only. The *mfn* helpers are
> used in arch/x86/xen for enlighten.c, mmu.c, p2m.c, setup.c,
> smp.c and mm.c
> ---
> arch/arm/include/asm/xen/page.h | 13 +++++++------
> arch/x86/include/asm/xen/page.h | 33 ++++++++++++++++++++++++++-------
> arch/x86/xen/smp.c | 2 +-
> drivers/block/xen-blkfront.c | 6 +++---
> drivers/input/misc/xen-kbdfront.c | 4 ++--
> drivers/net/xen-netback/netback.c | 4 ++--
> drivers/net/xen-netfront.c | 8 ++++----
> drivers/scsi/xen-scsifront.c | 8 +++-----
> drivers/tty/hvc/hvc_xen.c | 5 +++--
> drivers/video/fbdev/xen-fbfront.c | 4 ++--
> drivers/xen/balloon.c | 2 +-
> drivers/xen/events/events_base.c | 2 +-
> drivers/xen/events/events_fifo.c | 4 ++--
> drivers/xen/gntalloc.c | 3 ++-
> drivers/xen/manage.c | 2 +-
> drivers/xen/tmem.c | 4 ++--
> drivers/xen/xenbus/xenbus_client.c | 2 +-
> drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
> drivers/xen/xenbus/xenbus_probe.c | 8 +++-----
> include/xen/page.h | 4 ++--
> 20 files changed, 69 insertions(+), 51 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 087d86e..51e5bf1 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -34,14 +34,15 @@ typedef struct xpaddr {
> unsigned long __pfn_to_mfn(unsigned long pfn);
> extern struct rb_root phys_to_mach;
>
> -static inline unsigned long pfn_to_mfn(unsigned long pfn)
> +/* Pseudo-physical <-> Guest conversion */
> +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> {
> return pfn;
> }
>
> -static inline unsigned long mfn_to_pfn(unsigned long mfn)
> +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> {
> - return mfn;
> + return gfn;
> }
>
> /* Pseudo-physical <-> BUS conversion */
> @@ -65,9 +66,9 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
>
> #define bfn_to_local_pfn(bfn) bfn_to_pfn(bfn)
>
> -/* VIRT <-> MACHINE conversion */
> -#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> -#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> +/* VIRT <-> GUEST conversion */
> +#define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v)))
> +#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << PAGE_SHIFT))
>
> /* Only used in PV code. But ARM guests are always HVM. */
> static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 8ba04b8..c2da42f 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -103,8 +103,7 @@ static inline unsigned long pfn_to_mfn(unsigned long pfn)
> {
> unsigned long mfn;
>
> - if (xen_feature(XENFEAT_auto_translated_physmap))
> - return pfn;
> + BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
>
> mfn = __pfn_to_mfn(pfn);
>
> @@ -149,8 +148,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
> {
> unsigned long pfn;
>
> - if (xen_feature(XENFEAT_auto_translated_physmap))
> - return mfn;
> + BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
>
> pfn = mfn_to_pfn_no_overrides(mfn);
> if (__pfn_to_mfn(pfn) != mfn)
> @@ -178,9 +176,26 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
> return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
> }
>
> +/* Pseudo-physical <-> Guest conversion */
> +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> +{
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return pfn;
> + else
> + return pfn_to_mfn(pfn);
> +}
> +
> +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> +{
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + return gfn;
> + else
> + return mfn_to_pfn(gfn);
> +}
> +
> /* Pseudo-physical <-> Bus conversion */
> -#define pfn_to_bfn(pfn) pfn_to_mfn(pfn)
> -#define bfn_to_pfn(bfn) mfn_to_pfn(bfn)
> +#define pfn_to_bfn(pfn) pfn_to_gfn(pfn)
> +#define bfn_to_pfn(bfn) gfn_to_pfn(bfn)
>
> /*
> * We detect special mappings in one of two ways:
> @@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long mfn)
>
> /* VIRT <-> MACHINE conversion */
> #define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v))))
> -#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
> #define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> +#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
> +
> +/* VIRT <-> GUEST conversion */
> +#define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v)))
> +#define gfn_to_virt(g) (__va(gfn_to_pfn(g) << PAGE_SHIFT))
>
> static inline unsigned long pte_mfn(pte_t pte)
> {
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 8648438..1e0931b 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -429,7 +429,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
> }
> #endif
> ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> - ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> + ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_gfn(swapper_pg_dir));
> if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
> BUG();
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 6d89ed3..2e541a4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -247,7 +247,7 @@ static struct grant *get_grant(grant_ref_t *gref_head,
> struct blkfront_info *info)
> {
> struct grant *gnt_list_entry;
> - unsigned long buffer_mfn;
> + unsigned long buffer_gfn;
>
> BUG_ON(list_empty(&info->grants));
> gnt_list_entry = list_first_entry(&info->grants, struct grant,
> @@ -266,10 +266,10 @@ static struct grant *get_grant(grant_ref_t *gref_head,
> BUG_ON(!pfn);
> gnt_list_entry->pfn = pfn;
> }
> - buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
> + buffer_gfn = pfn_to_gfn(gnt_list_entry->pfn);
> gnttab_grant_foreign_access_ref(gnt_list_entry->gref,
> info->xbdev->otherend_id,
> - buffer_mfn, 0);
> + buffer_gfn, 0);
> return gnt_list_entry;
> }
>
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 95599e4..23d0549 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -232,7 +232,7 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
> struct xenbus_transaction xbt;
>
> ret = gnttab_grant_foreign_access(dev->otherend_id,
> - virt_to_mfn(info->page), 0);
> + virt_to_gfn(info->page), 0);
> if (ret < 0)
> return ret;
> info->gref = ret;
> @@ -255,7 +255,7 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
> goto error_irqh;
> }
> ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
> - virt_to_mfn(info->page));
> + virt_to_gfn(info->page));
> if (ret)
> goto error_xenbus;
> ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 7d50711..3b7b7c3 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
> } else {
> copy_gop->source.domid = DOMID_SELF;
> copy_gop->source.u.gmfn =
> - virt_to_mfn(page_address(page));
> + virt_to_gfn(page_address(page));
> }
> copy_gop->source.offset = offset;
>
> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>
> queue->tx_copy_ops[*copy_ops].dest.u.gmfn =
> - virt_to_mfn(skb->data);
> + virt_to_gfn(skb->data);
> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> queue->tx_copy_ops[*copy_ops].dest.offset =
> offset_in_page(skb->data);
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index f948c46..5cdab73 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -291,7 +291,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
> struct sk_buff *skb;
> unsigned short id;
> grant_ref_t ref;
> - unsigned long pfn;
> + unsigned long gfn;
> struct xen_netif_rx_request *req;
>
> skb = xennet_alloc_one_rx_buffer(queue);
> @@ -307,12 +307,12 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
> BUG_ON((signed short)ref < 0);
> queue->grant_rx_ref[id] = ref;
>
> - pfn = page_to_pfn(skb_frag_page(&skb_shinfo(skb)->frags[0]));
> + gfn = page_to_gfn(skb_frag_page(&skb_shinfo(skb)->frags[0]));
>
> req = RING_GET_REQUEST(&queue->rx, req_prod);
> gnttab_grant_foreign_access_ref(ref,
> queue->info->xbdev->otherend_id,
> - pfn_to_mfn(pfn),
> + gfn,
> 0);
>
> req->id = id;
> @@ -431,7 +431,7 @@ static struct xen_netif_tx_request *xennet_make_one_txreq(
> BUG_ON((signed short)ref < 0);
>
> gnttab_grant_foreign_access_ref(ref, queue->info->xbdev->otherend_id,
> - page_to_mfn(page), GNTMAP_readonly);
> + page_to_gfn(page), GNTMAP_readonly);
>
> queue->tx_skbs[id].skb = skb;
> queue->grant_tx_page[id] = page;
> diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
> index fad22ca..cdf00d1 100644
> --- a/drivers/scsi/xen-scsifront.c
> +++ b/drivers/scsi/xen-scsifront.c
> @@ -377,7 +377,6 @@ static int map_data_for_request(struct vscsifrnt_info *info,
> unsigned int data_len = scsi_bufflen(sc);
> unsigned int data_grants = 0, seg_grants = 0;
> struct scatterlist *sg;
> - unsigned long mfn;
> struct scsiif_request_segment *seg;
>
> ring_req->nr_segments = 0;
> @@ -420,9 +419,8 @@ static int map_data_for_request(struct vscsifrnt_info *info,
> ref = gnttab_claim_grant_reference(&gref_head);
> BUG_ON(ref == -ENOSPC);
>
> - mfn = pfn_to_mfn(page_to_pfn(page));
> gnttab_grant_foreign_access_ref(ref,
> - info->dev->otherend_id, mfn, 1);
> + info->dev->otherend_id, page_to_gfn(page), 1);
> shadow->gref[ref_cnt] = ref;
> ring_req->seg[ref_cnt].gref = ref;
> ring_req->seg[ref_cnt].offset = (uint16_t)off;
> @@ -454,9 +452,9 @@ static int map_data_for_request(struct vscsifrnt_info *info,
> ref = gnttab_claim_grant_reference(&gref_head);
> BUG_ON(ref == -ENOSPC);
>
> - mfn = pfn_to_mfn(page_to_pfn(page));
> gnttab_grant_foreign_access_ref(ref,
> - info->dev->otherend_id, mfn, grant_ro);
> + info->dev->otherend_id, page_to_gfn(page),
> + grant_ro);
>
> shadow->gref[ref_cnt] = ref;
> seg->gref = ref;
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index a9d837f..efe5124 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -265,7 +265,8 @@ static int xen_pv_console_init(void)
> return 0;
> }
> info->evtchn = xen_start_info->console.domU.evtchn;
> - info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
> + /* GFN == MFN for PV guest */
> + info->intf = gfn_to_virt(xen_start_info->console.domU.mfn);
> info->vtermno = HVC_COOKIE;
>
> spin_lock(&xencons_lock);
> @@ -390,7 +391,7 @@ static int xencons_connect_backend(struct xenbus_device *dev,
> if (IS_ERR(info->hvc))
> return PTR_ERR(info->hvc);
> if (xen_pv_domain())
> - mfn = virt_to_mfn(info->intf);
> + mfn = virt_to_gfn(info->intf);
> else
> mfn = __pa(info->intf) >> PAGE_SHIFT;
> ret = gnttab_alloc_grant_references(1, &gref_head);
> diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
> index 09dc447..25e3cce 100644
> --- a/drivers/video/fbdev/xen-fbfront.c
> +++ b/drivers/video/fbdev/xen-fbfront.c
> @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
>
> static unsigned long vmalloc_to_mfn(void *address)
> {
> - return pfn_to_mfn(vmalloc_to_pfn(address));
> + return pfn_to_gfn(vmalloc_to_pfn(address));
> }
>
> static void xenfb_init_shared_page(struct xenfb_info *info,
> @@ -586,7 +586,7 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
> goto unbind_irq;
> }
> ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
> - virt_to_mfn(info->page));
> + virt_to_gfn(info->page));
> if (ret)
> goto error_xenbus;
> ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index bf4a23c..5df28cd 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -441,7 +441,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> /* Update direct mapping, invalidate P2M, and add to balloon. */
> for (i = 0; i < nr_pages; i++) {
> pfn = frame_list[i];
> - frame_list[i] = pfn_to_mfn(pfn);
> + frame_list[i] = pfn_to_gfn(pfn);
> page = pfn_to_page(pfn);
>
> #ifdef CONFIG_XEN_HAVE_PVMMU
> diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
> index 1495ecc..10fd9c6 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -1694,7 +1694,7 @@ void __init xen_init_IRQ(void)
> struct physdev_pirq_eoi_gmfn eoi_gmfn;
>
> pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> - eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> + eoi_gmfn.gmfn = virt_to_gfn(pirq_eoi_map);
> rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
> /* TODO: No PVH support for PIRQ EOI */
> if (rc != 0) {
> diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
> index 6df8aac..2e55e90 100644
> --- a/drivers/xen/events/events_fifo.c
> +++ b/drivers/xen/events/events_fifo.c
> @@ -111,7 +111,7 @@ static int init_control_block(int cpu,
> for (i = 0; i < EVTCHN_FIFO_MAX_QUEUES; i++)
> q->head[i] = 0;
>
> - init_control.control_gfn = virt_to_mfn(control_block);
> + init_control.control_gfn = virt_to_gfn(control_block);
> init_control.offset = 0;
> init_control.vcpu = cpu;
>
> @@ -167,7 +167,7 @@ static int evtchn_fifo_setup(struct irq_info *info)
> /* Mask all events in this page before adding it. */
> init_array_page(array_page);
>
> - expand_array.array_gfn = virt_to_mfn(array_page);
> + expand_array.array_gfn = virt_to_gfn(array_page);
>
> ret = HYPERVISOR_event_channel_op(EVTCHNOP_expand_array, &expand_array);
> if (ret < 0)
> diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
> index e53fe19..13e1458 100644
> --- a/drivers/xen/gntalloc.c
> +++ b/drivers/xen/gntalloc.c
> @@ -142,7 +142,8 @@ static int add_grefs(struct ioctl_gntalloc_alloc_gref *op,
>
> /* Grant foreign access to the page. */
> rc = gnttab_grant_foreign_access(op->domid,
> - pfn_to_mfn(page_to_pfn(gref->page)), readonly);
> + page_to_gfn(gref->page),
> + readonly);
> if (rc < 0)
> goto undo;
> gref_ids[i] = gref->gref_id = rc;
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index d10effe..e12bd36 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -80,7 +80,7 @@ static int xen_suspend(void *data)
> * is resuming in a new domain.
> */
> si->cancelled = HYPERVISOR_suspend(xen_pv_domain()
> - ? virt_to_mfn(xen_start_info)
> + ? virt_to_gfn(xen_start_info)
> : 0);
>
> xen_arch_post_suspend(si->cancelled);
> diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
> index 239738f..28c97ff 100644
> --- a/drivers/xen/tmem.c
> +++ b/drivers/xen/tmem.c
> @@ -131,7 +131,7 @@ static int xen_tmem_new_pool(struct tmem_pool_uuid uuid,
> static int xen_tmem_put_page(u32 pool_id, struct tmem_oid oid,
> u32 index, unsigned long pfn)
> {
> - unsigned long gmfn = xen_pv_domain() ? pfn_to_mfn(pfn) : pfn;
> + unsigned long gmfn = pfn_to_gfn(pfn);
>
> return xen_tmem_op(TMEM_PUT_PAGE, pool_id, oid, index,
> gmfn, 0, 0, 0);
> @@ -140,7 +140,7 @@ static int xen_tmem_put_page(u32 pool_id, struct tmem_oid oid,
> static int xen_tmem_get_page(u32 pool_id, struct tmem_oid oid,
> u32 index, unsigned long pfn)
> {
> - unsigned long gmfn = xen_pv_domain() ? pfn_to_mfn(pfn) : pfn;
> + unsigned long gmfn = pfn_to_gfn(pfn);
>
> return xen_tmem_op(TMEM_GET_PAGE, pool_id, oid, index,
> gmfn, 0, 0, 0);
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index 9ad3272..daa267a 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -380,7 +380,7 @@ int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
>
> for (i = 0; i < nr_pages; i++) {
> err = gnttab_grant_foreign_access(dev->otherend_id,
> - virt_to_mfn(vaddr), 0);
> + virt_to_gfn(vaddr), 0);
> if (err < 0) {
> xenbus_dev_fatal(dev, err,
> "granting access to ring page");
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> index b17707e..ee6d9ef 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -49,7 +49,7 @@ static long xenbus_alloc(domid_t domid)
> goto out_err;
>
> gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
> - virt_to_mfn(xen_store_interface), 0 /* writable */);
> + virt_to_gfn(xen_store_interface), 0 /* writable */);
>
> arg.dom = DOMID_SELF;
> arg.remote_dom = domid;
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 4308fb3..b3870f4 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -711,9 +711,7 @@ static int __init xenstored_local_init(void)
> if (!page)
> goto out_err;
>
> - xen_store_mfn = xen_start_info->store_mfn =
> - pfn_to_mfn(virt_to_phys((void *)page) >>
> - PAGE_SHIFT);
> + xen_store_mfn = xen_start_info->store_mfn = virt_to_gfn((void *)page);
>
> /* Next allocate a local port which xenstored can bind to */
> alloc_unbound.dom = DOMID_SELF;
> @@ -787,12 +785,12 @@ static int __init xenbus_init(void)
> err = xenstored_local_init();
> if (err)
> goto out_error;
> - xen_store_interface = mfn_to_virt(xen_store_mfn);
> + xen_store_interface = gfn_to_virt(xen_store_mfn);
> break;
> case XS_PV:
> xen_store_evtchn = xen_start_info->store_evtchn;
> xen_store_mfn = xen_start_info->store_mfn;
> - xen_store_interface = mfn_to_virt(xen_store_mfn);
> + xen_store_interface = gfn_to_virt(xen_store_mfn);
> break;
> case XS_HVM:
> err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> diff --git a/include/xen/page.h b/include/xen/page.h
> index c5ed20b..e7e1425 100644
> --- a/include/xen/page.h
> +++ b/include/xen/page.h
> @@ -3,9 +3,9 @@
>
> #include <asm/xen/page.h>
>
> -static inline unsigned long page_to_mfn(struct page *page)
> +static inline unsigned long page_to_gfn(struct page *page)
> {
> - return pfn_to_mfn(page_to_pfn(page));
> + return pfn_to_gfn(page_to_pfn(page));
> }
>
> struct xen_memory_region {
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH v2 4/8] xen: Use the correctly the Xen memory terminologies
From: Stefano Stabellini @ 2015-08-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55C147DD.7000600@oracle.com>
On Tue, 4 Aug 2015, Boris Ostrovsky wrote:
> On 08/04/2015 02:12 PM, Julien Grall wrote:
> > /*
> > * We detect special mappings in one of two ways:
> > @@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned
> > long mfn)
> > /* VIRT <-> MACHINE conversion */
> > #define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v))))
> > -#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
> > #define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> > #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> > +#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
>
> This looks like unnecessary change.
>
>
> > diff --git a/drivers/video/fbdev/xen-fbfront.c
> > b/drivers/video/fbdev/xen-fbfront.c
> > index 09dc447..25e3cce 100644
> > --- a/drivers/video/fbdev/xen-fbfront.c
> > +++ b/drivers/video/fbdev/xen-fbfront.c
> > @@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
> > static unsigned long vmalloc_to_mfn(void *address)
> > {
> > - return pfn_to_mfn(vmalloc_to_pfn(address));
> > + return pfn_to_gfn(vmalloc_to_pfn(address));
> > }
>
> Are you sure? This will return vmalloc_to_pfn(address)).
I think that is OK: there is no behavioural change here.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox