Re: [PATCH v3 2/6] Disable instrumentation for some code

[Russell King - ARM Linux]

On Tue, Apr 03, 2018 at 12:30:42PM +0100, Marc Zyngier wrote:
> On 02/04/18 13:04, Abbott Liu wrote:
> > From: Andrey Ryabinin <a.ryabi...@samsung.com>
> > 
> > Disable instrumentation for arch/arm/boot/compressed/*
> > ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those
> > code won't linkd with kernel image.
> > 
> > Disable kasan check in the function unwind_pop_register
> > because it doesn't matter that kasan checks failed when
> > unwind_pop_register read stack memory of task.
> > 
> > Reviewed-by: Russell King - ARM Linux <li...@armlinux.org.uk>
> > Reviewed-by: Florian Fainelli <f.faine...@gmail.com>
> > Reviewed-by: Marc Zyngier <marc.zyng...@arm.com>
> 
> Just because I replied to this patch doesn't mean you can stick my
> Reviewed-by tag on it. Please drop this tag until I explicitly say that
> you can add it (see Documentation/process/submitting-patches.rst,
> section 11).
> 
> Same goes for patch 1.

Same goes for that reviewed-by line for me.  From my records, I never
even looked at patch 2 from the first posting, and I don't appear to
have the second posting in my mailbox (it's probably been classed as
spam by dspam.)  So these reviewed-by lines seem to be totally
misleading.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/6] Initialize the mapping of KASan shadow memory

[Russell King - ARM Linux]

On Mon, Apr 02, 2018 at 02:08:13PM -0400, Nicolas Pitre wrote:
> On Mon, 2 Apr 2018, Abbott Liu wrote:
> 
> > index c79b829..20161e2 100644
> > --- a/arch/arm/kernel/head-common.S
> > +++ b/arch/arm/kernel/head-common.S
> > @@ -115,6 +115,9 @@ __mmap_switched:
> > str r8, [r2]@ Save atags pointer
> > cmp r3, #0
> > strne   r10, [r3]   @ Save control register values
> > +#ifdef CONFIG_KASAN
> > +   bl  kasan_early_init
> > +#endif
> > mov lr, #0
> > b   start_kernel
> >  ENDPROC(__mmap_switched)
> 
> Would be better if lr was cleared before calling kasan_early_init.

No.  The code is correct - please remember that "bl" writes to LR.

The point of clearing LR here is to ensure that start_kernel is called
with a zero link register, which it won't be if kasan_early_init is
moved after it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/11] sfp: fix sparse warning

[Russell King]

drivers/net/phy/sfp-bus.c:298:13: warning: context imbalance in 
'sfp_bus_release' - wrong count at exit

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/phy/sfp-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 2b8c256156a2..a28859022ddb 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -291,7 +291,7 @@ static struct sfp_bus *sfp_bus_get(struct device_node *np)
return found;
 }
 
-static void sfp_bus_release(struct kref *kref) __releases(sfp_mutex)
+static void sfp_bus_release(struct kref *kref)
 {
struct sfp_bus *bus = container_of(kref, struct sfp_bus, kref);
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/11] sfp: convert to fwnode

[Russell King]

Convert sfp-bus to use fwnode rather than device_node internally, so
we can support more than just device tree firmware.

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/phy/phylink.c |  3 ++-
 drivers/net/phy/sfp-bus.c | 14 +++---
 include/linux/sfp.h   |  7 ---
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 5a1bd48eb6d7..bca142a4863c 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -499,7 +499,8 @@ static int phylink_register_sfp(struct phylink *pl, struct 
device_node *np)
if (!sfp_np)
return 0;
 
-   pl->sfp_bus = sfp_register_upstream(sfp_np, pl->netdev, pl,
+   pl->sfp_bus = sfp_register_upstream(of_fwnode_handle(sfp_np),
+   pl->netdev, pl,
_phylink_ops);
if (!pl->sfp_bus)
return -ENOMEM;
diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index a28859022ddb..1356dba0d9d3 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -15,7 +15,7 @@ struct sfp_bus {
/* private: */
struct kref kref;
struct list_head node;
-   struct device_node *device_node;
+   struct fwnode_handle *fwnode;
 
const struct sfp_socket_ops *socket_ops;
struct device *sfp_dev;
@@ -260,7 +260,7 @@ static const struct sfp_upstream_ops 
*sfp_get_upstream_ops(struct sfp_bus *bus)
return bus->registered ? bus->upstream_ops : NULL;
 }
 
-static struct sfp_bus *sfp_bus_get(struct device_node *np)
+static struct sfp_bus *sfp_bus_get(struct fwnode_handle *fwnode)
 {
struct sfp_bus *sfp, *new, *found = NULL;
 
@@ -269,7 +269,7 @@ static struct sfp_bus *sfp_bus_get(struct device_node *np)
mutex_lock(_mutex);
 
list_for_each_entry(sfp, _buses, node) {
-   if (sfp->device_node == np) {
+   if (sfp->fwnode == fwnode) {
kref_get(>kref);
found = sfp;
break;
@@ -278,7 +278,7 @@ static struct sfp_bus *sfp_bus_get(struct device_node *np)
 
if (!found && new) {
kref_init(>kref);
-   new->device_node = np;
+   new->fwnode = fwnode;
list_add(>node, _buses);
found = new;
new = NULL;
@@ -423,11 +423,11 @@ EXPORT_SYMBOL_GPL(sfp_upstream_stop);
  *
  * On error, returns %NULL.
  */
-struct sfp_bus *sfp_register_upstream(struct device_node *np,
+struct sfp_bus *sfp_register_upstream(struct fwnode_handle *fwnode,
  struct net_device *ndev, void *upstream,
  const struct sfp_upstream_ops *ops)
 {
-   struct sfp_bus *bus = sfp_bus_get(np);
+   struct sfp_bus *bus = sfp_bus_get(fwnode);
int ret = 0;
 
if (bus) {
@@ -537,7 +537,7 @@ EXPORT_SYMBOL_GPL(sfp_module_remove);
 struct sfp_bus *sfp_register_socket(struct device *dev, struct sfp *sfp,
const struct sfp_socket_ops *ops)
 {
-   struct sfp_bus *bus = sfp_bus_get(dev->of_node);
+   struct sfp_bus *bus = sfp_bus_get(dev->fwnode);
int ret = 0;
 
if (bus) {
diff --git a/include/linux/sfp.h b/include/linux/sfp.h
index b6089fe72378..47ea32d3e816 100644
--- a/include/linux/sfp.h
+++ b/include/linux/sfp.h
@@ -356,7 +356,7 @@ enum {
SFP_PAGE= 0x7f,
 };
 
-struct device_node;
+struct fwnode_handle;
 struct ethtool_eeprom;
 struct ethtool_modinfo;
 struct net_device;
@@ -397,7 +397,7 @@ int sfp_get_module_eeprom(struct sfp_bus *bus, struct 
ethtool_eeprom *ee,
  u8 *data);
 void sfp_upstream_start(struct sfp_bus *bus);
 void sfp_upstream_stop(struct sfp_bus *bus);
-struct sfp_bus *sfp_register_upstream(struct device_node *np,
+struct sfp_bus *sfp_register_upstream(struct fwnode_handle *fwnode,
  struct net_device *ndev, void *upstream,
  const struct sfp_upstream_ops *ops);
 void sfp_unregister_upstream(struct sfp_bus *bus);
@@ -441,7 +441,8 @@ static inline void sfp_upstream_stop(struct sfp_bus *bus)
 {
 }
 
-static inline struct sfp_bus *sfp_register_upstream(struct device_node *np,
+static inline struct sfp_bus *sfp_register_upstream(
+   struct fwnode_handle *fwnode,
struct net_device *ndev, void *upstream,
const struct sfp_upstream_ops *ops)
 {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/11] sfp: add documentation for kernel APIs

[Russell King]

Add kernel-doc documentation for sfp kernel APIs, and link it into the
networking kapi documentation under "Network device support".

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 Documentation/networking/kapi.rst |  12 +
 drivers/net/phy/sfp-bus.c | 104 ++
 include/linux/sfp.h   |  50 +-
 3 files changed, 152 insertions(+), 14 deletions(-)

diff --git a/Documentation/networking/kapi.rst 
b/Documentation/networking/kapi.rst
index df4141b72f24..f03ae64be8bc 100644
--- a/Documentation/networking/kapi.rst
+++ b/Documentation/networking/kapi.rst
@@ -157,3 +157,15 @@ PHYLINK
:internal:
 
 .. kernel-doc:: drivers/net/phy/phylink.c
+
+SFP support
+---
+
+.. kernel-doc:: drivers/net/phy/sfp-bus.c
+   :internal:
+
+.. kernel-doc:: include/linux/sfp.h
+   :internal:
+
+.. kernel-doc:: drivers/net/phy/sfp-bus.c
+   :export:
diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 8a1b1f4c1b7c..2b8c256156a2 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -8,7 +8,11 @@
 
 #include "sfp.h"
 
+/**
+ * struct sfp_bus - internal representation of a sfp bus
+ */
 struct sfp_bus {
+   /* private: */
struct kref kref;
struct list_head node;
struct device_node *device_node;
@@ -26,6 +30,20 @@ struct sfp_bus {
bool started;
 };
 
+/**
+ * sfp_parse_port() - Parse the EEPROM base ID, setting the port type
+ * @bus: a pointer to the  sfp_bus structure for the sfp module
+ * @id: a pointer to the module's  sfp_eeprom_id
+ * @support: optional pointer to an array of unsigned long for the
+ *   ethtool support mask
+ *
+ * Parse the EEPROM identification given in @id, and return one of
+ * %PORT_TP, %PORT_FIBRE or %PORT_OTHER. If @support is non-%NULL,
+ * also set the ethtool %ETHTOOL_LINK_MODE_xxx_BIT corresponding with
+ * the connector type.
+ *
+ * If the port type is not known, returns %PORT_OTHER.
+ */
 int sfp_parse_port(struct sfp_bus *bus, const struct sfp_eeprom_id *id,
   unsigned long *support)
 {
@@ -78,6 +96,24 @@ int sfp_parse_port(struct sfp_bus *bus, const struct 
sfp_eeprom_id *id,
 }
 EXPORT_SYMBOL_GPL(sfp_parse_port);
 
+/**
+ * sfp_parse_interface() - Parse the phy_interface_t
+ * @bus: a pointer to the  sfp_bus structure for the sfp module
+ * @id: a pointer to the module's  sfp_eeprom_id
+ *
+ * Derive the phy_interface_t mode for the information found in the
+ * module's identifying EEPROM. There is no standard or defined way
+ * to derive this information, so we use some heuristics.
+ *
+ * If the encoding is 64b66b, then the module must be >= 10G, so
+ * return %PHY_INTERFACE_MODE_10GKR.
+ *
+ * If it's 8b10b, then it's 1G or slower. If it's definitely a fibre
+ * module, return %PHY_INTERFACE_MODE_1000BASEX mode, otherwise return
+ * %PHY_INTERFACE_MODE_SGMII mode.
+ *
+ * If the encoding is not known, return %PHY_INTERFACE_MODE_NA.
+ */
 phy_interface_t sfp_parse_interface(struct sfp_bus *bus,
const struct sfp_eeprom_id *id)
 {
@@ -117,6 +153,15 @@ phy_interface_t sfp_parse_interface(struct sfp_bus *bus,
 }
 EXPORT_SYMBOL_GPL(sfp_parse_interface);
 
+/**
+ * sfp_parse_support() - Parse the eeprom id for supported link modes
+ * @bus: a pointer to the  sfp_bus structure for the sfp module
+ * @id: a pointer to the module's  sfp_eeprom_id
+ * @support: pointer to an array of unsigned long for the ethtool support mask
+ *
+ * Parse the EEPROM identification information and derive the supported
+ * ethtool link modes for the module.
+ */
 void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id,
   unsigned long *support)
 {
@@ -293,6 +338,16 @@ static void sfp_unregister_bus(struct sfp_bus *bus)
bus->registered = false;
 }
 
+/**
+ * sfp_get_module_info() - Get the ethtool_modinfo for a SFP module
+ * @bus: a pointer to the  sfp_bus structure for the sfp module
+ * @modinfo: a  ethtool_modinfo
+ *
+ * Fill in the type and eeprom_len parameters in @modinfo for a module on
+ * the sfp bus specified by @bus.
+ *
+ * Returns 0 on success or a negative errno number.
+ */
 int sfp_get_module_info(struct sfp_bus *bus, struct ethtool_modinfo *modinfo)
 {
if (!bus->registered)
@@ -301,6 +356,17 @@ int sfp_get_module_info(struct sfp_bus *bus, struct 
ethtool_modinfo *modinfo)
 }
 EXPORT_SYMBOL_GPL(sfp_get_module_info);
 
+/**
+ * sfp_get_module_eeprom() - Read the SFP module EEPROM
+ * @bus: a pointer to the  sfp_bus structure for the sfp module
+ * @ee: a  ethtool_eeprom
+ * @data: buffer to contain the EEPROM data (must be at least @ee->len bytes)
+ *
+ * Read the EEPROM as specified by the supplied @ee. See the documentation
+ * for  ethtool_eeprom for the region to be read.
+ *
+ * Returns 0 on success or a negative errno number.
+ */
 int sfp_get_module_eeprom(struct s

[PATCH 07/11] phylink: add documentation for kernel APIs

[Russell King]

Add kernel-doc documentation for phylink kernel APIs, and link it into
the networking kapi documentation under "Network device support".

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 Documentation/networking/kapi.rst |  12 +++
 drivers/net/phy/phylink.c | 182 +
 include/linux/phylink.h   | 183 --
 3 files changed, 329 insertions(+), 48 deletions(-)

diff --git a/Documentation/networking/kapi.rst 
b/Documentation/networking/kapi.rst
index 580289f345da..df4141b72f24 100644
--- a/Documentation/networking/kapi.rst
+++ b/Documentation/networking/kapi.rst
@@ -145,3 +145,15 @@ PHY Support
 
 .. kernel-doc:: drivers/net/phy/mdio_bus.c
:internal:
+
+PHYLINK
+---
+
+  PHYLINK interfaces traditional network drivers with PHYLIB, fixed-links,
+  and SFF modules (eg, hot-pluggable SFP) that may contain PHYs.  PHYLINK
+  provides management of the link state and link modes.
+
+.. kernel-doc:: include/linux/phylink.h
+   :internal:
+
+.. kernel-doc:: drivers/net/phy/phylink.c
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 40563c8d7352..5a1bd48eb6d7 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -36,7 +36,11 @@ enum {
PHYLINK_DISABLE_LINK,
 };
 
+/**
+ * struct phylink - internal data type for phylink
+ */
 struct phylink {
+   /* private: */
struct net_device *netdev;
const struct phylink_mac_ops *ops;
 
@@ -87,6 +91,13 @@ static inline bool linkmode_empty(const unsigned long *src)
return bitmap_empty(src, __ETHTOOL_LINK_MODE_MASK_NBITS);
 }
 
+/**
+ * phylink_set_port_modes() - set the port type modes in the ethtool mask
+ * @mask: ethtool link mode mask
+ *
+ * Sets all the port type modes in the ethtool mask.  MAC drivers should
+ * use this in their 'validate' callback.
+ */
 void phylink_set_port_modes(unsigned long *mask)
 {
phylink_set(mask, TP);
@@ -496,6 +507,19 @@ static int phylink_register_sfp(struct phylink *pl, struct 
device_node *np)
return 0;
 }
 
+/**
+ * phylink_create() - create a phylink instance
+ * @ndev: a pointer to the  net_device
+ * @np: a pointer to a  device_node describing the network interface
+ * @iface: the desired link mode defined by  phy_interface_t
+ * @ops: a pointer to a  phylink_mac_ops for the MAC.
+ *
+ * Create a new phylink instance, and parse the link parameters found in @np.
+ * This will parse in-band modes, fixed-link or SFP configuration.
+ *
+ * Returns a pointer to a  phylink, or an error-pointer value. Users
+ * must use IS_ERR() to check for errors from this function.
+ */
 struct phylink *phylink_create(struct net_device *ndev, struct device_node *np,
   phy_interface_t iface,
   const struct phylink_mac_ops *ops)
@@ -548,6 +572,13 @@ struct phylink *phylink_create(struct net_device *ndev, 
struct device_node *np,
 }
 EXPORT_SYMBOL_GPL(phylink_create);
 
+/**
+ * phylink_destroy() - cleanup and destroy the phylink instance
+ * @pl: a pointer to a  phylink returned from phylink_create()
+ *
+ * Destroy a phylink instance. Any PHY that has been attached must have been
+ * cleaned up via phylink_disconnect_phy() prior to calling this function.
+ */
 void phylink_destroy(struct phylink *pl)
 {
if (pl->sfp_bus)
@@ -644,6 +675,21 @@ static int phylink_bringup_phy(struct phylink *pl, struct 
phy_device *phy)
return 0;
 }
 
+/**
+ * phylink_connect_phy() - connect a PHY to the phylink instance
+ * @pl: a pointer to a  phylink returned from phylink_create()
+ * @phy: a pointer to a  phy_device.
+ *
+ * Connect @phy to the phylink instance specified by @pl by calling
+ * phy_attach_direct(). Configure the @phy according to the MAC driver's
+ * capabilities, start the PHYLIB state machine and enable any interrupts
+ * that the PHY supports.
+ *
+ * This updates the phylink's ethtool supported and advertising link mode
+ * masks.
+ *
+ * Returns 0 on success or a negative errno.
+ */
 int phylink_connect_phy(struct phylink *pl, struct phy_device *phy)
 {
int ret;
@@ -665,6 +711,17 @@ int phylink_connect_phy(struct phylink *pl, struct 
phy_device *phy)
 }
 EXPORT_SYMBOL_GPL(phylink_connect_phy);
 
+/**
+ * phylink_of_phy_connect() - connect the PHY specified in the DT mode.
+ * @pl: a pointer to a  phylink returned from phylink_create()
+ * @dn: a pointer to a  device_node.
+ *
+ * Connect the phy specified in the device node @dn to the phylink instance
+ * specified by @pl. Actions specified in phylink_connect_phy() will be
+ * performed.
+ *
+ * Returns 0 on success or a negative errno.
+ */
 int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn)
 {
struct device_node *phy_node;
@@ -706,6 +763,13 @@ int phylink_of_phy_connect(struct phylink *pl, struct 
device_node *dn)
 }
 EXPORT_SYMBOL_GPL(phylink_of_phy_connect);
 
+/**
+ * phy

[PATCH 06/11] phylink: restart 802.3z negotiation when starting net device

[Russell King]

Restart 802.3z negotiation when the net device is brought up to ensure
that the link partner has our current link modes.

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/phy/phylink.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 560486463930..40563c8d7352 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -751,6 +751,12 @@ void phylink_start(struct phylink *pl)
phylink_resolve_flow(pl, >link_config);
phylink_mac_config(pl, >link_config);
 
+   /* Restart autonegotiation if using 802.3z to ensure that the link
+* parameters are properly negotiated.  This is necessary for DSA
+* switches using 802.3z negotiation to ensure they see our modes.
+*/
+   phylink_mac_an_restart(pl);
+
clear_bit(PHYLINK_DISABLE_STOPPED, >phylink_disable_state);
phylink_run_resolve(pl);
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/11] phylink: get rid of separate Cisco SGMII and 802.3z modes

[Russell King]

Since the handling of SGMII and 802.3z is now the same, combine the
MLO_AN_xxx constants into a single MLO_AN_INBAND, and use the PHY
interface mode to distinguish between Cisco SGMII and 802.3z.

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/phy/phylink.c | 39 ++-
 include/linux/phylink.h   | 19 +++
 2 files changed, 21 insertions(+), 37 deletions(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index d7006fdc8f71..34ecdb892f57 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -117,8 +117,7 @@ static const char *phylink_an_mode_str(unsigned int mode)
static const char *modestr[] = {
[MLO_AN_PHY] = "phy",
[MLO_AN_FIXED] = "fixed",
-   [MLO_AN_SGMII] = "SGMII",
-   [MLO_AN_8023Z] = "802.3z",
+   [MLO_AN_INBAND] = "inband",
};
 
return mode < ARRAY_SIZE(modestr) ? modestr[mode] : "unknown";
@@ -244,6 +243,7 @@ static int phylink_parse_mode(struct phylink *pl, struct 
device_node *np)
phylink_set(pl->supported, Asym_Pause);
phylink_set(pl->supported, Pause);
pl->link_config.an_enabled = true;
+   pl->link_an_mode = MLO_AN_INBAND;
 
switch (pl->link_config.interface) {
case PHY_INTERFACE_MODE_SGMII:
@@ -253,17 +253,14 @@ static int phylink_parse_mode(struct phylink *pl, struct 
device_node *np)
phylink_set(pl->supported, 100baseT_Full);
phylink_set(pl->supported, 1000baseT_Half);
phylink_set(pl->supported, 1000baseT_Full);
-   pl->link_an_mode = MLO_AN_SGMII;
break;
 
case PHY_INTERFACE_MODE_1000BASEX:
phylink_set(pl->supported, 1000baseX_Full);
-   pl->link_an_mode = MLO_AN_8023Z;
break;
 
case PHY_INTERFACE_MODE_2500BASEX:
phylink_set(pl->supported, 2500baseX_Full);
-   pl->link_an_mode = MLO_AN_8023Z;
break;
 
case PHY_INTERFACE_MODE_10GKR:
@@ -280,7 +277,6 @@ static int phylink_parse_mode(struct phylink *pl, struct 
device_node *np)
phylink_set(pl->supported, 1baseLR_Full);
phylink_set(pl->supported, 1baseLRM_Full);
phylink_set(pl->supported, 1baseER_Full);
-   pl->link_an_mode = MLO_AN_SGMII;
break;
 
default:
@@ -422,8 +418,7 @@ static void phylink_resolve(struct work_struct *w)
phylink_mac_config(pl, _state);
break;
 
-   case MLO_AN_SGMII:
-   case MLO_AN_8023Z:
+   case MLO_AN_INBAND:
phylink_get_mac_state(pl, _state);
if (pl->phydev) {
bool changed = false;
@@ -654,7 +649,8 @@ int phylink_connect_phy(struct phylink *pl, struct 
phy_device *phy)
int ret;
 
if (WARN_ON(pl->link_an_mode == MLO_AN_FIXED ||
-   pl->link_an_mode == MLO_AN_8023Z))
+   (pl->link_an_mode == MLO_AN_INBAND &&
+phy_interface_mode_is_8023z(pl->link_interface
return -EINVAL;
 
ret = phy_attach_direct(pl->netdev, phy, 0, pl->link_interface);
@@ -677,7 +673,8 @@ int phylink_of_phy_connect(struct phylink *pl, struct 
device_node *dn)
 
/* Fixed links and 802.3z are handled without needing a PHY */
if (pl->link_an_mode == MLO_AN_FIXED ||
-   pl->link_an_mode == MLO_AN_8023Z)
+   (pl->link_an_mode == MLO_AN_INBAND &&
+phy_interface_mode_is_8023z(pl->link_interface)))
return 0;
 
phy_node = of_parse_phandle(dn, "phy-handle", 0);
@@ -851,8 +848,7 @@ int phylink_ethtool_ksettings_get(struct phylink *pl,
phylink_get_ksettings(_state, kset);
break;
 
-   case MLO_AN_SGMII:
-   case MLO_AN_8023Z:
+   case MLO_AN_INBAND:
/* If there is a phy attached, then use the reported
 * settings from the phy with no modification.
 */
@@ -1029,8 +1025,7 @@ int phylink_ethtool_set_pauseparam(struct phylink *pl,
phylink_mac_config(pl, config);
break;
 
-   case MLO_AN_SGMII:
-   case MLO_AN_8023Z:
+   case MLO_AN_INBAND:
phylink_mac_config(pl, config);
phylink_mac_an_restart(pl);
   

[PATCH 01/11] phy: add phy_interface_mode_is_8023z() helper

[Russell King]

Add and use phy_interface_mode_is_8023z() helper to identify the
interface modes that use 802.3z negotiation.  Use it in phylink's
phylink_mac_an_restart().

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/phy/phylink.c |  3 +--
 include/linux/phy.h   | 14 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 5dc9668dde34..a02d67689d6e 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -320,8 +320,7 @@ static void phylink_mac_config(struct phylink *pl,
 static void phylink_mac_an_restart(struct phylink *pl)
 {
if (pl->link_config.an_enabled &&
-   (pl->link_config.interface == PHY_INTERFACE_MODE_1000BASEX ||
-pl->link_config.interface == PHY_INTERFACE_MODE_2500BASEX))
+   phy_interface_mode_is_8023z(pl->link_config.interface))
pl->ops->mac_an_restart(pl->netdev);
 }
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index dc82a07cb4fd..71d777fe6c3d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -763,6 +763,20 @@ static inline bool 
phy_interface_mode_is_rgmii(phy_interface_t mode)
 };
 
 /**
+ * phy_interface_mode_is_8023z() - does the phy interface mode use 802.3z
+ *   negotiation
+ * @mode: one of  phy_interface_t
+ *
+ * Returns true if the phy interface mode uses the 16-bit negotiation
+ * word as defined in 802.3z. (See 802.3-2015 37.2.1 Config_Reg encoding)
+ */
+static inline bool phy_interface_mode_is_8023z(phy_interface_t mode)
+{
+   return mode == PHY_INTERFACE_MODE_1000BASEX ||
+  mode == PHY_INTERFACE_MODE_2500BASEX;
+}
+
+/**
  * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
  * is RGMII (all variants)
  * @phydev: the phy_device struct
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/11] phylink: remove phylink_init_eee()

[Russell King]

phylink_init_eee() serves no purpose, remove it.

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/phy/phylink.c | 13 -
 include/linux/phylink.h   |  1 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 06c6ad0603ac..560486463930 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1064,19 +1064,6 @@ int phylink_ethtool_get_module_eeprom(struct phylink *pl,
 }
 EXPORT_SYMBOL_GPL(phylink_ethtool_get_module_eeprom);
 
-int phylink_init_eee(struct phylink *pl, bool clk_stop_enable)
-{
-   int ret = -EPROTONOSUPPORT;
-
-   WARN_ON(!lockdep_rtnl_is_held());
-
-   if (pl->phydev)
-   ret = phy_init_eee(pl->phydev, clk_stop_enable);
-
-   return ret;
-}
-EXPORT_SYMBOL_GPL(phylink_init_eee);
-
 int phylink_get_eee_err(struct phylink *pl)
 {
int ret = 0;
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index cab22ad3bd6f..4d0f42da9078 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -123,7 +123,6 @@ int phylink_ethtool_set_pauseparam(struct phylink *,
 int phylink_ethtool_get_module_info(struct phylink *, struct ethtool_modinfo 
*);
 int phylink_ethtool_get_module_eeprom(struct phylink *,
  struct ethtool_eeprom *, u8 *);
-int phylink_init_eee(struct phylink *, bool);
 int phylink_get_eee_err(struct phylink *);
 int phylink_ethtool_get_eee(struct phylink *, struct ethtool_eee *);
 int phylink_ethtool_set_eee(struct phylink *, struct ethtool_eee *);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/11] phylink: add support for 2500baseX and 10GbaseKR

[Russell King]

Add support for handling the faster 2.5G and 10G link modes when used
with SFP modules.

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/phy/phylink.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 34ecdb892f57..06c6ad0603ac 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1352,6 +1352,8 @@ static int phylink_sfp_module_insert(void *upstream,
switch (iface) {
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+   case PHY_INTERFACE_MODE_2500BASEX:
+   case PHY_INTERFACE_MODE_10GKR:
mode = MLO_AN_INBAND;
break;
default:
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 00/20] simplify crypto wait for async op

[Russell King - ARM Linux]

On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
> Many users of kernel async. crypto services have a pattern of
> starting an async. crypto op and than using a completion
> to wait for it to end.
> 
> This patch set simplifies this common use case in two ways:
> 
> First, by separating the return codes of the case where a
> request is queued to a backlog due to the provider being
> busy (-EBUSY) from the case the request has failed due
> to the provider being busy and backlogging is not enabled
> (-EAGAIN).
> 
> Next, this change is than built on to create a generic API
> to wait for a async. crypto operation to complete.
> 
> The end result is a smaller code base and an API that is
> easier to use and more difficult to get wrong.
> 
> The patch set was boot tested on x86_64 and arm64 which
> at the very least tests the crypto users via testmgr and
> tcrypt but I do note that I do not have access to some
> of the HW whose drivers are modified nor do I claim I was
> able to test all of the corner cases.
> 
> The patch set is based upon linux-next release tagged
> next-20171013.

Has there been any performance impact analysis of these changes?  I
ended up with patches for one of the crypto drivers which converted
its interrupt handling to threaded interrupts being reverted because
it caused a performance degredation.

Moving code to latest APIs to simplify it is not always beneficial.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH resend] Documentation: arm: Replace use of virt_to_phys with __pa_symbol

[Russell King - ARM Linux]

On Mon, Jul 17, 2017 at 01:44:45PM -0600, Jonathan Corbet wrote:
> On Mon, 17 Jul 2017 15:39:28 +0200
> Geert Uytterhoeven  wrote:
> 
> > All low-level PM/SMP code using virt_to_phys() should actually use
> > __pa_symbol() against kernel symbols.  Update the documentation to move
> > away from virt_to_phys().
> > 
> > Cfr. commit 6996cbb2372189f7 ("ARM: 8641/1: treewide: Replace uses of
> > virt_to_phys with __pa_symbol")
> 
> I was kind of hoping for an ack from somebody on this, but, four months
> later, I'll take the absence of complaints as being enough.  Applied,
> thanks.

Maybe those who contributed Documentation/arm/firmware.txt should
have responded, seems that was Tomasz Figa 
who isn't even on the Cc list for this...

Can't blame people who aren't copied with the patch for not
responding.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Russell King - ARM Linux]

On Fri, Feb 03, 2017 at 01:08:40PM -0800, Kees Cook wrote:
> On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux
> <li...@armlinux.org.uk> wrote:
> > On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote:
> >> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott <labb...@redhat.com> wrote:
> >> > diff --git a/arch/Kconfig b/arch/Kconfig
> >> > index 99839c2..22ee01e 100644
> >> > --- a/arch/Kconfig
> >> > +++ b/arch/Kconfig
> >> > @@ -781,4 +781,32 @@ config VMAP_STACK
> >> >   the stack to map directly to the KASAN shadow map using a 
> >> > formula
> >> >   that is incorrect if the stack is in vmalloc space.
> >> >
> >> > +config ARCH_NO_STRICT_RWX_DEFAULTS
> >> > +   def_bool n
> >> > +
> >> > +config ARCH_HAS_STRICT_KERNEL_RWX
> >> > +   def_bool n
> >> > +
> >> > +config DEBUG_RODATA
> >> > +   def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS
> >> > +   prompt "Make kernel text and rodata read-only" if 
> >> > ARCH_NO_STRICT_RWX_DEFAULTS
> >>
> >> Ah! Yes, perfect. I totally forgot about using conditional "prompt"
> >> lines. Nice!
> >
> > It's no different from the more usual:
> >
> > bool "Make kernel text and rodata read-only" if 
> > ARCH_NO_STRICT_RWX_DEFAULTS
> > default y if !ARCH_NO_STRICT_RWX_DEFAULTS
> > depends on ARCH_HAS_STRICT_KERNEL_RWX
> >
> > But... I really don't like this - way too many negations and negatives
> > which make it difficult to figure out what's going on here.
> >
> > The situation we have today is:
> >
> > -config DEBUG_RODATA
> > -   bool "Make kernel text and rodata read-only"
> > -   depends on MMU && !XIP_KERNEL
> > -   default y if CPU_V7
> >
> > which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP
> > kernel", suggesting that the user turns it on for ARMv7 CPUs.
> >
> > That changes with this and the above:
> >
> > +   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> > +   select ARCH_HAS_STRICT_MODULE_RWX if MMU
> > +   select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7
> >
> > This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP
> > kernel, which carries the same pre-condition for DEBUG_RODATA - no
> > problem there.
> >
> > However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which
> > means the "Make kernel text and rodata read-only" prompt _is_ provided
> > for those.  However, for all ARMv7 systems, we go from "suggesting that
> > the user enables the option" to "you don't have a choice, you get this
> > whether you want it or not."
> >
> > I'd prefer to keep it off for my development systems, where I don't
> > care about kernel security.  If we don't wish to do that as a general
> > rule, can we make it dependent on EMBEDDED?
> >
> > Given that on ARM it can add up to 4MB to the kernel image - there
> > _will_ be about 1MB before the .text section, the padding on between
> > __modver and __ex_table which for me is around 626k, the padding
> > between .notes and the init sections start with .vectors (the space
> > between __ex_table and end of .notes is only 4124, which gets padded
> > up to 1MB) and lastly the padding between the .init section and the
> > data section (for me around 593k).  This all adds up to an increase
> > in kernel image size of 3.2MB on 14.2MB - an increase of 22%.
> >
> > So no, I'm really not happy with that.
> 
> Ah yeah, good point. We have three cases: unsupported, mandatory,
> optional, but we have the case of setting the default for the optional
> case. Maybe something like this?
> 
> config STRICT_KERNEL_RWX
>   bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
>   depends on ARCH_HAS_STRICT_KERNEL_RWX
>   default ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> 
> unsupported:
> !ARCH_HAS_STRICT_KERNEL_RWX
> 
> mandatory:
> ARCH_HAS_STRICT_KERNEL_RWX
> !ARCH_OPTIONAL_KERNEL_RWX
> 
> optional:
> ARCH_HAS_STRICT_KERNEL_RWX
> ARCH_OPTIONAL_KERNEL_RWX
> with default controlled by ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> 
> Then arm is:
>   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
>   select ARCH_HAS_STRICT_MODULE_RWX if MMU
>   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
>   se

Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

[Russell King - ARM Linux]

On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote:
> On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott  wrote:
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 99839c2..22ee01e 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -781,4 +781,32 @@ config VMAP_STACK
> >   the stack to map directly to the KASAN shadow map using a formula
> >   that is incorrect if the stack is in vmalloc space.
> >
> > +config ARCH_NO_STRICT_RWX_DEFAULTS
> > +   def_bool n
> > +
> > +config ARCH_HAS_STRICT_KERNEL_RWX
> > +   def_bool n
> > +
> > +config DEBUG_RODATA
> > +   def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS
> > +   prompt "Make kernel text and rodata read-only" if 
> > ARCH_NO_STRICT_RWX_DEFAULTS
> 
> Ah! Yes, perfect. I totally forgot about using conditional "prompt"
> lines. Nice!

It's no different from the more usual:

bool "Make kernel text and rodata read-only" if 
ARCH_NO_STRICT_RWX_DEFAULTS
default y if !ARCH_NO_STRICT_RWX_DEFAULTS
depends on ARCH_HAS_STRICT_KERNEL_RWX

But... I really don't like this - way too many negations and negatives
which make it difficult to figure out what's going on here.

The situation we have today is:

-config DEBUG_RODATA
-   bool "Make kernel text and rodata read-only"
-   depends on MMU && !XIP_KERNEL
-   default y if CPU_V7

which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP
kernel", suggesting that the user turns it on for ARMv7 CPUs.

That changes with this and the above:

+   select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
+   select ARCH_HAS_STRICT_MODULE_RWX if MMU
+   select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7

This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP
kernel, which carries the same pre-condition for DEBUG_RODATA - no
problem there.

However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which
means the "Make kernel text and rodata read-only" prompt _is_ provided
for those.  However, for all ARMv7 systems, we go from "suggesting that
the user enables the option" to "you don't have a choice, you get this
whether you want it or not."

I'd prefer to keep it off for my development systems, where I don't
care about kernel security.  If we don't wish to do that as a general
rule, can we make it dependent on EMBEDDED?

Given that on ARM it can add up to 4MB to the kernel image - there
_will_ be about 1MB before the .text section, the padding on between
__modver and __ex_table which for me is around 626k, the padding
between .notes and the init sections start with .vectors (the space
between __ex_table and end of .notes is only 4124, which gets padded
up to 1MB) and lastly the padding between the .init section and the
data section (for me around 593k).  This all adds up to an increase
in kernel image size of 3.2MB on 14.2MB - an increase of 22%.

So no, I'm really not happy with that.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] tty: pl011: Work around stuck BUSY bit on QDF2400

[Russell King - ARM Linux]

On Mon, Jan 30, 2017 at 06:44:17PM -0500, Christopher Covington wrote:
>  {
>   struct uart_amba_port *uap =
>   container_of(port, struct uart_amba_port, port);
> - unsigned int status = pl011_read(uap, REG_FR);
> + unsigned int status = pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr;
>   return status & (uap->vendor->fr_busy | UART01x_FR_TXFF) ?
>   0 : TIOCSER_TEMT;
>  }

I'd much prefer the reg & mask == val approach, but the above makes that
difficult.

So for the PL011 changes:

Acked-by: Russell King <rmk+ker...@armlinux.org.uk>

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.

I'm taking this patch, but with the following commit log:

  Due to the way kbuild works, this header was unintentionally exported
  back in 2013 when it was created, despite it not being in a uapi/
  directory.  This is very non-intuitive behaviour by Kbuild.

  However, we've had this include exported to userland for almost four
  years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives
  no hint that anyone has complained about it.  So, let's make it
  officially exported in this state.

If anyone has any objections, they better shout sooner rather than
later.

> 
> Signed-off-by: Nicolas Dichtel 
> ---
>  arch/arm/include/asm/types.h  | 40 
> ---
>  arch/arm/include/uapi/asm/types.h | 40 
> +++
>  2 files changed, 40 insertions(+), 40 deletions(-)
>  delete mode 100644 arch/arm/include/asm/types.h
>  create mode 100644 arch/arm/include/uapi/asm/types.h
> 
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> deleted file mode 100644
> index a53cdb8f068c..
> --- a/arch/arm/include/asm/types.h
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -#ifndef _ASM_TYPES_H
> -#define _ASM_TYPES_H
> -
> -#include 
> -
> -/*
> - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> - * unambiguous on ARM as you would expect. For the types below, there is a
> - * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> - * and the kernel itself, which results in build errors if you try to build 
> with
> - * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> - * in order to use NEON intrinsics)
> - *
> - * As the typedefs for these types in 'stdint.h' are based on builtin defines
> - * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> - * source file (provided that -ffreestanding is used).
> - *
> - *int32_t uint32_t   uintptr_t
> - * bare metal GCC longunsigned long  unsigned int
> - * glibc GCC  int unsigned int   unsigned int
> - * kernel int unsigned int   unsigned long
> - */
> -
> -#ifdef __INT32_TYPE__
> -#undef __INT32_TYPE__
> -#define __INT32_TYPE__   int
> -#endif
> -
> -#ifdef __UINT32_TYPE__
> -#undef __UINT32_TYPE__
> -#define __UINT32_TYPE__  unsigned int
> -#endif
> -
> -#ifdef __UINTPTR_TYPE__
> -#undef __UINTPTR_TYPE__
> -#define __UINTPTR_TYPE__ unsigned long
> -#endif
> -
> -#endif /* _ASM_TYPES_H */
> diff --git a/arch/arm/include/uapi/asm/types.h 
> b/arch/arm/include/uapi/asm/types.h
> new file mode 100644
> index ..9435a42f575e
> --- /dev/null
> +++ b/arch/arm/include/uapi/asm/types.h
> @@ -0,0 +1,40 @@
> +#ifndef _UAPI_ASM_TYPES_H
> +#define _UAPI_ASM_TYPES_H
> +
> +#include 
> +
> +/*
> + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> + * unambiguous on ARM as you would expect. For the types below, there is a
> + * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> + * and the kernel itself, which results in build errors if you try to build 
> with
> + * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> + * in order to use NEON intrinsics)
> + *
> + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> + * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> + * source file (provided that -ffreestanding is used).
> + *
> + *int32_t uint32_t   uintptr_t
> + * bare metal GCC longunsigned long  unsigned int
> + * glibc GCC  int unsigned int   unsigned int
> + * kernel int unsigned int   unsigned long
> + */
> +
> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
> +
> +#endif /* _UAPI_ASM_TYPES_H */
> -- 
> 2.8.1
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote:
> Please, do not remove the email subject when you reply. I restore it to
> ease the thread follow-up.

I mentioned it to David, and he says it's because the long list of
recipients is breaking his mailer.  I've already posed the question
about whether that's exploitable!

> Le 13/01/2017 à 16:36, David Howells a écrit :
> > Nicolas Dichtel  wrote:
> > 
> >> This header file is exported, thus move it to uapi.
> > 
> > Exported how?
> 
> It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by
> arch/arm/include/uapi/asm/Kbuild.

We really should not be installing non-uapi header files to userland
under _any_ circumstance - this to me sounds like a bug in kbuild.

The assumption is that headers outside of uapi directories are not
part of the user visible API, and so can be freely modified - which
in the presence of this bug is untrue.

However, as it's happening, and this header has been there since 2013
(commit 09096f6a0ee2 - "ARM: 7822/1: add workaround for ambiguous C99
stdint.h types") it's now well and truely part of the user API whether
we intended it to be or not, so your patch looks to me like the correct
thing to do.

I think it needs further evaluation to make sure kbuild isn't going to
do something else silly, like subsitute include/asm-generic/types.h for
the now missing arch/arm/include/asm/types.h

I wonder how many more headers are unintentionally exported.

... what a mess. :(

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/7] arm: put types.h in uapi

[Russell King - ARM Linux]

On Mon, Jan 09, 2017 at 12:33:02PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
> > 
> > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> > index a53cdb8f068c..c48fee3d7b3b 100644
> > --- a/arch/arm/include/asm/types.h
> > +++ b/arch/arm/include/asm/types.h
> > @@ -1,40 +1,6 @@
> >  #ifndef _ASM_TYPES_H
> >  #define _ASM_TYPES_H
> >  
> > -#include 
> ...
> > -#define __UINTPTR_TYPE__   unsigned long
> > -#endif
> > +#include 
> >  
> >  #endif /* _ASM_TYPES_H */
> > 
> 
> Moving the file is correct as far as I can tell, but the extra
> #include is not necessary here, as the kernel will automatically
> search both arch/arm/include/ and arch/arm/include/uapi/.

Indeed, I'd like to see the include/asm file gone.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> diff --git a/arch/arm/include/uapi/asm/Kbuild 
> b/arch/arm/include/uapi/asm/Kbuild
> index 46a76cd6acb6..607f702c2d62 100644
> --- a/arch/arm/include/uapi/asm/Kbuild
> +++ b/arch/arm/include/uapi/asm/Kbuild
> @@ -1,23 +1,6 @@
>  # UAPI Header export list
>  include include/uapi/asm-generic/Kbuild.asm
>  
> -header-y += auxvec.h
> -header-y += byteorder.h
> -header-y += fcntl.h
> -header-y += hwcap.h
> -header-y += ioctls.h
> -header-y += kvm_para.h
> -header-y += mman.h
> -header-y += perf_regs.h
> -header-y += posix_types.h
> -header-y += ptrace.h
> -header-y += setup.h
> -header-y += sigcontext.h
> -header-y += signal.h
> -header-y += stat.h
> -header-y += statfs.h
> -header-y += swab.h
> -header-y += unistd.h
>  genhdr-y += unistd-common.h
>  genhdr-y += unistd-oabi.h
>  genhdr-y += unistd-eabi.h

Acked-by: Russell King <rmk+ker...@armlinux.org.uk>

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Thu, May 12, 2016 at 02:26:27PM +0800, Baoquan He wrote:
> On 04/28/16 at 10:28am, Russell King wrote:
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index 52a3a221bcb2..99cb9dac7909 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const 
> > Elf_Ehdr *ehdr,
> >  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr 
> > *sechdrs,
> > unsigned int relsec);
> >  
> > +#ifndef page_to_boot_pfn
> > +static inline unsigned long page_to_boot_pfn(struct page *page)
> > +{
> > +   return page_to_pfn(page);
> > +}
> > +#endif
> 
> I am thinking if it's appropriate to introduce a new concept which only
> exists in a certain system of a certain ARCH. Is it unavoidable? If have
> to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
> might not need to know about boot view physical address and kernel view
> physical address things when they just want to understand kexec
> implementation related to one ARCH except of ARM, even related to ARM
> but not Keystone 2.

Well, what do you suggest we do instead?

Eric, please get involved in this discussion, as this was your idea.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

I was going to send the patches to Andrew, but then I noticed this
one has received no acks.  What's the situation for this patch?

On Thu, Apr 28, 2016 at 10:28:40AM +0100, Russell King wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
> 
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
> 
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
> 
> Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 38 ++
>  kernel/kexec.c|  3 ++-
>  kernel/kexec_core.c   | 26 +-
>  3 files changed, 53 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const 
> Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr 
> *sechdrs,
>   unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> + return page_to_pfn(page);
> +}
> +#endif
> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> + return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> + return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> + return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> + return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> + return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, 
> unsigned long entry,
>  
>   if (kexec_on_panic) {
>   /* Verify we have a valid entry point */
> - if ((entry < crashk_res.start) || (entry > crashk_res.end))
> + if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> + (entry > phys_to_boot_phys(crashk_res.end)))
>   return -EADDRNOTAVAIL;
>   }
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>   mstart = image->segment[i].mem;
>   mend = mstart + image->segment[i].memsz - 1;
>   /* Ensure we are within the crash kernel limits */
> - if ((mstart < crashk_res.start) ||
> - (mend > crashk_res.end))
> + if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> + (mend > phys_to_boot_phys(crashk_res.end)))
>   return result;
>   }
>   }
> @@ -354,7 +354,7 @@ static struct page 
> *kimage_alloc_normal_control_pages(struct kimage *image,
>   pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>   if (!pages)
>   break;
> - pfn   = page_to_pfn(pages);
> + pfn   = page_to_boot_pfn(pages);
>   epfn  = pfn + count;
>   addr  = pfn << PAGE_SHIFT;
>   eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, 
> kimage_entry_t entry)
>   return -ENOMEM;
>  
>   ind_page = page_address(page);
> - *image->ent

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > I think you're confusing things.  DT doesn't contain the boot alias
> > memory ranges - it's not a separate chunk of memory.  It's an alias
> > of the same physical address space found higher in the physical
> > address range.
> 
> Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> not from DT?

Just like any other ARM system, it pulls itself up by its shoe laces.

The kernel assumes that it has been placed into RAM with at least 32KiB
of writable memory below it, which it uses for the initial page tables.
It "guesses" that the executing address, rounded down to I-forget-what-
boundary gives the base address of physical memory.

It sets the page table up using that assumption.  The kernel gets going
with C code, and only _then_ parses the DTB.

If we then find that we're running on TI Keystone 2, part of the early
platform initialisation specifies to the ARM core code that the kernel
is to switch a high physical address space > 4GiB, and this provokes
a "dance" where we tear the MMU back down, run some more assembly code
to fix up the page tables, and re-initialise the MMU before returning
to the kernel C code, this time running in the high physical address
space.  This break-modify-make is an architecture requirement.  We
also record the physical address delta between the original physical
address space and the high physical address space so that we can reverse
the translation for code which needs identity mapping (eg, SMP bringup.)

The DTB only contains the high physical address space memory information,
and the kernel now parses the DTB, and sets the page tables up properly
for the running system.

> > If we put it in DT, then we need a way to also describe that it is an
> > alias of some other bit of physical memory.
> 
> I may missed the background, I just want kexec to get infomation just like
> the normal kernel.

See above.  What you're asking for isn't really possible.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> Could you please help tell why arm PAE kernel can be put above 4G?
> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

This is explained in the covering email to the series.

The explanation given by Pratyush was incomplete.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> <li...@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> Hi Russell,
> >>
> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> <rmk+ker...@arm.linux.org.uk> wrote:
> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> > know where it can place the kernel in RAM, and so be executable when
> >> > the system needs to jump into it.
> >> >
> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> > tag.
> >> >
> >> > Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
> >>
> >> Can you please also share git tree path of corresponding kexec-tools 
> >> changes?
> >>
> >> Could it be a better idea (if things in user space become simpler)
> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> user space, and then user space manipulates existing "Crash kernel"
> >> and "System RAM" resources.
> >
> > Given that it's only _one_ platform right now, I don't think that
> > additional complexity is worth it.  It means that we have to invent
> 
> Probably, I could not communicate it well.  I was not trying  to have
> *additional* complexity. Wanted to see if things could be simpler
> rather. So this is what my understanding was:
> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> (say in /sys/kernel/bootmem_idmap_offset)
> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> content of the series will go away.

Patches 11 and 12 don't go away with what you're suggesting.  Patches
11 and 12 are necessary to allow the boot-view addresses to be passed
into the kernel through kexec, and to allow kexec to find appropriate
memory resources.

For example, from patch 11:

@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned
long entry,

-   if ((entry < crashk_res.start) || (entry > crashk_res.end))
+   if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+   (entry > phys_to_boot_phys(crashk_res.end)))

"entry" is limited to a 32-bit physical address as it is unsigned long,
and is the boot-view physical address.  crashk_res.start is the
running-view physical address.  Without this change, the rest will
always be true on Keystone 2.

@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
-   if ((mstart < crashk_res.start) ||
-   (mend > crashk_res.end))
+   if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+   (mend > phys_to_boot_phys(crashk_res.end)))

Same problem - mstart and mend are both 32-bit quantities.  The result
is the segment list validation always fails.

@@ -354,7 +354,7 @@ static struct page 
*kimage_alloc_normal_control_pages(struct kimage *image,
-   pfn   = page_to_pfn(pages);
+   pfn   = page_to_boot_pfn(pages);

The result without this change is that we allocate _all_ system memory
looking for a suitable page, never finding one because we never find
a page which matches.  Without a previous patch, killing many
processes and taking the system down.

@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, 
kimage_entry_t entry)
-   *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+   *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;

The physical address would end up being truncated to 32-bits, but
would actually be larger than 4GiB.  So, *image->entry would point
at the incorrect address, and kexec would fail.

@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
for (ptr = >head; (entry = *ptr) && !(entry & IND_DONE); \
ptr = (entry & IND_INDIRECTION) ? \
-   phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+   boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)

"entry" is truncated to 32-bit, and so this passes an invalid
physical address which is not part of the lowmem mapping to
phys_to_virt().  The resulting virtual address is undefined.

-   page = pfn_to_page(entry >> PAGE_SHIFT);
+   page = boot_pfn_to_page(entry >> PAGE_SHIFT);

Same, except the resulting struct page pointer is undefined.

... and so it goes on.

The only patches which get replaced are patches 5 and 6 with a new
userspace API.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:44:29PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+ker...@arm.linux.org.uk> wrote:
> > kexec physical addresses are the boot-time view of the system.  For
> > certain ARM systems (such as Keystone 2), the boot view of the system
> > does not match the kernel's view of the system: the boot view uses a
> > special alias in the lower 4GB of the physical address space.
> >
> > To cater for these kinds of setups, we need to translate between the
> > boot view physical addresses and the normal kernel view physical
> > addresses.  This patch extracts the current transation points into
> > linux/kexec.h, and allows an architecture to override the functions.
> >
> > Due to the translations required, we unfortunately end up with six
> > translation functions, which are reduced down to four that the
> > architecture can override.
> >
> > Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
> 
> I must be missing something when I am thinking that, had we passed
> arch_phys_to_idmap_offset to user space, this patch would not have
> been needed, and things would have been more simpler. Please help me
> to understand why passing arch_phys_to_idmap_offset to user space
> would not be a good idea.

Sorry, I disagree.

Even if we thought that passing the offset to userspace would be a
good idea, it does nothing to solve each site in this patch.  This
patch would still be necessary.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+ker...@arm.linux.org.uk> wrote:
> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > index 152da4a48867..9f1920d2d0c6 100644
> > --- a/kernel/ksysfs.c
> > +++ b/kernel/ksysfs.c
> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
> >struct kobj_attribute *attr, char *buf)
> >  {
> > -   return sprintf(buf, "%lx %x\n",
> > -  paddr_vmcoreinfo_note(),
> > +   phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +   return sprintf(buf, "%pa %x\n", _base,
> 
> Why do we pass _base? Shouldn't it be vmcore_base?

You seem to not know what the "%pa" format string means.

%p always takes a _pointer_ as per C standard, so the printf argument
must be a pointer.  However, the kernel format strings are extended
with additional suffixes - in this case 'a', which means that we want
to print the contents of a _pointer_ to a phys_addr_t.

Full details in Documentation/printk-formats.txt in the kernel.

The code above is correct.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Hi Russell,
> 
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+ker...@arm.linux.org.uk> wrote:
> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> > know where it can place the kernel in RAM, and so be executable when
> > the system needs to jump into it.
> >
> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> > tag.
> >
> > Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
> 
> Can you please also share git tree path of corresponding kexec-tools changes?
> 
> Could it be a better idea (if things in user space become simpler)
> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> user space, and then user space manipulates existing "Crash kernel"
> and "System RAM" resources.

Given that it's only _one_ platform right now, I don't think that
additional complexity is worth it.  It means that we have to invent
some API to do it, and I don't see why userspace should even care
about having the delta exported - especially when the conversion
may not be as trivial.

The method I've implemented here keeps things completely independent
of whatever conversion between boot and running physical addresses
may be present on the kernel side as far as userspace is concerned.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King]

kexec physical addresses are the boot-time view of the system.  For
certain ARM systems (such as Keystone 2), the boot view of the system
does not match the kernel's view of the system: the boot view uses a
special alias in the lower 4GB of the physical address space.

To cater for these kinds of setups, we need to translate between the
boot view physical addresses and the normal kernel view physical
addresses.  This patch extracts the current transation points into
linux/kexec.h, and allows an architecture to override the functions.

Due to the translations required, we unfortunately end up with six
translation functions, which are reduced down to four that the
architecture can override.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 include/linux/kexec.h | 38 ++
 kernel/kexec.c|  3 ++-
 kernel/kexec_core.c   | 26 +-
 3 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 52a3a221bcb2..99cb9dac7909 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr 
*ehdr,
 int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr 
*sechdrs,
unsigned int relsec);
 
+#ifndef page_to_boot_pfn
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+   return page_to_pfn(page);
+}
+#endif
+
+#ifndef boot_pfn_to_page
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+   return pfn_to_page(boot_pfn);
+}
+#endif
+
+#ifndef phys_to_boot_phys
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+   return phys;
+}
+#endif
+
+#ifndef boot_phys_to_phys
+static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
+{
+   return boot_phys;
+}
+#endif
+
+static inline unsigned long virt_to_boot_phys(void *addr)
+{
+   return phys_to_boot_phys(__pa((unsigned long)addr));
+}
+
+static inline void *boot_phys_to_virt(unsigned long entry)
+{
+   return phys_to_virt(boot_phys_to_phys(entry));
+}
+
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
 struct task_struct;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index ee70aef5cd81..dd49d572a5e2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned 
long entry,
 
if (kexec_on_panic) {
/* Verify we have a valid entry point */
-   if ((entry < crashk_res.start) || (entry > crashk_res.end))
+   if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+   (entry > phys_to_boot_phys(crashk_res.end)))
return -EADDRNOTAVAIL;
}
 
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f9847e5822e6..d04940ccc58d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
mstart = image->segment[i].mem;
mend = mstart + image->segment[i].memsz - 1;
/* Ensure we are within the crash kernel limits */
-   if ((mstart < crashk_res.start) ||
-   (mend > crashk_res.end))
+   if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+   (mend > phys_to_boot_phys(crashk_res.end)))
return result;
}
}
@@ -354,7 +354,7 @@ static struct page 
*kimage_alloc_normal_control_pages(struct kimage *image,
pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
if (!pages)
break;
-   pfn   = page_to_pfn(pages);
+   pfn   = page_to_boot_pfn(pages);
epfn  = pfn + count;
addr  = pfn << PAGE_SHIFT;
eaddr = epfn << PAGE_SHIFT;
@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, 
kimage_entry_t entry)
return -ENOMEM;
 
ind_page = page_address(page);
-   *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+   *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
image->entry = ind_page;
image->last_entry = ind_page +
  ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
for (ptr = >head; (entry = *ptr) && !(entry & IND_DONE); \
ptr = (entry & IND_INDIRECTION) ? \
-   phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+   boot_phys_to_virt((entry & PAGE_MASK)) : ptr +

[PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Russell King]

Ensure that user memory sizes do not wrap around when validating the
user input, which can lead to the following input validation working
incorrectly.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8d34308ea449..d719a4d0ef55 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
 
mstart = image->segment[i].mem;
mend   = mstart + image->segment[i].memsz;
+   if (mstart > mend)
+   return result;
if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
return result;
if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King]

On PAE systems (eg, ARM LPAE) the vmcore note may be located above
4GB physical on 32-bit architectures, so we need a wider type than
"unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
a phys_addr_t, thereby allowing it to be located above 4GB.

This makes no difference for kexec-tools, as they already assume a
64-bit type when reading from this file.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/ia64/kernel/machine_kexec.c | 2 +-
 include/linux/kexec.h| 2 +-
 kernel/kexec_core.c  | 2 +-
 kernel/ksysfs.c  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index b72cd7a07222..599507bcec91 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
 #endif
 }
 
-unsigned long paddr_vmcoreinfo_note(void)
+phys_addr_t paddr_vmcoreinfo_note(void)
 {
return ia64_tpa((unsigned long)(char *)_note);
 }
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 1b32ab587f66..52a3a221bcb2 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
 void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
-unsigned long paddr_vmcoreinfo_note(void);
+phys_addr_t paddr_vmcoreinfo_note(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index d719a4d0ef55..f9847e5822e6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 void __weak arch_crash_save_vmcoreinfo(void)
 {}
 
-unsigned long __weak paddr_vmcoreinfo_note(void)
+phys_addr_t __weak paddr_vmcoreinfo_note(void)
 {
return __pa((unsigned long)(char *)_note);
 }
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 152da4a48867..9f1920d2d0c6 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
 static ssize_t vmcoreinfo_show(struct kobject *kobj,
   struct kobj_attribute *attr, char *buf)
 {
-   return sprintf(buf, "%lx %x\n",
-  paddr_vmcoreinfo_note(),
+   phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
+   return sprintf(buf, "%pa %x\n", _base,
   (unsigned int)sizeof(vmcoreinfo_note));
 }
 KERNEL_ATTR_RO(vmcoreinfo);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/12] ARM: keystone: dts: add psci command definition

[Russell King]

From: Vitaly Andrianov <vita...@ti.com>

This commit adds definition for cpu_on, cpu_off and cpu_suspend commands.
These definitions must match the corresponding PSCI definitions in
boot monitor.

Having those command and corresponding PSCI support in boot monitor allows
run time CPU hot plugin.

Signed-off-by: Keerthy <j-keer...@ti.com>
Signed-off-by: Vitaly Andrianov <vita...@ti.com>
Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---

This patch is already queued by Santosh, and only exists as part of this
series for completeness.

 arch/arm/boot/dts/keystone.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 3f272826f537..007648971744 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -59,6 +59,14 @@
 ;
};
 
+   psci {
+   compatible  = "arm,psci";
+   method  = "smc";
+   cpu_suspend = <0x8401>;
+   cpu_off = <0x8402>;
+   cpu_on  = <0x8403>;
+   };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Russell King]

If we are unable to find a suitable page when allocating the control
page, do not invoke the OOM-killer: killing processes probably isn't
going to help.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 include/linux/kexec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 2cc643c6e870..1b32ab587f66 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -41,7 +41,7 @@
 #endif
 
 #ifndef KEXEC_CONTROL_MEMORY_GFP
-#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
+#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
 #endif
 
 #ifndef KEXEC_CONTROL_PAGE_SIZE
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Russell King]

Provide a helper to indicate whether we need to perform special handling
for boot identity mapping aliases or not.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ca208335fde6..31c07a2cc100 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
  * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+static inline bool arm_has_idmap_alias(void)
+{
+   return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
+}
+
 #define IDMAP_INVALID_ADDR ((u32)~0)
 
 static inline unsigned long phys_to_idmap(phys_addr_t addr)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/12] ARM: kdump: advertise boot aliased crash kernel resource

[Russell King]

Advertise a resource which describes where the crash kernel is located
in the boot view of RAM.  This allows kexec-tools to have this vital
information.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d9317eec1eba..19b25ad61385 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1003,9 +1003,25 @@ static void __init reserve_crashkernel(void)
(unsigned long)(crash_base >> 20),
(unsigned long)(total_mem >> 20));
 
+   /* The crashk resource must always be located in normal mem */
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
insert_resource(_resource, _res);
+
+   if (arm_has_idmap_alias()) {
+   /*
+* If we have a special RAM alias for use at boot, we
+* need to advertise to kexec tools where the alias is.
+*/
+   static struct resource crashk_boot_res = {
+   .name = "Crash kernel (boot alias)",
+   .flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+   };
+
+   crashk_boot_res.start = phys_to_idmap(crash_base);
+   crashk_boot_res.end = crashk_boot_res.start + crash_size - 1;
+   insert_resource(_resource, _boot_res);
+   }
 }
 #else
 static inline void reserve_crashkernel(void) {}
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/12] ARM: provide improved virt_to_idmap() functionality

[Russell King]

For kexec, we need more functionality from the IDMAP system.  We need to
be able to convert physical addresses to their identity mappped versions
as well as virtual addresses.

Convert the existing arch_virt_to_idmap() to deal with physical
addresses instead.

Acked-by: Santosh Shilimkar <ssant...@kernel.org>
Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h | 33 ++---
 arch/arm/mach-keystone/keystone.c |  7 +--
 arch/arm/mm/idmap.c   |  2 +-
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 9427fd632552..ca208335fde6 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -288,19 +288,38 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define __va(x)((void 
*)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)  __va((phys_addr_t)(pfn) << PAGE_SHIFT)
 
-extern unsigned long (*arch_virt_to_idmap)(unsigned long x);
+extern long long arch_phys_to_idmap_offset;
 
 /*
- * These are for systems that have a hardware interconnect supported alias of
- * physical memory for idmap purposes.  Most cases should leave these
+ * These are for systems that have a hardware interconnect supported alias
+ * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+#define IDMAP_INVALID_ADDR ((u32)~0)
+
+static inline unsigned long phys_to_idmap(phys_addr_t addr)
+{
+   if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
+   addr += arch_phys_to_idmap_offset;
+   if (addr > (u32)~0)
+   addr = IDMAP_INVALID_ADDR;
+   }
+   return addr;
+}
+
+static inline phys_addr_t idmap_to_phys(unsigned long idmap)
+{
+   phys_addr_t addr = idmap;
+
+   if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset)
+   addr -= arch_phys_to_idmap_offset;
+
+   return addr;
+}
+
 static inline unsigned long __virt_to_idmap(unsigned long x)
 {
-   if (IS_ENABLED(CONFIG_MMU) && arch_virt_to_idmap)
-   return arch_virt_to_idmap(x);
-   else
-   return __virt_to_phys(x);
+   return phys_to_idmap(__virt_to_phys(x));
 }
 
 #define virt_to_idmap(x)   __virt_to_idmap((unsigned long)(x))
diff --git a/arch/arm/mach-keystone/keystone.c 
b/arch/arm/mach-keystone/keystone.c
index e6b9cb1e6709..a33a296b00dc 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -63,11 +63,6 @@ static void __init keystone_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static unsigned long keystone_virt_to_idmap(unsigned long x)
-{
-   return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET + KEYSTONE_LOW_PHYS_START;
-}
-
 static long long __init keystone_pv_fixup(void)
 {
long long offset;
@@ -91,7 +86,7 @@ static long long __init keystone_pv_fixup(void)
offset = KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START;
 
/* Populate the arch idmap hook */
-   arch_virt_to_idmap = keystone_virt_to_idmap;
+   arch_phys_to_idmap_offset = -offset;
 
return offset;
 }
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index bd274a05b8ff..c1a48f88764e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -15,7 +15,7 @@
  * page tables.
  */
 pgd_t *idmap_pgd;
-unsigned long (*arch_virt_to_idmap)(unsigned long x);
+long long arch_phys_to_idmap_offset;
 
 #ifdef CONFIG_ARM_LPAE
 static void idmap_add_pmd(pud_t *pud, unsigned long addr, unsigned long end,
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Russell King]

When the kernel crashkernel parameter is specified with just a size, we
are supposed to allocate a region from RAM to store the crashkernel.
However, ARM merely reserves physical address zero with no checking that
there is even RAM there.

Fix this by lifting similar code from x86, importing it to ARM with the
ARM specific parameters added.  In the absence of any platform specific
information, we allocate the crashkernel region from the first 512MB of
physical memory.

Update the kdump documentation to reflect this change.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 Documentation/kdump/kdump.txt | 13 +++--
 arch/arm/kernel/setup.c   | 29 +
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index bc4bd5a44b88..88ff63d5fde3 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -263,12 +263,6 @@ been removed from the machine.
 crashkernel=:[,:,...][@offset]
 range=start-[end]
 
-Please note, on arm, the offset is required.
-crashkernel=:[,:,...]@offset
-range=start-[end]
-
-'start' is inclusive and 'end' is exclusive.
-
 For example:
 
 crashkernel=512M-2G:64M,2G-:128M
@@ -307,10 +301,9 @@ Boot into System Kernel
on the memory consumption of the kdump system. In general this is not
dependent on the memory size of the production system.
 
-   On arm, use "crashkernel=Y@X". Note that the start address of the kernel
-   will be aligned to 128MiB (0x0800), so if the start address is not then
-   any space below the alignment point may be overwritten by the dump-capture 
kernel,
-   which means it is possible that the vmcore is not that precise as expected.
+   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
+   kernel will automatically locate the crash kernel image within the
+   first 512MB of RAM if X is not given.
 
 
 Load the Dump-capture Kernel
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..77b54c461c52 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -938,6 +938,13 @@ static int __init init_machine_late(void)
 late_initcall(init_machine_late);
 
 #ifdef CONFIG_KEXEC
+/*
+ * The crash region must be aligned to 128MB to avoid
+ * zImage relocating below the reserved region.
+ */
+#define CRASH_ALIGN(128 << 20)
+#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
+
 static inline unsigned long long get_total_mem(void)
 {
unsigned long total;
@@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
if (ret)
return;
 
+   if (crash_base <= 0) {
+   unsigned long long crash_max = CRASH_ADDR_MAX;
+   if (crash_max > (u32)~0)
+   crash_max = (u32)~0;
+   crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
+   crash_size, CRASH_ALIGN);
+   if (!crash_base) {
+   pr_err("crashkernel reservation failed - No suitable 
area found.\n");
+   return;
+   }
+   } else {
+   unsigned long long start;
+
+   start = memblock_find_in_range(crash_base,
+  crash_base + crash_size,
+  crash_size, SECTION_SIZE);
+   if (start != crash_base) {
+   pr_err("crashkernel reservation failed - memory is in 
use.\n");
+   return;
+   }
+   }
+
ret = memblock_reserve(crash_base, crash_size);
if (ret < 0) {
pr_warn("crashkernel reservation failed - memory is in use 
(0x%lx)\n",
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: kexec: fix crashkernel= handling

[Russell King]

When the kernel crashkernel parameter is specified with just a size, we
are supposed to allocate a region from RAM to store the crashkernel.
However, ARM merely reserves physical address zero with no checking that
there is even RAM there.

Fix this by lifting similar code from x86, importing it to ARM with the
ARM specific parameters added.  In the absence of any platform specific
information, we allocate the crashkernel region from the first 512MB of
physical memory.

Update the kdump documentation to reflect this change.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 Documentation/kdump/kdump.txt | 13 +++--
 arch/arm/kernel/setup.c   | 29 +
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index bc4bd5a44b88..88ff63d5fde3 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -263,12 +263,6 @@ been removed from the machine.
 crashkernel=:[,:,...][@offset]
 range=start-[end]
 
-Please note, on arm, the offset is required.
-crashkernel=:[,:,...]@offset
-range=start-[end]
-
-'start' is inclusive and 'end' is exclusive.
-
 For example:
 
 crashkernel=512M-2G:64M,2G-:128M
@@ -307,10 +301,9 @@ Boot into System Kernel
on the memory consumption of the kdump system. In general this is not
dependent on the memory size of the production system.
 
-   On arm, use "crashkernel=Y@X". Note that the start address of the kernel
-   will be aligned to 128MiB (0x0800), so if the start address is not then
-   any space below the alignment point may be overwritten by the dump-capture 
kernel,
-   which means it is possible that the vmcore is not that precise as expected.
+   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
+   kernel will automatically locate the crash kernel image within the
+   first 512MB of RAM if X is not given.
 
 
 Load the Dump-capture Kernel
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..77b54c461c52 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -938,6 +938,13 @@ static int __init init_machine_late(void)
 late_initcall(init_machine_late);
 
 #ifdef CONFIG_KEXEC
+/*
+ * The crash region must be aligned to 128MB to avoid
+ * zImage relocating below the reserved region.
+ */
+#define CRASH_ALIGN(128 << 20)
+#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
+
 static inline unsigned long long get_total_mem(void)
 {
unsigned long total;
@@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
if (ret)
return;
 
+   if (crash_base <= 0) {
+   unsigned long long crash_max = CRASH_ADDR_MAX;
+   if (crash_max > (u32)~0)
+   crash_max = (u32)~0;
+   crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
+   crash_size, CRASH_ALIGN);
+   if (!crash_base) {
+   pr_err("crashkernel reservation failed - No suitable 
area found.\n");
+   return;
+   }
+   } else {
+   unsigned long long start;
+
+   start = memblock_find_in_range(crash_base,
+  crash_base + crash_size,
+  crash_size, SECTION_SIZE);
+   if (start != crash_base) {
+   pr_err("crashkernel reservation failed - memory is in 
use.\n");
+   return;
+   }
+   }
+
ret = memblock_reserve(crash_base, crash_size);
if (ret < 0) {
pr_warn("crashkernel reservation failed - memory is in use 
(0x%lx)\n",
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: fix crashkernel= handling

[Russell King - ARM Linux]

On Wed, Mar 30, 2016 at 09:27:08AM -0400, Vivek Goyal wrote:
> On Wed, Mar 30, 2016 at 02:05:30PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Mar 30, 2016 at 06:09:22PM +0530, Pratyush Anand wrote:
> > > On 30/03/2016:09:46:38 AM, Dave Young wrote:
> > > > Hi, Russell
> > > > 
> > > > A long standing issue, but nobody tried to do it. Thank you for 
> > > > bringing up.
> > > > 
> > > > On 03/29/16 at 11:10am, Russell King wrote:
> > > > > When the kernel crashkernel parameter is specified with just a size, 
> > > > > we
> > > > > are supposed to allocate a region from RAM to store the crashkernel.
> > > > > However, ARM merely reserves physical address zero with no checking
> > > > > that there is even RAM there.
> > > > > 
> > > > > Fix this by lifting similar code from x86, importing it to ARM with
> > > > > the ARM specific parameters added.
> > > > > 
> > > > > Update the kdump documentation to reflect this change.
> > > > > 
> > > > > Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
> > > > > ---
> > > > >  Documentation/kdump/kdump.txt | 13 +++--
> > > > >  arch/arm/kernel/setup.c   | 26 ++
> > > > >  2 files changed, 29 insertions(+), 10 deletions(-)
> > > > > 
> > > > > diff --git a/Documentation/kdump/kdump.txt 
> > > > > b/Documentation/kdump/kdump.txt
> > > > > index bc4bd5a44b88..88ff63d5fde3 100644
> > > > > --- a/Documentation/kdump/kdump.txt
> > > > > +++ b/Documentation/kdump/kdump.txt
> > > > > @@ -263,12 +263,6 @@ been removed from the machine.
> > > > >  crashkernel=:[,:,...][@offset]
> > > > >  range=start-[end]
> > > > >  
> > > > > -Please note, on arm, the offset is required.
> > > > > -crashkernel=:[,:,...]@offset
> > > > > -range=start-[end]
> > > > > -
> > > > > -'start' is inclusive and 'end' is exclusive.
> > > > > -
> > > > >  For example:
> > > > >  
> > > > >  crashkernel=512M-2G:64M,2G-:128M
> > > > > @@ -307,10 +301,9 @@ Boot into System Kernel
> > > > > on the memory consumption of the kdump system. In general this is 
> > > > > not
> > > > > dependent on the memory size of the production system.
> > > > >  
> > > > > -   On arm, use "crashkernel=Y@X". Note that the start address of the 
> > > > > kernel
> > > > > -   will be aligned to 128MiB (0x0800), so if the start address 
> > > > > is not then
> > > > > -   any space below the alignment point may be overwritten by the 
> > > > > dump-capture kernel,
> > > > > -   which means it is possible that the vmcore is not that precise as 
> > > > > expected.
> > > > > +   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
> > > > > +   kernel will automatically locate the crash kernel image within the
> > > > > +   first 512MB of RAM if X is not given.
> > > > >  
> > > > >  
> > > > >  Load the Dump-capture Kernel
> > > > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > > > index 7d0cba6f1cc5..5d8511c425f0 100644
> > > > > --- a/arch/arm/kernel/setup.c
> > > > > +++ b/arch/arm/kernel/setup.c
> > > > > @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
> > > > >  late_initcall(init_machine_late);
> > > > >  
> > > > >  #ifdef CONFIG_KEXEC
> > > > > +/*
> > > > > + * The crash region must be aligned to 128MB to avoid
> > > > > + * zImage relocating below the reserved region.
> > > > > + */
> > > > > +#define CRASH_ALIGN  (128 << 20)
> > > > > +#define CRASH_ADDR_MAX   (PHYS_OFFSET + (512 << 20))
> > > > 
> > > > Any reason to limit crash mem within the first 512M only? What if one 
> > > > want to
> > > > reserve memory over 512M?
> > > 
> > > When crash base is not give, then may be it can be just checked if 
> > > memblock
> > > region is memory and not reserved, then al

Re: [PATCH] ARM: kexec: fix crashkernel= handling

[Russell King - ARM Linux]

On Wed, Mar 30, 2016 at 06:09:22PM +0530, Pratyush Anand wrote:
> On 30/03/2016:09:46:38 AM, Dave Young wrote:
> > Hi, Russell
> > 
> > A long standing issue, but nobody tried to do it. Thank you for bringing up.
> > 
> > On 03/29/16 at 11:10am, Russell King wrote:
> > > When the kernel crashkernel parameter is specified with just a size, we
> > > are supposed to allocate a region from RAM to store the crashkernel.
> > > However, ARM merely reserves physical address zero with no checking
> > > that there is even RAM there.
> > > 
> > > Fix this by lifting similar code from x86, importing it to ARM with
> > > the ARM specific parameters added.
> > > 
> > > Update the kdump documentation to reflect this change.
> > > 
> > > Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
> > > ---
> > >  Documentation/kdump/kdump.txt | 13 +++--
> > >  arch/arm/kernel/setup.c   | 26 ++
> > >  2 files changed, 29 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> > > index bc4bd5a44b88..88ff63d5fde3 100644
> > > --- a/Documentation/kdump/kdump.txt
> > > +++ b/Documentation/kdump/kdump.txt
> > > @@ -263,12 +263,6 @@ been removed from the machine.
> > >  crashkernel=:[,:,...][@offset]
> > >  range=start-[end]
> > >  
> > > -Please note, on arm, the offset is required.
> > > -crashkernel=:[,:,...]@offset
> > > -range=start-[end]
> > > -
> > > -'start' is inclusive and 'end' is exclusive.
> > > -
> > >  For example:
> > >  
> > >  crashkernel=512M-2G:64M,2G-:128M
> > > @@ -307,10 +301,9 @@ Boot into System Kernel
> > > on the memory consumption of the kdump system. In general this is not
> > > dependent on the memory size of the production system.
> > >  
> > > -   On arm, use "crashkernel=Y@X". Note that the start address of the 
> > > kernel
> > > -   will be aligned to 128MiB (0x0800), so if the start address is 
> > > not then
> > > -   any space below the alignment point may be overwritten by the 
> > > dump-capture kernel,
> > > -   which means it is possible that the vmcore is not that precise as 
> > > expected.
> > > +   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
> > > +   kernel will automatically locate the crash kernel image within the
> > > +   first 512MB of RAM if X is not given.
> > >  
> > >  
> > >  Load the Dump-capture Kernel
> > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > index 7d0cba6f1cc5..5d8511c425f0 100644
> > > --- a/arch/arm/kernel/setup.c
> > > +++ b/arch/arm/kernel/setup.c
> > > @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
> > >  late_initcall(init_machine_late);
> > >  
> > >  #ifdef CONFIG_KEXEC
> > > +/*
> > > + * The crash region must be aligned to 128MB to avoid
> > > + * zImage relocating below the reserved region.
> > > + */
> > > +#define CRASH_ALIGN  (128 << 20)
> > > +#define CRASH_ADDR_MAX   (PHYS_OFFSET + (512 << 20))
> > 
> > Any reason to limit crash mem within the first 512M only? What if one want 
> > to
> > reserve memory over 512M?
> 
> When crash base is not give, then may be it can be just checked if memblock
> region is memory and not reserved, then allow to reserve. That might help to
> remove 512M restriction.

... and then I'll have to update the commit text.

You may notice that I say that this is mostly taken from the x86
implementation.  The x86 implementation also has this 512MB
allocation limit, to prevent it being placed too high in physical
memory.

This limit only applies for the case where the user hasn't specified
the base.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html