* [PATCH v2 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
From: Dhinakaran Pandiyan @ 2016-11-14 21:42 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
In-Reply-To: <1479159735-29364-1-git-send-email-dhinakaran.pandiyan@intel.com>
Not validating the mode rate against max. link rate results in not pruning
invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not
support 4k@60Hz. But, we do not reject this mode.
So, make use of the helpers in intel_dp to validate mode data rate against
max. link data rate of a configuration.
v2: Renamed mode data rate local variable to be more explanatory.
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0c5d4bd..a7393e8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
return min(source_max, sink_max);
}
-static int
+int
intel_dp_link_required(int pixel_clock, int bpp)
{
/* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
return DIV_ROUND_UP(pixel_clk * bpp, 8);
}
-static int
+int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..2c557d9 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -335,7 +335,17 @@ static enum drm_mode_status
intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ int link_clock = intel_dp_max_link_rate(intel_dp);
+ int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+ int bpp = 24; /* MST uses fixed bpp */
+ int mode_data_rate;
+ int link_max_data_rate;
+
+ mode_data_rate = intel_dp_link_required(mode->clock, bpp);
+ link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
/* TODO - validate mode against available PBN for link */
if (mode->clock < 10000)
@@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
- if (mode->clock > max_dotclk)
+ if (mode_data_rate > link_max_data_rate || mode->clock > max_dotclk)
return MODE_CLOCK_HIGH;
return MODE_OK;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2f3863..313419d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
bool __intel_dp_read_desc(struct intel_dp *intel_dp,
struct intel_dp_desc *desc);
bool intel_dp_read_desc(struct intel_dp *intel_dp);
+int intel_dp_link_required(int pixel_clock, int bpp);
+int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
/* intel_dp_aux_backlight.c */
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math
From: Dhinakaran Pandiyan @ 2016-11-14 21:42 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.
E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
Using link clock frequency, like we do
Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
Because, each symbol has 8 bit of data, this is 2160000 kBps
and there is no need to account for channel encoding here.
But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps
v2: Changed to DIV_ROUND_UP() and comment changes (Ville)
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..0c5d4bd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
return min(source_max, sink_max);
}
-/*
- * The units on the numbers in the next two are... bizarre. Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- * 270000 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits. ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000. At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
static int
intel_dp_link_required(int pixel_clock, int bpp)
{
- return (pixel_clock * bpp + 9) / 10;
+ /* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
+ return DIV_ROUND_UP(pixel_clk * bpp, 8);
}
static int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
- return (max_link_clock * max_lanes * 8) / 10;
+ /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+ * link rate that is generally expressed in Gbps. Since, 8 bits of data
+ * is transmitted every LS_Clk per lane, there is no need to account for
+ * the channel encoding that is done in the PHY layer here.
+ */
+
+ return max_link_clock * max_lanes;
}
static int
@@ -3573,7 +3563,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (val == 0)
break;
- /* Value read is in kHz while drm clock is saved in deca-kHz */
+ /* Value read multiplied by 200kHz gives the per-lane
+ * link rate in kHz. The source rates are, however,
+ * stored in terms of LS_Clk kHz. The full conversion
+ * back to symbols is
+ * (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
+ */
intel_dp->sink_rates[i] = (val * 200) / 10;
}
intel_dp->num_sink_rates = i;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH nft] mnl: use nftnl_set_elems_nlmsg_build_payload_iter() when deleting elements
From: Pablo Neira Ayuso @ 2016-11-14 21:41 UTC (permalink / raw)
To: netfilter-devel
Otherwise, nft crashes when deleting a very large number of elements.
*** stack smashing detected ***: nft terminated
Segmentation fault
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
src/mnl.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/src/mnl.c b/src/mnl.c
index 52875f4a16da..137ecf0d1e01 100644
--- a/src/mnl.c
+++ b/src/mnl.c
@@ -867,8 +867,9 @@ static int set_elem_cb(const struct nlmsghdr *nlh, void *data)
return MNL_CB_OK;
}
-int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
- uint32_t seqnum)
+static int mnl_nft_setelem_batch(struct nftnl_set *nls,
+ enum nf_tables_msg_types cmd,
+ unsigned int flags, uint32_t seqnum)
{
struct nlmsghdr *nlh;
struct nftnl_set_elems_iter *iter;
@@ -880,8 +881,7 @@ int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
do {
nlh = nftnl_set_elem_nlmsg_build_hdr(nftnl_batch_buffer(batch),
- NFT_MSG_NEWSETELEM,
- nftnl_set_get_u32(nls, NFTNL_SET_FAMILY),
+ cmd, nftnl_set_get_u32(nls, NFTNL_SET_FAMILY),
NLM_F_CREATE | flags, seqnum);
ret = nftnl_set_elems_nlmsg_build_payload_iter(nlh, iter);
mnl_nft_batch_continue();
@@ -892,19 +892,16 @@ int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
return 0;
}
-int mnl_nft_setelem_batch_del(struct nftnl_set *nls, unsigned int flags,
+int mnl_nft_setelem_batch_add(struct nftnl_set *nls, unsigned int flags,
uint32_t seqnum)
{
- struct nlmsghdr *nlh;
-
- nlh = nftnl_set_elem_nlmsg_build_hdr(nftnl_batch_buffer(batch),
- NFT_MSG_DELSETELEM,
- nftnl_set_get_u32(nls, NFTNL_SET_FAMILY),
- 0, seqnum);
- nftnl_set_elems_nlmsg_build_payload(nlh, nls);
- mnl_nft_batch_continue();
+ return mnl_nft_setelem_batch(nls, NFT_MSG_NEWSETELEM, flags, seqnum);
+}
- return 0;
+int mnl_nft_setelem_batch_del(struct nftnl_set *nls, unsigned int flags,
+ uint32_t seqnum)
+{
+ return mnl_nft_setelem_batch(nls, NFT_MSG_DELSETELEM, flags, seqnum);
}
int mnl_nft_setelem_get(struct mnl_socket *nf_sock, struct nftnl_set *nls)
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 2/3] cpuidle: allow setting deepest idle
From: Rafael J. Wysocki @ 2016-11-14 21:42 UTC (permalink / raw)
To: Jacob Pan
Cc: Peter Zijlstra, Ingo Molnar, Thomas Gleixner, LKML, Linux PM,
Arjan van de Ven, Srinivas Pandruvada, Len Brown, Rafael Wysocki,
Eduardo Valentin, Zhang Rui, Petr Mladek,
Sebastian Andrzej Siewior
In-Reply-To: <1479149278-12418-3-git-send-email-jacob.jun.pan@linux.intel.com>
On Monday, November 14, 2016 10:47:57 AM Jacob Pan wrote:
> When idle injection is used to cap power, we need to override
> governor's choice of idle states. This patch allows caller to select
> the deepest idle state on a CPU therefore achieve the maximum
> potential power saving.
>
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> ---
> drivers/cpuidle/cpuidle.c | 11 +++++++++++
> include/linux/cpuidle.h | 4 +++-
> kernel/sched/idle.c | 3 +++
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index c73207a..887a52a 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -97,6 +97,17 @@ static int find_deepest_state(struct cpuidle_driver *drv,
> return ret;
> }
>
> +/* Set the current cpu to use the deepest idle state, override governors */
> +void cpuidle_use_deepest_state(bool enable)
> +{
> + struct cpuidle_device *dev;
> +
> + preempt_disable();
> + dev = cpuidle_get_device();
> + dev->use_deepest_state = enable;
> + preempt_enable();
> +}
> +
> #ifdef CONFIG_SUSPEND
> /**
> * cpuidle_find_deepest_state - Find the deepest available idle state.
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index bb31373..7f93c63 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -74,6 +74,7 @@ struct cpuidle_state {
> struct cpuidle_device {
> unsigned int registered:1;
> unsigned int enabled:1;
> + unsigned int use_deepest_state:1;
> unsigned int cpu;
>
> int last_residency;
> @@ -192,11 +193,12 @@ static inline struct cpuidle_driver *cpuidle_get_cpu_driver(
> static inline struct cpuidle_device *cpuidle_get_device(void) {return NULL; }
> #endif
>
> -#if defined(CONFIG_CPU_IDLE) && defined(CONFIG_SUSPEND)
> +#if defined(CONFIG_CPU_IDLE)
#ifdef CONFIG_CPU_IDLE
would be more ususal.
> extern int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
> struct cpuidle_device *dev);
> extern int cpuidle_enter_freeze(struct cpuidle_driver *drv,
> struct cpuidle_device *dev);
> +extern void cpuidle_use_deepest_state(bool enable);
> #else
> static inline int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
> struct cpuidle_device *dev)
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index cb6442f..9e80f32 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -173,6 +173,9 @@ static void cpuidle_idle_call(void)
>
> next_state = cpuidle_find_deepest_state(drv, dev);
> call_cpuidle(drv, dev, next_state);
> + } else if (dev->use_deepest_state) {
> + next_state = cpuidle_find_deepest_state(drv, dev);
> + call_cpuidle(drv, dev, next_state);
> } else {
> /*
> * Ask the cpuidle framework to choose a convenient idle state.
I would arrange the code slightly differently here:
if (idle_should_freeze() || dev->use_deepest_state) {
if (idle_should_freeze()) {
entered_state = cpuidle_enter_freeze(drv, dev);
if (entered_state > 0) {
local_irq_enable();
goto exit_idle;
}
}
next_state = cpuidle_find_deepest_state(drv, dev);
call_cpuidle(drv, dev, next_state);
} else {
This way you'd avoid the ugly code duplication and the extra
dev->use_deepest_state branch in the most frequent case. I guess you could
take the unlikely() thing away from idle_should_freeze() and use it directly
here too.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH net-next] mdio: Demote print from info to debug in mdio_driver_register
From: David Miller @ 2016-11-14 21:41 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew
In-Reply-To: <20161114030117.25169-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 13 Nov 2016 19:01:17 -0800
> While it is useful to know which MDIO driver is being registered, demote
> the pr_info() to a pr_debug().
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: stmmac: Fix lack of link transition for fixed PHYs
From: David Miller @ 2016-11-14 21:40 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, peppe.cavallaro, alexandre.torgue, linux-kernel
In-Reply-To: <20161114015036.6926-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 13 Nov 2016 17:50:35 -0800
> Commit 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch
> is attached") added some logic to avoid polling the fixed PHY and
> therefore invoking the adjust_link callback more than once, since this
> is a fixed PHY and link events won't be generated.
>
> This works fine the first time, because we start with phydev->irq =
> PHY_POLL, so we call adjust_link, then we set phydev->irq =
> PHY_IGNORE_INTERRUPT and we stop polling the PHY.
>
> Now, if we called ndo_close(), which calls both phy_stop() and does an
> explicit netif_carrier_off(), we end up with a link down. Upon calling
> ndo_open() again, despite starting the PHY state machine, we have
> PHY_IGNORE_INTERRUPT set, and we generate no link event at all, so the
> link is permanently down.
>
> 52f95bbfcf72 ("stmmac: fix adjust link call in case of a switch is attached")
I added the missing "Fixes: " here.
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Bjorn Helgaas @ 2016-11-14 21:40 UTC (permalink / raw)
To: Julia Lawall; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <1477769829-22230-14-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @rw@
> declarer name DEVICE_ATTR;
> identifier x,x_show,x_store;
> @@
>
> DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
>
> @script:ocaml@
> x << rw.x;
> x_show << rw.x_show;
> x_store << rw.x_store;
> @@
>
> if not (x^"_show" = x_show && x^"_store" = x_store)
> then Coccilib.include_match false
>
> @@
> declarer name DEVICE_ATTR_RW;
> identifier rw.x,rw.x_show,rw.x_store;
> @@
>
> - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> + DEVICE_ATTR_RW(x);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
I applied this to pci/aspm to follow the herd, although it looks
pretty similar to the ill-fated "Replace numeric parameter like 0444
with macro" series (http://lwn.net/Articles/696229/). Maybe this is
different because everybody except me knows what ATTR_RW means? To
me, "0644" contained more information than "_RW" does.
I do certainly like the removal of the "_show" and "_store"
redundancy.
> ---
> drivers/pci/pcie/aspm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 0ec649d..3b14d9e 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> return n;
> }
>
> -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> +static DEVICE_ATTR_RW(link_state);
> +static DEVICE_ATTR_RW(clk_ctl);
>
> static char power_group[] = "power";
> void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
>
^ permalink raw reply
* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Bjorn Helgaas @ 2016-11-14 21:40 UTC (permalink / raw)
To: Julia Lawall; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <1477769829-22230-14-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @rw@
> declarer name DEVICE_ATTR;
> identifier x,x_show,x_store;
> @@
>
> DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
>
> @script:ocaml@
> x << rw.x;
> x_show << rw.x_show;
> x_store << rw.x_store;
> @@
>
> if not (x^"_show" = x_show && x^"_store" = x_store)
> then Coccilib.include_match false
>
> @@
> declarer name DEVICE_ATTR_RW;
> identifier rw.x,rw.x_show,rw.x_store;
> @@
>
> - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> + DEVICE_ATTR_RW(x);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
I applied this to pci/aspm to follow the herd, although it looks
pretty similar to the ill-fated "Replace numeric parameter like 0444
with macro" series (http://lwn.net/Articles/696229/). Maybe this is
different because everybody except me knows what ATTR_RW means? To
me, "0644" contained more information than "_RW" does.
I do certainly like the removal of the "_show" and "_store"
redundancy.
> ---
> drivers/pci/pcie/aspm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 0ec649d..3b14d9e 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> return n;
> }
>
> -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> +static DEVICE_ATTR_RW(link_state);
> +static DEVICE_ATTR_RW(clk_ctl);
>
> static char power_group[] = "power";
> void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
>
^ permalink raw reply
* [U-Boot] [PATCH v4 00/14] efi: x86: Add EFI hello world and loader support for x86
From: Simon Glass @ 2016-11-14 21:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478533636-17577-1-git-send-email-sjg@chromium.org>
Resend attempt...
On 7 November 2016 at 08:47, Simon Glass <sjg@chromium.org> wrote:
> This series adds EFI loader support for x86. Since U-Boot already supports
> running as an EFI app (and as a payload) this is relatively
> straightforward, requiring just moving files into place and updating a few
> compiler flags.
>
> One problem with the EFI loader is that it lacks even rudimentary test
> support within U-Boot. At present the only way to test it is to boot an
> EFI application. As a step towards correcting this, this series also adds
> support for a 'hello world' test program which can be used to make sure
> that EFI loader support works correctly on a supported architecture. It is
> only a very simple program (it makes just two API calls!) but it does
> provide a sanity check and can be expanded as needed.
>
> No attempt is made to create a pytest with this, but it should be fairly
> straightforward to do so.
>
> Changes in v4:
> - Move hello world test program into new patch
> - Add new patch to add EFI app support
> - Add new patch to add EFI app support on aarch64
> - Use the build-generated 'hello world' program instead of a binary blob
> - Add new patch to adjust EFI files support efi_loader
> - Drop the binary 'hello world' program
>
> Changes in v3:
> - Include a link to the program instead of adding it to the tree
> - Fix several typos
> - Align backslashes to the same column
>
> Changes in v2:
> - Add new patch to tidy up selection of building the EFI stub
> - Remove EFI support from README.x86 TODO list
>
> Simon Glass (14):
> x86: Correct a build warning in x86 tables
> efi: Correct cache flush alignment
> efi: Fix debug message address format
> x86: Tidy up selection of building the EFI stub
> efi: Makefile: Export variables for use with EFI
> efi: Add support for a hello world test program
> elf: arm: Add a few ARM relocation types
> efi: arm: Add EFI app support
> efi: arm: Add aarch64 EFI app support
> efi: arm: Enable the hello world test program
> x86: Move efi .lds files into the 'lib' directory
> x86: Move efi .S files into the 'lib' directory
> efi: x86: Adjust EFI files support efi_loader
> x86: Enable EFI loader support
>
> Makefile | 11 +-
> arch/arm/config.mk | 7 ++
> arch/arm/cpu/armv8/config.mk | 4 +
> arch/arm/lib/Makefile | 10 ++
> arch/arm/lib/crt0_aarch64_efi.S | 135 ++++++++++++++++++++
> arch/arm/lib/crt0_arm_efi.S | 138 +++++++++++++++++++++
> arch/arm/lib/elf_aarch64_efi.lds | 70 +++++++++++
> arch/arm/lib/elf_arm_efi.lds | 70 +++++++++++
> arch/arm/lib/reloc_aarch64_efi.c | 87 +++++++++++++
> arch/arm/lib/reloc_arm_efi.c | 66 ++++++++++
> arch/arm/lib/relocate.S | 3 +-
> arch/arm/lib/relocate_64.S | 3 +-
> arch/x86/config.mk | 20 ++-
> arch/x86/lib/Makefile | 23 ++++
> .../lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} | 0
> .../{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} | 0
> arch/x86/lib/efi/Makefile | 18 ---
> arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds | 2 -
> arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds | 2 -
> .../x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} | 0
> .../lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} | 0
> arch/x86/lib/tables.c | 2 +
> cmd/Kconfig | 10 ++
> cmd/bootefi.c | 29 +++--
> configs/efi-x86_defconfig | 1 +
> configs/qemu-x86_efi_payload64_defconfig | 1 +
> configs/stm32f429-discovery_defconfig | 1 +
> doc/README.efi | 22 ++++
> doc/README.x86 | 1 -
> include/asm-generic/sections.h | 2 +
> include/efi.h | 7 +-
> include/elf.h | 13 ++
> lib/efi/Makefile | 4 +-
> lib/efi_loader/Kconfig | 2 +-
> lib/efi_loader/Makefile | 4 +
> lib/efi_loader/efi_image_loader.c | 3 +-
> lib/efi_loader/helloworld.c | 24 ++++
> scripts/Makefile.lib | 33 +++++
> 38 files changed, 787 insertions(+), 41 deletions(-)
> create mode 100644 arch/arm/lib/crt0_aarch64_efi.S
> create mode 100644 arch/arm/lib/crt0_arm_efi.S
> create mode 100644 arch/arm/lib/elf_aarch64_efi.lds
> create mode 100644 arch/arm/lib/elf_arm_efi.lds
> create mode 100644 arch/arm/lib/reloc_aarch64_efi.c
> create mode 100644 arch/arm/lib/reloc_arm_efi.c
> rename arch/x86/lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} (100%)
> rename arch/x86/lib/{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} (100%)
> rename arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds (98%)
> rename arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds (98%)
> rename arch/x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} (100%)
> rename arch/x86/lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} (100%)
> create mode 100644 lib/efi_loader/helloworld.c
>
> --
> 2.8.0.rc3.226.g39d4020
>
^ permalink raw reply
* Out-of-tree module build against yocto kernel
From: Ed @ 2016-11-14 21:38 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
I want to build an out-of-tree kernel module against my Yocto-generated
kernel (cross-compiled, not on the target).
I know that I can modify the hello-mod recipe to build it alongside the
Yocto image, but I'd strongly prefer not to; it's not a workflow that's
conducive to rapid iteration during development & test.
I've tried building against the kernel in
<TMP>/work-shared/<MACHINE>/kernel-source, to no avail. While I don't
understand everytihng that's going on, I suspect it has something to do
with how Yocto organizes kernel build artifacts (autoconf headers,
Module.symvers, conf stuff).
I've also tried building a SDK. By default that didn't seem to include
kernel headers, so I added kernel-devsrc to TOOLCHAIN_TARGET_TASK in
populate_sdk_base.bbclass. That seemed to get me kernel source w/ the SDK,
but I still haven't been able to successfully build against it.
A great deal of my troubleshooting has been driven by the a 2013 discussion
on this list that appeared to end inconclusively:
https://lists.yoctoproject.org/pipermail/yocto/2013-January/011564.html
Am I going about this in the right way? Am I just missing some
configuration/setup steps, or am I going about this all wrong? Everything
I'm trying feels clunky and hack-ish.
--
Ed Laird
On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the
machine wrong figures, will the right answers come out?" ... I am not able
rightly to apprehend the kind of confusion of ideas that could provoke such
a question.
—Charles Babbage, Passages from the Life of a Philosopher
<http://en.wikipedia.org/wiki/Charles_Babbage>
[-- Attachment #2: Type: text/html, Size: 2032 bytes --]
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Heiko Stuebner @ 2016-11-14 21:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kishon Vijay Abraham I, Wei Yongjun, Bjorn Helgaas, Wei Yongjun,
linux-omap, linux-pci, Shawn Lin, michal.simek, soren.brinkmann,
bharat.kumar.gogada, robh, Frank Rowand, devicetree
In-Reply-To: <20161114211928.GD9868@bhelgaas-glaptop.roam.corp.google.com>
Am Montag, 14. November 2016, 15:19:28 CET schrieb Bjorn Helgaas:
> [+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
>
> On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> > >> From: Wei Yongjun <weiyongjun1@huawei.com>
> > >>
> > >> This node pointer is returned by of_get_next_child() with refcount
> > >> incremented in this function. of_node_put() on it before exitting
> > >> this function on error.
> > >>
> > >> This is detected by Coccinelle semantic patch.
> > >>
> > >> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > >
> > > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > > v4.10. Let me know if you have any issue with it.
> > >
> > >> ---
> > >>
> > >> drivers/pci/host/pci-dra7xx.c | 1 +
> > >> 1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/drivers/pci/host/pci-dra7xx.c
> > >> b/drivers/pci/host/pci-dra7xx.c
> > >> index 9595fad..79297e9 100644
> > >> --- a/drivers/pci/host/pci-dra7xx.c
> > >> +++ b/drivers/pci/host/pci-dra7xx.c
> > >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct
> > >> pcie_port *pp)> >>
> > >> &intx_domain_ops, pp);
> > >>
> > >> if (!pp->irq_domain) {
> > >>
> > >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> > >>
> > >> + of_node_put(pcie_intc_node);
> >
> > I think of_node_put should be used for both the error case and non-error
> > case.
> Hmm, OK. I don't know what the rules are. Certainly if we made these
> drivers modular, I don't think we'd want to leak these references
> every time we unload/reload the module. Should we do the put
> immediately here, or in the module remove path, or ...?
>
> Adding other driver and DT folks for comment.
I think the function above (dra7xx_pcie_init_irq_domain) can do the
of_node_put at its end in all cases as suggested by Kishon.
of_get_next_child() will increment the refcount
irq_domain_add_linear()
__irq_domain_add() also increments the refcount
irq_domain_remove() will decrement the refcount
So it should be safe to decrement the refcount in
dra7xx_pcie_init_irq_domain() in all cases as the irq-domain internals will
always keep it above 1 as long as the node is used.
Heiko
^ permalink raw reply
* [PATCH] can: spi: hi311x: fix semicolon.cocci warnings (fwd)
From: Julia Lawall @ 2016-11-14 21:36 UTC (permalink / raw)
To: Akshay Bhat
Cc: wg, mkl, robh+dt, mark.rutland, linux-can, netdev, devicetree,
linux-kernel, Akshay Bhat, Akshay Bhat
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
It's a minor issue, but may as well fix it up now. The tree this code is
from is as follows:
url:
https://github.com/0day-ci/linux/commits/Akshay-Bhat/can-holt_hi311x-documen
t-device-tree-bindings/20161115-034509
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
hi311x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/spi/hi311x.c
+++ b/drivers/net/can/spi/hi311x.c
@@ -673,7 +673,7 @@ static irqreturn_t hi3110_can_ist(int ir
while (!(HI3110_STAT_RXFMTY &
hi3110_read(spi, HI3110_READ_STATF))) {
hi3110_hw_rx(spi);
- };
+ }
intf = hi3110_read(spi, HI3110_READ_INTF);
eflag = hi3110_read(spi, HI3110_READ_ERR);
^ permalink raw reply
* Re: [PATCH net-next 1/1] driver: macvlan: Replace integer number with bool value
From: David Miller @ 2016-11-14 21:36 UTC (permalink / raw)
To: fgao; +Cc: kaber, netdev, gfree.wind
In-Reply-To: <1479083059-12688-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Mon, 14 Nov 2016 08:24:19 +0800
> From: Gao Feng <gfree.wind@gmail.com>
>
> The return value of function macvlan_addr_busy is used as bool value,
> so use bool value instead of integer number "1" and "0".
>
> Signed-off-by: Gao Feng <gfree.wind@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] can: spi: hi311x: fix semicolon.cocci warnings (fwd)
From: Julia Lawall @ 2016-11-14 21:36 UTC (permalink / raw)
Cc: wg, mkl, robh+dt, mark.rutland, linux-can, netdev, devicetree,
linux-kernel, Akshay Bhat, Akshay Bhat
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
It's a minor issue, but may as well fix it up now. The tree this code is
from is as follows:
url:
https://github.com/0day-ci/linux/commits/Akshay-Bhat/can-holt_hi311x-documen
t-device-tree-bindings/20161115-034509
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
hi311x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/spi/hi311x.c
+++ b/drivers/net/can/spi/hi311x.c
@@ -673,7 +673,7 @@ static irqreturn_t hi3110_can_ist(int ir
while (!(HI3110_STAT_RXFMTY &
hi3110_read(spi, HI3110_READ_STATF))) {
hi3110_hw_rx(spi);
- };
+ }
intf = hi3110_read(spi, HI3110_READ_INTF);
eflag = hi3110_read(spi, HI3110_READ_ERR);
^ permalink raw reply
* [U-Boot] [PATCH v6 2/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 MSI node
From: york sun @ 2016-11-14 21:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1477970547-28846-2-git-send-email-wenbin.song@nxp.com>
On 10/31/2016 08:35 PM, Wenbin song wrote:
> There are two types of msi node in kernel device tree, one is for
> LS1043A rev1.1 silicon, the other is for rev1.0.
This doesn't explain the difference between the two versions. I don't
see comments below either.
>
> According to revision number, fixup the msi node.
>
> Signed-off-by: Wenbin Song <wenbin.song@nxp.com>
> Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
> ---
> Change in v6:
> None
> Change in v5:
> Fixup the msi node used on rev1.0 when running on rev1.1.
> ---
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 3 +
> arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 115 ++++++++++++++++++++++++++++++
> 2 files changed, 118 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index f415868..34ac867 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -139,4 +139,7 @@ config HAS_FEATURE_GIC4K_ALIGN
> bool
> default y if ARCH_LS1043A
>
> +config HAS_FEATURE_ENHANCED_MSI
> + bool
> + default y if ARCH_LS1043A
> endmenu
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 9936be1..e87ba19 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -194,6 +194,118 @@ static void fdt_fixup_gic(void *blob)
> }
> #endif
>
> +#ifdef CONFIG_HAS_FEATURE_ENHANCED_MSI
> +static int _fdt_fixup_msi_subnode(void *blob, int offset, const char *name,
> + int irq_0, int irq_1, int rev)
> +{
> + int err, sub_offset, len;
> + u32 tmp[4][3];
> +
> + sub_offset = fdt_subnode_offset(blob, offset, name);
> + if (offset < 0) {
> + printf("WARNING: fdt_subnode_offset can't find %s: %s\n",
> + name, fdt_strerror(sub_offset));
> + return 0;
> + }
> +
> + tmp[0][0] = cpu_to_fdt32(0x0);
> + tmp[0][1] = cpu_to_fdt32(irq_0);
> + tmp[0][2] = cpu_to_fdt32(0x4);
> +
> + if (rev > REV1_0) {
> + tmp[1][0] = cpu_to_fdt32(0x0);
> + tmp[1][1] = cpu_to_fdt32(irq_1);
> + tmp[1][2] = cpu_to_fdt32(0x4);
> + tmp[2][0] = cpu_to_fdt32(0x0);
> + tmp[2][1] = cpu_to_fdt32(irq_1 + 1);
> + tmp[2][2] = cpu_to_fdt32(0x4);
> + tmp[3][0] = cpu_to_fdt32(0x0);
> + tmp[3][1] = cpu_to_fdt32(irq_1 + 2);
> + tmp[3][2] = cpu_to_fdt32(0x4);
> + len = sizeof(tmp);
Looks like you are adding three more interrupts. Some comments here
would be nice.
> + } else {
> + len = sizeof(tmp[0]);
> + }
> +
> + err = fdt_setprop(blob, sub_offset, "interrupts", tmp, len);
> + if (err < 0) {
> + printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
> + "interrupts", name, fdt_strerror(err));
> + return 0;
> + }
> +
> + return 1;
> +}
> +
> +static int _fdt_fixup_pci_msi(void *blob, const char *name, int rev)
> +{
> + int offset, len, err;
> + void *p;
> + int val;
> + u32 tmp[4][8];
> +
> + offset = fdt_path_offset(blob, name);
> + if (offset < 0) {
> + printf("WARNING: fdt_path_offset can't find path %s: %s\n",
> + name, fdt_strerror(offset));
> + return 0;
> + }
> +
> + p = (char *)fdt_getprop(blob, offset, "interrupt-map", &len);
> + if (!p || len != sizeof(tmp)) {
Is the length check always accurate here?
> + printf("WARNING: fdt_getprop can't get %s from node %s\n",
> + "interrupt-map", name);
> + return 0;
> + }
> +
> + memcpy((char *)tmp, p, len);
> +
> + val = fdt32_to_cpu(tmp[0][6]);
> + if (rev > REV1_0) {
> + tmp[1][6] = cpu_to_fdt32(val + 1);
> + tmp[2][6] = cpu_to_fdt32(val + 2);
> + tmp[3][6] = cpu_to_fdt32(val + 3);
> + } else {
> + tmp[1][6] = cpu_to_fdt32(val);
> + tmp[2][6] = cpu_to_fdt32(val);
> + tmp[3][6] = cpu_to_fdt32(val);
> + }
> +
> + err = fdt_setprop(blob, offset, "interrupt-map", tmp, sizeof(tmp));
> + if (err < 0) {
> + printf("WARNING: fdt_setprop can't set %s from node %s: %s.\n",
> + "interrupt-map", name, fdt_strerror(err));
> + return 0;
> + }
> + return 1;
> +}
> +
> +/* Fixup msi to v1_0*/
> +
This comment is not accurate. You are fixing msi for both 1.0 and 1.1.
York
^ permalink raw reply
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: NeilBrown @ 2016-11-14 21:35 UTC (permalink / raw)
To: Mark Brown
Cc: Baolin Wang, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
In-Reply-To: <20161114120430.hpnetdedyofhlkad@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3323 bytes --]
On Mon, Nov 14 2016, Mark Brown wrote:
> On Mon, Nov 14, 2016 at 03:21:13PM +1100, NeilBrown wrote:
>> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> > Fourth, we need integrate all charger plugin/out
>> > event in one framework, not from extcon, maybe type-c in future.
>
>> Why not extcon? Given that a charger is connected by an external
>> connector, extcon seems like exactly the right thing to use.
>
>> Obviously extcon doesn't report the current that was negotiated, but
>> that is best kept separate. The battery charger can be advised of the
>> available current either via extcon or separately via the usb
>> subsystem. Don't conflate the two.
>
> Conflating the two seems like the whole point here. We're looking for
> something that sits between the power supply code and the USB code and
> tells the power supply code what it's allowed to do which is the result
> of a combination of physical cable detection and USB protocol. It seems
> reasonable that extcon drivers ought to be part of this but it doesn't
> seem like they are the whole story.
I don't think "between the power supply code and the USB code" is where
this thing sits. I think it sits inside the power-supply driver.
We already have extcon which sits between the phy and the power_supply
code, and the usb_notifier which sits between the USB code and the
power supply code. We don't need another go-between.
If we have extcon able to deliver reliable information about cable type,
and if with have the usb notifier able to deliver reliable information
about negotiated current, and if the power supply manager is able to
register with the correct extcon and the correct usb notifier, then the
power supply manager *could* handle all the notifications and make the
correct determinations and set the current limits itself. All this
could be done entirely internally, without the help of any new
subsystem.
Do you agree?
Clearly doing it that way would result in lots of code duplication and
would mean that each driver probably gets its own private set of bugs,
but it would be possible. Just undesirable.
So yes, it makes perfect to provide common code which handles the
registrations, and captures the events, and translates the different
events into current levels and feeds those back to the driver. This
isn't some new subsystem, this is just a resource, provided by a
library, that power drivers can allocate and initialize if the want to.
To quote myself:
> 5/ Now that all cable connection notifications are sent over extcon and
> all vbus_draw notifications are sent over the usb_phy notifier, write
> some support code that a power supply client can use to be told what
> power is available.
> e.g. a battery charger driver would call:
> register_power_client(.....)
> or similar, providing a phandle (or similar) for the usb phy and a
> function to call back when the available current changes (or maybe a
> work_struct containing the function pointer)
>
> register_power_client() would then register with extcon and separately
> with the usb_phy notifier. When the different events arrive it
> calculates what ranges of currents are expected and calls the
> call-back function with those details.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
From: Pandiyan, Dhinakaran @ 2016-11-14 21:35 UTC (permalink / raw)
To: Navare, Manasi D; +Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org
In-Reply-To: <20161110233256.GA4623@intel.com>
On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. But, we do not reject this mode currently.
> >
> > So, make use of the helpers in intel_dp in validate mode rates against
> > max. data rate of a configuration.
> >
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> > drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 3 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 7a9e122..7a73e43 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > return min(source_max, sink_max);
> > }
> >
> > -static int
> > +int
> > intel_dp_link_required(int pixel_clock, int bpp)
> > {
> > /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > return (pixel_clock * bpp + 7) / 8;
> > }
> >
> > -static int
> > +int
> > intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> > {
> > /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..38d2ce0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -335,7 +335,17 @@ static enum drm_mode_status
> > intel_dp_mst_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > {
> > + struct intel_connector *intel_connector = to_intel_connector(connector);
> > + struct intel_dp *intel_dp = intel_connector->mst_port;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > + int link_clock = intel_dp_max_link_rate(intel_dp);
> > + int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > + int bpp = 24; /* MST uses fixed bpp */
> > + int mode_rate;
> > + int link_max_data_rate;
>
> In the SST equivalent mode_valid function, this variable is named as
> max_rate, I think you should name it as max_rate as well for consistency.
> Other than that this looks good, we definitely need this for mode validation
> at an early stage.
>
> Regards
> Manasi
>
Well, one of the goals of Patch 1/2 is to reduce ambiguity that has led
to some confusing hacks. I prefer clarity over consistency and anyway
this variable is local to this function :)
-DK
> > +
> > + link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > + mode_rate = intel_dp_link_required(mode->clock, bpp);
> >
> > /* TODO - validate mode against available PBN for link */
> > if (mode->clock < 10000)
> > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > return MODE_H_ILLEGAL;
> >
> > - if (mode->clock > max_dotclk)
> > + if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> >
> > return MODE_OK;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index c2f3863..313419d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> > struct intel_dp_desc *desc);
> > bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > +int intel_dp_link_required(int pixel_clock, int bpp);
> > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >
> > /* intel_dp_aux_backlight.c */
> > int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: NeilBrown @ 2016-11-14 21:35 UTC (permalink / raw)
To: Mark Brown
Cc: Baolin Wang, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, John Stultz,
Charles Keepax, patches, Linux PM list, USB
In-Reply-To: <20161114120430.hpnetdedyofhlkad@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3323 bytes --]
On Mon, Nov 14 2016, Mark Brown wrote:
> On Mon, Nov 14, 2016 at 03:21:13PM +1100, NeilBrown wrote:
>> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> > Fourth, we need integrate all charger plugin/out
>> > event in one framework, not from extcon, maybe type-c in future.
>
>> Why not extcon? Given that a charger is connected by an external
>> connector, extcon seems like exactly the right thing to use.
>
>> Obviously extcon doesn't report the current that was negotiated, but
>> that is best kept separate. The battery charger can be advised of the
>> available current either via extcon or separately via the usb
>> subsystem. Don't conflate the two.
>
> Conflating the two seems like the whole point here. We're looking for
> something that sits between the power supply code and the USB code and
> tells the power supply code what it's allowed to do which is the result
> of a combination of physical cable detection and USB protocol. It seems
> reasonable that extcon drivers ought to be part of this but it doesn't
> seem like they are the whole story.
I don't think "between the power supply code and the USB code" is where
this thing sits. I think it sits inside the power-supply driver.
We already have extcon which sits between the phy and the power_supply
code, and the usb_notifier which sits between the USB code and the
power supply code. We don't need another go-between.
If we have extcon able to deliver reliable information about cable type,
and if with have the usb notifier able to deliver reliable information
about negotiated current, and if the power supply manager is able to
register with the correct extcon and the correct usb notifier, then the
power supply manager *could* handle all the notifications and make the
correct determinations and set the current limits itself. All this
could be done entirely internally, without the help of any new
subsystem.
Do you agree?
Clearly doing it that way would result in lots of code duplication and
would mean that each driver probably gets its own private set of bugs,
but it would be possible. Just undesirable.
So yes, it makes perfect to provide common code which handles the
registrations, and captures the events, and translates the different
events into current levels and feeds those back to the driver. This
isn't some new subsystem, this is just a resource, provided by a
library, that power drivers can allocate and initialize if the want to.
To quote myself:
> 5/ Now that all cable connection notifications are sent over extcon and
> all vbus_draw notifications are sent over the usb_phy notifier, write
> some support code that a power supply client can use to be told what
> power is available.
> e.g. a battery charger driver would call:
> register_power_client(.....)
> or similar, providing a phandle (or similar) for the usb phy and a
> function to call back when the available current changes (or maybe a
> work_struct containing the function pointer)
>
> register_power_client() would then register with extcon and separately
> with the usb_phy notifier. When the different events arrive it
> calculates what ranges of currents are expected and calls the
> call-back function with those details.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program
From: Simon Glass @ 2016-11-14 21:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <477cfddb-1d3c-ede3-d106-f71ab17a4a01@suse.de>
Hi Alex,
On 14 November 2016 at 14:24, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 14/11/2016 21:58, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 14 November 2016 at 13:46, Alexander Graf <agraf@suse.de> wrote:
>>>
>>>
>>>
>>> On 14/11/2016 21:44, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Alex,
>>>>
>>>> On 11 November 2016 at 23:23, Alexander Graf <agraf@suse.de> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Am 11.11.2016 um 17:17 schrieb Simon Glass <sjg@chromium.org>:
>>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>>> On 7 November 2016 at 09:32, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 07/11/2016 10:46, Simon Glass wrote:
>>>>>>>>
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>>> On 19 October 2016 at 01:09, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 18/10/2016 22:37, Simon Glass wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Alex,
>>>>>>>>>>
>>>>>>>>>>> On 18 October 2016 at 01:14, Alexander Graf <agraf@suse.de>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 10/18/2016 04:29 AM, Simon Glass wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It is useful to have a basic sanity check for EFI loader
>>>>>>>>>>>> support.
>>>>>>>>>>>> Add
>>>>>>>>>>>> a
>>>>>>>>>>>> 'bootefi hello' command which loads HelloWord.efi and runs it
>>>>>>>>>>>> under
>>>>>>>>>>>> U-Boot.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> Changes in v3:
>>>>>>>>>>>> - Include a link to the program instead of adding it to the tree
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, uh, where is the link?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I put it in the README (see the arm patch).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm really not convinced this command buys us anything yet. I do
>>>>>>>>>>> agree
>>>>>>>>>>> that
>>>>>>>>>>> we want automated testing - but can't we get that using QEMU and
>>>>>>>>>>> a
>>>>>>>>>>> downloadable image file that we pass in as disk and have the
>>>>>>>>>>> distro
>>>>>>>>>>> boot do
>>>>>>>>>>> its magic?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That seems very heavyweight as a sanity check, although I agree it
>>>>>>>>>> is
>>>>>>>>>> useful.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It's not really much more heavy weight. The "image file" could
>>>>>>>>> simply
>>>>>>>>> contain your hello world binary. But with this we don't just verify
>>>>>>>>> whether "bootefi" works, but also whether the default boot path
>>>>>>>>> works
>>>>>>>>> ok.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think I understand what you mean by 'image file'. Is it
>>>>>>>> something other than the .efi file? Do you mean a disk image?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes. For reasonable test coverage, we should also verify that the
>>>>>>> distro
>>>>>>> defaults wrote a sane boot script that automatically searches for a
>>>>>>> default
>>>>>>> EFI binary in /efi/boot/bootx86.efi on the first partition of all
>>>>>>> devices
>>>>>>> and runs it.
>>>>>>>
>>>>>>> So if we just provide an SD card image or hard disk image to QEMU
>>>>>>> which
>>>>>>> contains a hello world .efi binary as that default boot file, we
>>>>>>> don't
>>>>>>> only
>>>>>>> test whether the "bootefi" command works, but also whether the distro
>>>>>>> boot
>>>>>>> script works.
>>>>>>
>>>>>>
>>>>>>
>>>>>> That's right.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Here I am just making sure that EFI programs can start, print
>>>>>>>>>> output
>>>>>>>>>> and exit. It is a test that we can easily run without a lot of
>>>>>>>>>> overhead, much less than a full distro boot.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Again, I don't think it's much more overhead and I do believe it
>>>>>>>>> gives
>>>>>>>>> us much cleaner separation between responsibilities of code (tests
>>>>>>>>> go
>>>>>>>>> where tests are).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> You are talking about a functional test, something that tests things
>>>>>>>> end to end. I prefer to at least start with a smaller test. Granted
>>>>>>>> it
>>>>>>>> takes a little more work but it means there are fewer things to hunt
>>>>>>>> through when something goes wrong.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, I personally find unit tests terribly annoying and unproductive
>>>>>>> and
>>>>>>> functional tests very helpful :). And in this case, the effort to
>>>>>>> write
>>>>>>> it
>>>>>>> is about the same for both, just that the functional test actually
>>>>>>> tells you
>>>>>>> that things work or don't work at the end of the day.
>>>>>>>
>>>>>>> With a code base like U-Boot, a simple functional test like the above
>>>>>>> plus
>>>>>>> git bisect should get you to an offending patch very quickly.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is not a unit test - in fact the EFI stuff has no unit tests. I
>>>>>> suppose if we are trying to find a name this is a small functional
>>>>>> test since it exercises the general functionality.
>>>>>>
>>>>>> I am much keener on small tests than large ones for finding simple
>>>>>> bugs. Of course you can generally bisect to find a bug, but the more
>>>>>> layers of software you need to look for the harder this is.
>>>>>>
>>>>>> We could definitely use a pytest which checks an EFI boot into an
>>>>>> image, but I don't think this obviates the need for a smaller targeted
>>>>>> test like this one.
>>>>>
>>>>>
>>>>>
>>>>> I think arguing over this is moot :). More tests is usually a good
>>>>> thing,
>>>>> so whoever gets to write them gets to push them ;). As long as the
>>>>> licenses
>>>>> are sound at least.
>>>>
>>>>
>>>>
>>>> OK good, well please can you review this at some point?
>>>
>>>
>>>
>>> Review what exactly?
>>
>>
>> I mean the patches. There should be ~14 in your queue.
>
>
> Interesting. I see them on patchwork, but neither in my U-Boot folder, my
> inbox nor my spam folder. I wonder what happened there.
I'm really not sure but I have seen similar things. I will see if I
can figure it out.
Regards,
Simon
^ permalink raw reply
* Re: [MISSED PATCH] xattr: Fix setting security xattrs on sockfs
From: Casey Schaufler @ 2016-11-14 21:29 UTC (permalink / raw)
To: Andreas Gruenbacher, Alexander Viro, Linus Torvalds,
Andrew Morton
Cc: linux-fsdevel, Miklos Szeredi
In-Reply-To: <1479068614-5952-1-git-send-email-agruenba@redhat.com>
On 11/13/2016 12:23 PM, Andreas Gruenbacher wrote:
> Al,
>
> here is a fix for a regression introduced in commit 6c6ef9f2 (which is
> contained in v4.9-rc1). The fix was originally posted on November 3 [*], with
> no reaction:
>
> https://patchwork.kernel.org/patch/9410885/
> https://patchwork.kernel.org/patch/9411123/
>
> So may I again ask you to have a look, preferably before we slip yet another -rc?
This is a critical regression fix for Smack. Without
the fix it is impossible to properly configure certain
system services.
>
> Thanks,
> Andreas
>
> --
>
> The IOP_XATTR flag is set on sockfs because sockfs supports getting the
> "system.sockprotoname" xattr. Since commit 6c6ef9f2, this flag is checked for
> setxattr support as well. This is wrong on sockfs because security xattr
> support there is supposed to be provided by security_inode_setsecurity. The
> smack security module relies on socket labels (xattrs).
>
> Fix this by adding a security xattr handler on sockfs that returns
> -EAGAIN, and by checking for -EAGAIN in setxattr.
>
> We cannot simply check for -EOPNOTSUPP in setxattr because there are
> filesystems that neither have direct security xattr support nor support
> via security_inode_setsecurity. A more proper fix might be to move the
> call to security_inode_setsecurity into sockfs, but it's not clear to me
> if that is safe: we would end up calling security_inode_post_setxattr after
> that as well.
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
> fs/xattr.c | 22 ++++++++++++++--------
> net/socket.c | 15 +++++++++++++++
> 2 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 3368659..2d13b4e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -170,7 +170,7 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags)
> {
> struct inode *inode = dentry->d_inode;
> - int error = -EOPNOTSUPP;
> + int error = -EAGAIN;
> int issec = !strncmp(name, XATTR_SECURITY_PREFIX,
> XATTR_SECURITY_PREFIX_LEN);
>
> @@ -183,15 +183,21 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
> security_inode_post_setxattr(dentry, name, value,
> size, flags);
> }
> - } else if (issec) {
> - const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> -
> + } else {
> if (unlikely(is_bad_inode(inode)))
> return -EIO;
> - error = security_inode_setsecurity(inode, suffix, value,
> - size, flags);
> - if (!error)
> - fsnotify_xattr(dentry);
> + }
> + if (error == -EAGAIN) {
> + error = -EOPNOTSUPP;
> +
> + if (issec) {
> + const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> +
> + error = security_inode_setsecurity(inode, suffix, value,
> + size, flags);
> + if (!error)
> + fsnotify_xattr(dentry);
> + }
> }
>
> return error;
> diff --git a/net/socket.c b/net/socket.c
> index 5a9bf5e..9820725 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -341,8 +341,23 @@ static const struct xattr_handler sockfs_xattr_handler = {
> .get = sockfs_xattr_get,
> };
>
> +static int sockfs_security_xattr_set(const struct xattr_handler *handler,
> + struct dentry *dentry, struct inode *inode,
> + const char *suffix, const void *value,
> + size_t size, int flags)
> +{
> + /* Handled by LSM. */
> + return -EAGAIN;
> +}
> +
> +static const struct xattr_handler sockfs_security_xattr_handler = {
> + .prefix = XATTR_SECURITY_PREFIX,
> + .set = sockfs_security_xattr_set,
> +};
> +
> static const struct xattr_handler *sockfs_xattr_handlers[] = {
> &sockfs_xattr_handler,
> + &sockfs_security_xattr_handler,
> NULL
> };
>
^ permalink raw reply
* [PATCH libibmad] configure.ac: Update AM_INIT_AUTOMAKE to use subdir-objects
From: Hal Rosenstock @ 2016-11-14 21:34 UTC (permalink / raw)
To: Weiny, Ira; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
With this option, the objects are placed into the subdirectory of
the build directory corresponding to the subdirectory of the source file.
Fixes the following warning:
Makefile.am:16: warning: source file 'src/dump.c' is in a subdirectory,
Makefile.am:16: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Signed-off-by: Hal Rosenstock <hal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
diff --git a/configure.ac b/configure.ac
index 843dbfd..6453e11 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6,7 +6,7 @@ AC_CONFIG_SRCDIR([src/sa.c])
AC_CONFIG_AUX_DIR(config)
AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([subdir-objects])
AC_SUBST(RELEASE, ${RELEASE:-unknown})
AC_SUBST(TARBALL, ${TARBALL:-${PACKAGE}-${VERSION}.tar.gz})
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net] ipv4: fix cloning issues in fib_trie_unmerge()
From: Eric Dumazet @ 2016-11-14 21:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck
From: Eric Dumazet <edumazet@google.com>
I had crashes in a DEBUG_PAGEALLOC kernels in fib_table_flush() or
fib_table_lookup() that I back tracked to a refcounting issue
happening when we clone struct fib_alias in fib_trie_unmerge()
While fixing this issue, I also noticed a mem leak happening
if fib_insert_alias() fails.
Fixes: 0ddcf43d5d4a0 ("ipv4: FIB Local/MAIN table collapse")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/ipv4/fib_trie.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 4cff74d4133f..ebf49ab889e8 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1737,14 +1737,19 @@ struct fib_table *fib_trie_unmerge(struct fib_table *oldtb)
goto out;
memcpy(new_fa, fa, sizeof(*fa));
+ if (fa->fa_info)
+ fa->fa_info->fib_treeref++;
/* insert clone into table */
if (!local_l)
local_l = fib_find_node(lt, &local_tp, l->key);
if (fib_insert_alias(lt, local_tp, local_l, new_fa,
- NULL, l->key))
+ NULL, l->key)) {
+ kmem_cache_free(fn_alias_kmem, new_fa);
+ fib_release_info(fa->fa_info);
goto out;
+ }
}
/* stop loop if key wrapped back to 0 */
^ permalink raw reply related
* [Buildroot] [PATCHv2] dtv-scan-tables: rename file to have only ASCII characters
From: Thomas Petazzoni @ 2016-11-14 21:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479158436-4361-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hello,
On Mon, 14 Nov 2016 22:20:36 +0100, Thomas Petazzoni wrote:
> Since the bump of dtv-scan-tables to version
> ceb11833b35f05813b1f0397a60e0f3b99430aab in commit
> b1c8794d8ac0eb3895d13ae91d8e912ec469a105, one file contains non-ASCII
> characters, which causes encoding issues tvheadend. Since no other
> file in the dtv-scan-tables code base contains files with non-ASCII
> characters (despite having files named after cities in various
> countries that definitely do have non-ASCII characters), we rename
> this file so that it is named with only ASCII characters.
>
> This fixes the build of tvheadend, which was failing when the host
> Python interpreter was python3, due to a file name encoding issue.
>
> Fixes:
>
> http://autobuild.buildroot.net/results/1ae8bee297edb089535a2fb6ec724ebf7976888d/
> (tvheadend)
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> Changes since v1:
> - use a post-patch hook instead of doing the rename at the end of the
> installation step
> ---
> package/dtv-scan-tables/dtv-scan-tables.mk | 9 +++++++++
> 1 file changed, 9 insertions(+)
Applied to master, thanks. Thanks Yann for reviewing the patch!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit] dtv-scan-tables: rename file to have only ASCII characters
From: Thomas Petazzoni @ 2016-11-14 21:34 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=7f4dfd11888d1a092f3b92e8550b3958d87412f3
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Since the bump of dtv-scan-tables to version
ceb11833b35f05813b1f0397a60e0f3b99430aab in commit
b1c8794d8ac0eb3895d13ae91d8e912ec469a105, one file contains non-ASCII
characters, which causes encoding issues tvheadend. Since no other
file in the dtv-scan-tables code base contains files with non-ASCII
characters (despite having files named after cities in various
countries that definitely do have non-ASCII characters), we rename
this file so that it is named with only ASCII characters.
This fixes the build of tvheadend, which was failing when the host
Python interpreter was python3, due to a file name encoding issue.
Fixes:
http://autobuild.buildroot.net/results/1ae8bee297edb089535a2fb6ec724ebf7976888d/
(tvheadend)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/dtv-scan-tables/dtv-scan-tables.mk | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/package/dtv-scan-tables/dtv-scan-tables.mk b/package/dtv-scan-tables/dtv-scan-tables.mk
index 8ef42b9..8a782cb 100644
--- a/package/dtv-scan-tables/dtv-scan-tables.mk
+++ b/package/dtv-scan-tables/dtv-scan-tables.mk
@@ -17,6 +17,15 @@ DTV_SCAN_TABLES_SITE_METHOD = git
DTV_SCAN_TABLES_LICENSE = GPLv2, LGPLv2.1
DTV_SCAN_TABLES_LICENSE_FILES = COPYING COPYING.LGPL
+# In order to avoid issues with file name encodings, we rename the
+# only dtv-scan-tables file that has non-ASCII characters to have a
+# name using only ASCII characters (pl-Krosno_Sucha_Gora)
+define DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
+ mv $(@D)/dvb-t/pl-Krosno_Sucha* $(@D)/dvb-t/pl-Krosno_Sucha_Gora
+endef
+
+DTV_SCAN_TABLES_POST_PATCH_HOOKS += DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
+
define DTV_SCAN_TABLES_INSTALL_TARGET_CMDS
for f in atsc dvb-c dvb-s dvb-t; do \
$(INSTALL) -d -m 0755 $(TARGET_DIR)/usr/share/dvb/$$f; \
^ permalink raw reply related
* Re: [PATCH igt v4 06/13] igt/gem_exec_parse: init global parser_version in fixture
From: Matthew Auld @ 2016-11-14 21:33 UTC (permalink / raw)
To: Robert Bragg; +Cc: Intel Graphics Development
In-Reply-To: <20161114205122.10742-7-robert@sixbynine.org>
On 14 November 2016 at 20:51, Robert Bragg <robert@sixbynine.org> wrote:
> This adds a static global int parser_version that can be referenced by
> all subtests without needing multiple GETPARAM requests.
>
> Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.