linux-next: no linux-next today
Hi all, Unfortunately, I ran out of time before our machine room was shut down this evening. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp4Qo5d_z5Ot.pgp Description: OpenPGP digital signature
Re: [PATCH v4] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification
Hello,
I like it now. There are only a few small nitpicks, not sure its worth
to respin if noone else has concerns. See below.
On Thu, Dec 11, 2014 at 02:00:49PM +0800, Addy Ke wrote:
> The number of clock cycles to be written into the CLKDIV register
> that determines the I2C clk high phase includes the rise time.
> So to meet the timing requirements defined in the I2C specification
> which defines the minimal time SCL has to be high, the rise time
> has to taken into account. The same applies to the low phase with
> falling time.
>
> In my test on RK3288-Pink2 board, which is not an upstream board yet,
> if external pull-up resistor is 4.7K, rise_ns is about 700ns.
> So the measured high_ns is about 3900ns, which is less than 4000ns
> (the minimum high_ns in I2C specification for Standard-mode).
>
> To fix this bug, min_low_ns should include fall time and min_high_ns
s/,//
> should include rise time too.
I'd skip the "too". If you want to keep it, s/time/time,/.
> This patch merged the patch that Doug submitted to chromium project,
AFAIK s/,//
For correctness, does this patch needs Doug's Sob?
> which can get the rise and fall times for signals from the device tree.
> This allows us to more accurately calculate timings. see:
> https://chromium-review.googlesource.com/#/c/232774/
>
> Signed-off-by: Addy Ke
> ---
> [...]
> @@ -469,29 +476,33 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
> unsigned long scl_rate,
> [...]
> if (scl_rate <= 10) {
> - min_low_ns = 4700;
> - min_high_ns = 4000;
> - max_data_hold_ns = 3450;
> - data_hold_buffer_ns = 50;
> + /* Standard-mode */
> + spec_min_low_ns = 4700;
> + spec_min_high_ns = 4000;
> + spec_max_data_hold_ns = 3450;
> + spec_data_hold_buffer_ns = 50;
> } else {
> - min_low_ns = 1300;
> - min_high_ns = 600;
> - max_data_hold_ns = 900;
> - data_hold_buffer_ns = 50;
> + /* Fast-mode */
> + spec_min_low_ns = 1300;
> + spec_min_high_ns = 600;
> + spec_max_data_hold_ns = 900;
> + spec_data_hold_buffer_ns = 50;
The background of my question regarding data_hold_buffer_ns in the last
round was: If data_hold_buffer_ns doesn't appear in the I2C
specification, should it be renamed to spec_... ? *shrug*
> }
> - max_low_ns = max_data_hold_ns * 2 - data_hold_buffer_ns;
> + min_low_ns = spec_min_low_ns + fall_ns;
> + min_high_ns = spec_min_high_ns + rise_ns;
> + max_low_ns = spec_max_data_hold_ns * 2 - spec_data_hold_buffer_ns;
> min_total_ns = min_low_ns + min_high_ns;
>
> /* Adjust to avoid overflow */
> @@ -510,8 +521,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
> unsigned long scl_rate,
> min_div_for_hold = (min_low_div + min_high_div);
>
> /*
> - * This is the maximum divider so we don't go over the max.
> - * We don't round up here (we round down) since this is a max.
> + * This is the maximum divider so we don't go over the maximum.
> + * We don't round up here (we round down) since this is a maximum.
>*/
> max_low_div = clk_rate_khz * max_low_ns / (8 * 100);
>
> @@ -544,7 +555,7 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
> unsigned long scl_rate,
> ideal_low_div = DIV_ROUND_UP(clk_rate_khz * min_low_ns,
>scl_rate_khz * 8 * min_total_ns);
>
> - /* Don't allow it to go over the max */
> + /* Don't allow it to go over the maximum */
> if (ideal_low_div > max_low_div)
> ideal_low_div = max_low_div;
>
> @@ -588,8 +599,8 @@ static void rk3x_i2c_adapt_div(struct rk3x_i2c *i2c,
> unsigned long clk_rate)
> u64 t_low_ns, t_high_ns;
> int ret;
>
> - ret = rk3x_i2c_calc_divs(clk_rate, i2c->scl_frequency, _low,
> - _high);
> + ret = rk3x_i2c_calc_divs(clk_rate, i2c->scl_frequency, i2c->rise_ns,
> + i2c->fall_ns, _low, _high);
>
> WARN_ONCE(ret != 0, "Could not reach SCL freq %u", i2c->scl_frequency);
>
> @@ -633,9 +644,9 @@ static int rk3x_i2c_clk_notifier_cb(struct notifier_block
> *nb, unsigned long
> switch (event) {
> case PRE_RATE_CHANGE:
> if (rk3x_i2c_calc_divs(ndata->new_rate, i2c->scl_frequency,
> - _low, _high) != 0) {
> +i2c->rise_ns, i2c->fall_ns, _low,
> +_high) != 0)
> return NOTIFY_STOP;
> - }
>
> /* scale up */
> if (ndata->new_rate > ndata->old_rate)
> @@ -859,6 +870,21 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
> i2c->scl_frequency = DEFAULT_SCL_RATE;
> }
>
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
Hi Kishon:
On 2014/12/11 14:02, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 10 December 2014 04:16 PM, Yunzhi Li wrote:
This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
currently this driver can support RK3288. The RK3288 SoC have
three independent USB PHY IPs which are all configured through a
set of registers located in the GRF (general register files)
module.
Signed-off-by: Yunzhi Li
+
+#define ROCKCHIP_RK3288_UOC(n) (0x320 + n * 0x14)
+
+/*
+ * The higher 16-bit of this register is used for write protection
+ * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
+ */
+#define SIDDQ_MSK BIT(13 + 16)
I think here the "MSK" is misleading. it should be something that refers write
protection?
So, #define SIDDQ_WRITE_ENA BIT(29) , could be ok ?
+#define SIDDQ_ON BIT(13)
+#define SIDDQ_OFF (0 << 13)
+
+struct rockchip_usb_phy {
+ struct regmap *reg_base;
+ unsigned intreg_offset;
+ struct clk *clk;
+ struct phy *phy;
+ unsignedindex;
+};
+
+struct rockchip_usb_phy_priv {
+ struct rockchip_usb_phy *phys;
+ unsignednphys;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+ bool siddq)
+{
+ return regmap_write(phy->reg_base, phy->reg_offset,
+ SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
Shouldn't we actually reset the bit for power off?
Sorry, which bit you refer to here and why should it be reset? could
you give more infomation.
---
Yunzhi Li @ rockchip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] sound/soc/adi/axi-spdif.c: Support programmable master clock
If the master clock supports programmable rates, program it to generate
the desired frequency. Only apply constraints when the clock is fixed.
This allows proper clock generation for both 44100 and 48000 Hz based
sampling rates if the platform supports it.
The clock frequency must be set before enabling it. Enabling the clock
was done in "startup", but that occurs before "hw_params" where the rate
is known. Enabling a programmable clock without first setting a valid
frequency may harm the system. Move the clock start to the hw_params
routine, and keep track of whether the clock has been started, because
shutdown may be called without having called hw_params first, and
hw_params may be called multiple times.
Starting the clock and enabling the SPDIF output AFTER programming the
dividers is a more logical order anyway.
To detect if the source clock is fixed, the driver calls clk_round_rate
for two frequencies. If the results are equal, or if the call returns
an error, the driver assumes the clock is fixed.
Signed-off-by: Mike Looijmans
---
v3: Only enable clock once in hw_params which may be called multiple times.
sound/soc/adi/axi-spdif.c | 62 +
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/sound/soc/adi/axi-spdif.c b/sound/soc/adi/axi-spdif.c
index 198e3a4..d8a98a9 100644
--- a/sound/soc/adi/axi-spdif.c
+++ b/sound/soc/adi/axi-spdif.c
@@ -4,7 +4,6 @@
*
* Licensed under the GPL-2.
*/
-
#include
#include
#include
@@ -44,6 +43,8 @@ struct axi_spdif {
struct snd_ratnum ratnum;
struct snd_pcm_hw_constraint_ratnums rate_constraints;
+
+ bool clk_ref_running;
};
static int axi_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
@@ -79,6 +80,7 @@ static int axi_spdif_hw_params(struct snd_pcm_substream
*substream,
struct axi_spdif *spdif = snd_soc_dai_get_drvdata(dai);
unsigned int rate = params_rate(params);
unsigned int clkdiv, stat;
+ int ret;
switch (params_rate(params)) {
case 32000:
@@ -95,6 +97,9 @@ static int axi_spdif_hw_params(struct snd_pcm_substream
*substream,
break;
}
+ /* Try to set the master clock */
+ clk_set_rate(spdif->clk_ref, rate * 128);
+
clkdiv = DIV_ROUND_CLOSEST(clk_get_rate(spdif->clk_ref),
rate * 64 * 2) - 1;
clkdiv <<= AXI_SPDIF_CTRL_CLKDIV_OFFSET;
@@ -103,6 +108,16 @@ static int axi_spdif_hw_params(struct snd_pcm_substream
*substream,
regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL,
AXI_SPDIF_CTRL_CLKDIV_MASK, clkdiv);
+ if (!spdif->clk_ref_running) {
+ ret = clk_prepare_enable(spdif->clk_ref);
+ if (ret)
+ return ret;
+ spdif->clk_ref_running = true;
+ }
+
+ regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL,
+ AXI_SPDIF_CTRL_TXEN, AXI_SPDIF_CTRL_TXEN);
+
return 0;
}
@@ -121,18 +136,13 @@ static int axi_spdif_startup(struct snd_pcm_substream
*substream,
struct axi_spdif *spdif = snd_soc_dai_get_drvdata(dai);
int ret;
- ret = snd_pcm_hw_constraint_ratnums(substream->runtime, 0,
- SNDRV_PCM_HW_PARAM_RATE,
- >rate_constraints);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(spdif->clk_ref);
- if (ret)
- return ret;
-
- regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL,
- AXI_SPDIF_CTRL_TXEN, AXI_SPDIF_CTRL_TXEN);
+ if (spdif->rate_constraints.nrats) {
+ ret = snd_pcm_hw_constraint_ratnums(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ >rate_constraints);
+ if (ret)
+ return ret;
+ }
return 0;
}
@@ -145,7 +155,10 @@ static void axi_spdif_shutdown(struct snd_pcm_substream
*substream,
regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL,
AXI_SPDIF_CTRL_TXEN, 0);
- clk_disable_unprepare(spdif->clk_ref);
+ if (spdif->clk_ref_running) {
+ clk_disable_unprepare(spdif->clk_ref);
+ spdif->clk_ref_running = false;
+ }
}
static const struct snd_soc_dai_ops axi_spdif_dai_ops = {
@@ -183,6 +196,7 @@ static int axi_spdif_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
int ret;
+ long rate;
spdif = devm_kzalloc(>dev, sizeof(*spdif), GFP_KERNEL);
if (!spdif)
@@ -216,14 +230,18 @@ static int axi_spdif_probe(struct platform_device *pdev)
spdif->dma_data.addr_width = 4;
spdif->dma_data.maxburst = 1;
- spdif->ratnum.num = clk_get_rate(spdif->clk_ref) / 128;
- spdif->ratnum.den_step = 1;
- spdif->ratnum.den_min = 1;
- spdif->ratnum.den_max = 64;
-
-
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, Dec 10, 2014 at 05:57:12PM -0800, Yinghai Lu wrote: > Tried with mutt or thunderbird etc, all kept on downloading Mutt with gmail via imap works just fine for me. set folder="imaps://imap.gmail.com:993" set imap_user="lu...@gmail.com" set imap_pass="SuperSecret" You don't have to set imap_pass if you prefer an interactive prompt. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: at91: board-dt-sama5: add phy_fixup to override NAND_Tree which improperly strapp-in during the reset period.
Appearance: On some SAMA5D4EK boards, after power up, the Eth1 doesn't work.
Reason: The PIOE2 pin is connected to the NAND_Tree# of KSZ8081,
But it outputs LOW during the reset period, which cause the NAND_Tree# enabled.
Add phy_fixup() to disable NAND_Tree by overriding the Operation
Mode Strap Override register(i.e. Register 16h) to clear the NAND_Tree bit.
Signed-off-by: Wenyou Yang
---
arch/arm/mach-at91/board-dt-sama5.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-at91/board-dt-sama5.c
b/arch/arm/mach-at91/board-dt-sama5.c
index 8fb9ef5..97f7367 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -26,8 +27,25 @@
#include "generic.h"
+static int ksz8081_phy_fixup(struct phy_device *phy)
+{
+ int value;
+
+ value = phy_read(phy, 0x16);
+ value &= ~0x20;
+ phy_write(phy, 0x16, value);
+
+ return 0;
+}
+
static void __init sama5_dt_device_init(void)
{
+ if (of_machine_is_compatible("atmel,sama5d4ek") &&
+ IS_ENABLED(CONFIG_PHYLIB)) {
+ phy_register_fixup_for_id("fc028000.etherne:00",
+ ksz8081_phy_fixup);
+ }
+
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] iommu/vt-d: Move iommu preparatory allocations to irq_remap_ops.prepare
On Fri, Dec 5, 2014 at 3:26 PM, tip-bot for Thomas Gleixner wrote: > Commit-ID: e9220e591375af6d02604c261999df570fba744f > Gitweb: http://git.kernel.org/tip/e9220e591375af6d02604c261999df570fba744f > Author: Thomas Gleixner > AuthorDate: Fri, 5 Dec 2014 08:48:32 + > Committer: Thomas Gleixner > CommitDate: Sat, 6 Dec 2014 00:19:25 +0100 > > iommu/vt-d: Move iommu preparatory allocations to irq_remap_ops.prepare > > The whole iommu setup for irq remapping is a convoluted mess. The > iommu detect function gets called from mem_init() and the prepare > callback gets called from enable_IR_x2apic() for unknown reasons. Got [ 134.510969] calling ahci_pci_driver_init+0x0/0x1b @ 1 [ 134.511387] ahci :00:1f.2: version 3.0 [ 134.530941] alloc irq_desc for 91 on node 0 [ 134.531168] alloc irq_desc for 92 on node 0 [ 134.550728] alloc irq_desc for 93 on node 0 [ 134.550995] alloc irq_desc for 94 on node 0 [ 134.551199] alloc irq_desc for 95 on node 0 [ 134.570871] alloc irq_desc for 96 on node 0 [ 134.571090] alloc irq_desc for 97 on node 0 [ 134.571303] alloc irq_desc for 98 on node 0 [ 134.590974] alloc irq_desc for 99 on node 0 [ 134.591205] alloc irq_desc for 100 on node 0 [ 134.610882] alloc irq_desc for 101 on node 0 [ 134.611136] alloc irq_desc for 102 on node 0 [ 134.611364] alloc irq_desc for 103 on node 0 [ 134.630992] alloc irq_desc for 104 on node 0 [ 134.631232] alloc irq_desc for 105 on node 0 [ 134.650885] alloc irq_desc for 106 on node 0 [ 134.651246] ahci :00:1f.2: SSS flag set, parallel bus scan disabled [ 134.670926] ahci :00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode [ 134.671349] ahci :00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part ccc ems sxs [ 134.691158] ahci :00:1f.2: with iommu 3 : domain 10 [ 134.751560] BUG: unable to handle kernel NULL pointer dereference at 0118 [ 134.751997] IP: [] modify_irte+0x40/0xd0 [ 134.770893] PGD 0 [ 134.771011] Oops: [#1] SMP [ 134.771195] Modules linked in: [ 134.771344] CPU: 0 PID: 2169 Comm: kworker/0:1 Tainted: GW [ 134.811557] Workqueue: events work_for_cpu_fn [ 134.830823] task: 881024725240 ti: 8810252f8000 task.ti: 8810252f8000 [ 134.831176] RIP: 0010:[] [] modify_irte+0x40/0xd0 [ 134.851029] RSP: :8810252fba18 EFLAGS: 00010096 [ 134.851276] RAX: RBX: RCX: 00be00bd [ 134.871322] RDX: RSI: 81eafe3f RDI: 0046 [ 134.891061] RBP: 8810252fba48 R08: 0001 R09: 0001 [ 134.891393] R10: 881024725240 R11: 0292 R12: [ 134.911249] R13: 0096 R14: 881022b181d0 R15: 880079268260 [ 134.930824] FS: () GS:88103de0() knlGS: [ 134.931202] CS: 0010 DS: ES: CR0: 8005003b [ 134.950966] CR2: 0118 CR3: 02c1a000 CR4: 07f0 [ 134.970775] Stack: [ 134.970883] 8810252fba88 0046 881022f6c660 881026d0 [ 134.971253] 005c 880079268200 8810252fba58 81eaff26 [ 134.991066] 8810252fba78 81106761 880079268200 88103d889400 [ 135.010908] Call Trace: [ 135.011038] [] intel_irq_remapping_activate+0x16/0x20 [ 135.030800] [] irq_domain_activate_irq+0x41/0x50 [ 135.031103] [] irq_domain_activate_irq+0x2b/0x50 [ 135.050857] [] irq_startup+0x29/0x70 [ 135.051091] [] __setup_irq+0x327/0x590 [ 135.070849] [] ? ahci_bad_pmp_check_ready+0x70/0x70 [ 135.071143] [] request_threaded_irq+0xf2/0x150 [ 135.090972] [] ? ahci_bad_pmp_check_ready+0x70/0x70 [ 135.091295] [] ? ahci_host_activate+0x180/0x180 [ 135.111014] [] devm_request_threaded_irq+0x5f/0xb0 [ 135.130804] [] ahci_host_activate+0xa3/0x180 [ 135.131097] [] ahci_init_one+0x9d1/0xac0 [ 135.150841] [] local_pci_probe+0x45/0xa0 [ 135.151127] [] work_for_cpu_fn+0x18/0x30 [ 135.170843] [] process_one_work+0x254/0x470 [ 135.171103] [] ? process_one_work+0x1b9/0x470 [ 135.190846] [] worker_thread+0x31b/0x4e0 [ 135.191115] [] ? trace_hardirqs_on+0xd/0x10 [ 135.210920] [] ? pool_mayday_timeout+0x170/0x170 [ 135.211215] [] kthread+0x101/0x110 [ 135.230902] [] ? trace_hardirqs_on+0xd/0x10 [ 135.231157] [] ? kthread_stop+0x100/0x100 [ 135.250930] [] ret_from_fork+0x7c/0xb0 [ 135.251178] [] ? kthread_stop+0x100/0x100 [ 135.270969] Code: ec 10 48 85 ff 0f 84 90 00 00 00 48 c7 c7 80 34 e0 82 49 89 f6 e8 21 54 16 00 0f b7 53 08 49 89 c5 0f b7 43 0a 4c 8b 23 8d 1c 02 <49> 8b 84 24 18 01 00 00 48 63 fb 48 c1 e7 04 48 03 38 49 8b 06 [ 135.291699] RIP [] modify_irte+0x40/0xd0 [ 135.311051] RSP [ 135.311215] CR2: 0118 [ 135.330856] ---[ end trace fee039719f1667df ]--- [ 135.333024] BUG: unable to handle kernel paging request at ff98 [ 135.350911] IP: []
Re: [PATCH] dma: imx-sdma: fix indentation
On 12/11/2014 06:50 AM, Vinod Koul wrote: > On Wed, Dec 10, 2014 at 10:00:36AM +0200, Asaf Vertz wrote: >> Fixed a coding style error, switch and case should be at the same indent > Please use the right subsystem name for the patches what subsystem name I should have used? I used the one from the last patches in the log http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/dma/imx-sdma.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: Intel: fix possible acpi enumeration panic
A crash can occur on some platforms where adsp is enumerated but codec is not matched. Check that the codec_id string is valid before attempting to match. Signed-off-by: Kevin Strasser --- sound/soc/intel/sst/sst_acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/sst/sst_acpi.c b/sound/soc/intel/sst/sst_acpi.c index 31124aa..dd72e58 100644 --- a/sound/soc/intel/sst/sst_acpi.c +++ b/sound/soc/intel/sst/sst_acpi.c @@ -236,7 +236,7 @@ static struct sst_machines *sst_acpi_find_machine( struct sst_machines *mach; bool found = false; - for (mach = machines; mach->codec_id; mach++) + for (mach = machines; mach->codec_id[0]; mach++) if (ACPI_SUCCESS(acpi_get_devices(mach->codec_id, sst_acpi_mach_match, , NULL)) && found) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] i2c: cadence: Check for errata condition involving master receive
Hi Soren,
On Wed, Dec 10, 2014 at 11:15 PM, Sören Brinkmann
wrote:
> On Wed, 2014-12-10 at 05:14PM +0530, Harini Katakam wrote:
>> Cadence I2C controller has the following bugs:
>> - completion indication is not given to the driver at the end of
>> a read/receive transfer with HOLD bit set.
>> - Invalid read transaction are generated on the bus when HW timeout
>> condition occurs with HOLD bit set.
>>
>> As a result of the above, if a set of messages to be transferred with
>> repeated start includes any transfer following a read transfer,
>> completion is never indicated and timeout occurs.
>> Hence a check is implemented to return -EOPNOTSUPP for such sequences.
>>
>> Signed-off-by: Harini Katakam
>> Signed-off-by: Vishnu Motghare
>> ---
>>
>> v4:
>> Use single dev_warn and make message grep-able.
>>
>> v3:
>> Add warning in case of unsupported transfer.
>>
>> v2:
>> Dont defeteature repeated start. Just check for unsupported conditions in the
>> driver and return error.
>>
>> ---
>> drivers/i2c/busses/i2c-cadence.c | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-cadence.c
>> b/drivers/i2c/busses/i2c-cadence.c
>> index 5f5d4fa..f9269a6 100644
>> --- a/drivers/i2c/busses/i2c-cadence.c
>> +++ b/drivers/i2c/busses/i2c-cadence.c
>> @@ -541,6 +541,20 @@ static int cdns_i2c_master_xfer(struct i2c_adapter
>> *adap, struct i2c_msg *msgs,
>>* processed with a repeated start.
>>*/
>> if (num > 1) {
>> + /*
>> + * This controller does not give completion interrupt after a
>> + * master receive transfer if HOLD bit is set (repeated start),
>> + * resulting in SW timeout. Hence, if a receive transfer is
>> + * followed by any other transfer, an error is returned
>> + * indicating that this sequence is not supported.
>> + */
>> + for (count = 0; count < num-1; count++) {
>> + if (msgs[count].flags & I2C_M_RD)
>> + dev_warn(adap->dev.parent, "No support for "
>> + "repeated start when receive is "
>> + "followed by a transfer\n");
>
> Still not grepable. There must be no line breaks in the string!
This message will be printed in one single line.
Do you want this string to be grepable in the driver? Why is that necessary?
Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
On 12/11/2014 03:06 PM, Joe Perches wrote: On Thu, 2014-12-11 at 14:52 +0800, Yunzhi Li wrote: On 2014/12/11 14:37, Joe Perches wrote: On Thu, 2014-12-11 at 11:57 +0530, Kishon Vijay Abraham I wrote: [] So If I have to write something on bit 0, I have to set bit 16. If I have to write something on bit 1, I have to set bit 17. If I have to write something on bit 2, I have to set bit 18. and so on. To me it'd look better to use another << rather than a plus Like (BIT(13) << 16)? It looks strange, or could I just use ((1 << 13) << 16) to describe this bit ? Up to you. To me, the BIT(x+y) seems odd. I think BIT(29) is better, since you have described in comments. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
On Thu, 2014-12-11 at 14:52 +0800, Yunzhi Li wrote: > On 2014/12/11 14:37, Joe Perches wrote: > > On Thu, 2014-12-11 at 11:57 +0530, Kishon Vijay Abraham I wrote: [] > >> So If I have to write something on bit 0, I have to set bit 16. > >> If I have to write something on bit 1, I have to set bit 17. > >> If I have to write something on bit 2, I have to set bit 18. > >> and so on. > > To me it'd look better to use another << rather than a plus > Like (BIT(13) << 16)? It looks strange, or could I just use ((1 << 13) > << 16) to describe this bit ? Up to you. To me, the BIT(x+y) seems odd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] gpio_wdt: Add "always_running" feature to GPIO watchdog
Is this v3 patch okay or are you waiting for additional changes?
Kind regards,
Mike.
On 11/21/2014 10:40 AM, Mike Looijmans wrote:
On some chips, like the TPS386000, the trigger cannot be disabled
and the CPU must keep toggling the line at all times. Add a switch
"always_running" to keep toggling the GPIO line regardless of the
state of the soft part of the watchdog. The "armed" member keeps
track of whether a timeout must also cause a reset.
Signed-off-by: Mike Looijmans
---
v3: Indentation adjusted to match
Fix error path in probe when notification registration fails
Prevent double assignment of "armed" variable
.../devicetree/bindings/watchdog/gpio-wdt.txt |5 +++
drivers/watchdog/gpio_wdt.c| 39
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
index 37afec1..1987949 100644
--- a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
@@ -13,6 +13,11 @@ Required Properties:
by the GPIO flags.
- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds).
+Optional Properties:
+- always-running: If the watchdog timer cannot be disabled, add this flag to
+ have the driver keep toggling the signal without a client. It will only cease
+ to toggle the signal when the device is open and the timeout elapsed.
+
Example:
watchdog: watchdog {
/* ADM706 */
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index 220a9e0..9bfbd73 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -31,6 +31,8 @@ struct gpio_wdt_priv {
int gpio;
boolactive_low;
boolstate;
+ boolalways_running;
+ boolarmed;
unsigned inthw_algo;
unsigned inthw_margin;
unsigned long last_jiffies;
@@ -48,10 +50,8 @@ static void gpio_wdt_disable(struct gpio_wdt_priv *priv)
gpio_direction_input(priv->gpio);
}
-static int gpio_wdt_start(struct watchdog_device *wdd)
+static void gpio_wdt_start_impl(struct gpio_wdt_priv *priv)
{
- struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
-
priv->state = priv->active_low;
gpio_direction_output(priv->gpio, priv->state);
priv->last_jiffies = jiffies;
@@ -60,12 +60,25 @@ static int gpio_wdt_start(struct watchdog_device *wdd)
return 0;
}
+static int gpio_wdt_start(struct watchdog_device *wdd)
+{
+ struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ gpio_wdt_start_impl(priv);
+ priv->armed = true;
+
+ return 0;
+}
+
static int gpio_wdt_stop(struct watchdog_device *wdd)
{
struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
- mod_timer(>timer, 0);
- gpio_wdt_disable(priv);
+ priv->armed = false;
+ if (!priv->always_running) {
+ mod_timer(>timer, 0);
+ gpio_wdt_disable(priv);
+ }
return 0;
}
@@ -91,8 +104,8 @@ static void gpio_wdt_hwping(unsigned long data)
struct watchdog_device *wdd = (struct watchdog_device *)data;
struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
- if (time_after(jiffies, priv->last_jiffies +
- msecs_to_jiffies(wdd->timeout * 1000))) {
+ if (priv->armed && time_after(jiffies, priv->last_jiffies +
+ msecs_to_jiffies(wdd->timeout * 1000))) {
dev_crit(wdd->dev, "Timer expired. System will reboot soon!\n");
return;
}
@@ -197,6 +210,9 @@ static int gpio_wdt_probe(struct platform_device *pdev)
/* Use safe value (1/2 of real timeout) */
priv->hw_margin = msecs_to_jiffies(hw_margin / 2);
+ priv->always_running = of_property_read_bool(pdev->dev.of_node,
+"always-running");
+
watchdog_set_drvdata(>wdd, priv);
priv->wdd.info = _wdt_ident;
@@ -216,8 +232,15 @@ static int gpio_wdt_probe(struct platform_device *pdev)
priv->notifier.notifier_call = gpio_wdt_notify_sys;
ret = register_reboot_notifier(>notifier);
if (ret)
- watchdog_unregister_device(>wdd);
+ goto error_unregister;
+ if (priv->always_running)
+ gpio_wdt_start_impl(priv);
+
+ return 0;
+
+error_unregister:
+ watchdog_unregister_device(>wdd);
return ret;
}
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail:
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
On 2014/12/11 14:37, Joe Perches wrote: On Thu, 2014-12-11 at 11:57 +0530, Kishon Vijay Abraham I wrote: Hi, On Thursday 11 December 2014 11:42 AM, Joe Perches wrote: On Thu, 2014-12-11 at 11:32 +0530, Kishon Vijay Abraham I wrote: On Wednesday 10 December 2014 04:16 PM, Yunzhi Li wrote: diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c [] +/* + * The higher 16-bit of this register is used for write protection + * only if BIT(13 + 16) set to 1 the BIT(13) can be written. + */ +#define SIDDQ_MSK BIT(13 + 16) huh? This #define looks _very_ odd. Is this supposed to be a single bit 29 or some range? From what I understood, the most significant 16 bits are write locks to the least significant 16 bits. So If I have to write something on bit 0, I have to set bit 16. If I have to write something on bit 1, I have to set bit 17. If I have to write something on bit 2, I have to set bit 18. and so on. To me it'd look better to use another << rather than a plus Like (BIT(13) << 16)? It looks strange, or could I just use ((1 << 13) << 16) to describe this bit ? --- Yunzhi Li @ rockchip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Perf Bench: Locking Microbenchmark
* Tuan Bui wrote: > Subject: [PATCH] Perf Bench: Locking Microbenchmark Acked-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sound/soc/adi/axi-spdif.c: Support programmable master clock
On 12/10/2014 10:34 AM, Lars-Peter Clausen wrote: On 12/05/2014 01:37 PM, Mike Looijmans wrote: If the master clock supports programmable rates, program it to generate the desired frequency. Only apply constraints when the clock is fixed. This allows proper clock generation for both 44100 and 48000 Hz based sampling rates if the platform supports it. The clock frequency must be set before enabling it. Enabling the clock was done in "startup", but that occurs before "hw_params" where the rate is known. Enabling a programmable clock without first setting a valid frequency may harm the system. Move the clock start to the hw_params routine, and keep track of whether the clock has been started, because shutdown may be called without having called hw_params first. Starting the clock and enabling the SPDIF output AFTER programming the dividers is a more logical order anyway. To detect if the source clock is fixed, the driver calls clk_round_rate for two frequencies. If the results are equal, or if the call returns an error, the driver assumes the clock is fixed. Signed-off-by: Mike Looijmans Hi, Sorry for the delay. [...] +/* Try to set the master clock */ +clk_set_rate(spdif->clk_ref, rate * 128); + clkdiv = DIV_ROUND_CLOSEST(clk_get_rate(spdif->clk_ref), rate * 64 * 2) - 1; clkdiv <<= AXI_SPDIF_CTRL_CLKDIV_OFFSET; @@ -103,6 +108,14 @@ static int axi_spdif_hw_params(struct snd_pcm_substream *substream, regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL, AXI_SPDIF_CTRL_CLKDIV_MASK, clkdiv); +ret = clk_prepare_enable(spdif->clk_ref); I'm still not convinced this is the right place. I do see your point. But it just feels wrong to enable the clock in hw_params. It's a bit of a dilemma. the startup callback is to early, hw_params is the wrong place and we can't put it in the trigger callback as the trigger callback can not sleep. The clock interface suggests that we should do the clk_prepare in hw_params and the clk_enable in trigger then, since clk_prepare may sleep but clk_enable cannot. Which would complicate the clock state housekeeping because I'd have to keep track of prepare and enable states separately. (Imagine the housekeeping on a board that could have two codecs running on one DAI using the clock generated by a third codec... I never even bothered to submit that...) But in any way hwparmas can be called multiple times, so you need to handle the case where the clock is already enabled. A simple "if (spdif->clk_ref_running)" check would fix that. I wasn't aware of that though, I thought there'd be a shutdown before another hw_params. +if (ret) +return ret; +spdif->clk_ref_running = true; + +regmap_update_bits(spdif->regmap, AXI_SPDIF_REG_CTRL, +AXI_SPDIF_CTRL_TXEN, AXI_SPDIF_CTRL_TXEN); This should probably be moved to the trigger callback though. I'll create a v3. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tracing/sched: Check preempt_count() for current when reading task->state
* Steven Rostedt wrote: > > When recording the state of a task for the sched_switch tracepoint a check of > task_preempt_count() is performed to see if PREEMPT_ACTIVE is set. This is > because, technically, a task being preempted is really in the TASK_RUNNING > state, and that is what should be recorded when tracing a sched_switch, > even if the task put itself into another state (it hasn't scheduled out > in that state yet). > > But with the change to use per_cpu preempt counts, the > task_thread_info(p)->preempt_count is no longer used, and instead > task_preempt_count(p) is used. > > The problem is that this does not use the current preempt count but a > stale one from a previous sched_switch. The task_preempt_count(p) uses > saved_preempt_count and not preempt_count(). But for tracing > sched_switch, if p is current, we really want preempt_count(). > > I hit this bug when I was tracing sleep and the call from do_nanosleep() > scheduled out in the "RUNNING" state. > >sleep-4290 [000] 537272.259992: sched_switch: sleep:4290 > [120] R ==> swapper/0:0 [120] >sleep-4290 [000] 537272.260015: kernel_stack: trace> > => __schedule (8150864a) > => schedule (815089f8) > => do_nanosleep (8150b76c) > => hrtimer_nanosleep (8108d66b) > => SyS_nanosleep (8108d750) > => return_to_handler (8150e8e5) > => tracesys_phase2 (8150c844) > > After a bit of hair pulling, I found that the state was really > TASK_INTERRUPTIBLE, but the saved_preempt_count had an old PREEMPT_ACTIVE > set and caused the sched_switch tracepoint to show it as RUNNING. > > Cc: sta...@vger.kernel.org # 3.13+ > Fixes: 01028747559a "sched: Create more preempt_count accessors" > Signed-off-by: Steven Rostedt > --- > include/trace/events/sched.h | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h > index 0a68d5ae584e..13fbadcc172b 100644 > --- a/include/trace/events/sched.h > +++ b/include/trace/events/sched.h > @@ -97,10 +97,14 @@ static inline long __trace_sched_switch_state(struct > task_struct *p) > long state = p->state; > > #ifdef CONFIG_PREEMPT > + unsigned long pc; > + > + pc = (p == current) ? preempt_count() : task_preempt_count(p); > + > /* >* For all intents and purposes a preempted task is a running task. >*/ > - if (task_preempt_count(p) & PREEMPT_ACTIVE) > + if (pc & PREEMPT_ACTIVE) > state = TASK_RUNNING | TASK_STATE_MAX; I really don't like the overhead around here. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
On Thu, 2014-12-11 at 11:57 +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 11 December 2014 11:42 AM, Joe Perches wrote: > > On Thu, 2014-12-11 at 11:32 +0530, Kishon Vijay Abraham I wrote: > >> On Wednesday 10 December 2014 04:16 PM, Yunzhi Li wrote: > >>> diff --git a/drivers/phy/phy-rockchip-usb.c > >>> b/drivers/phy/phy-rockchip-usb.c > > [] > >>> +/* > >>> + * The higher 16-bit of this register is used for write protection > >>> + * only if BIT(13 + 16) set to 1 the BIT(13) can be written. > >>> + */ > >>> +#define SIDDQ_MSKBIT(13 + 16) > > > > huh? > > > > This #define looks _very_ odd. > > > > Is this supposed to be a single bit 29 or > > some range? > > From what I understood, the most significant 16 bits are write locks to the > least significant 16 bits. > > So If I have to write something on bit 0, I have to set bit 16. > If I have to write something on bit 1, I have to set bit 17. > If I have to write something on bit 2, I have to set bit 18. > and so on. To me it'd look better to use another << rather than a plus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] X86: Add a thread cpu time implementation to vDSO
* Andy Lutomirski wrote: > On Wed, Dec 10, 2014 at 2:56 PM, Shaohua Li wrote: > > On Wed, Dec 10, 2014 at 02:13:23PM -0800, Andy Lutomirski wrote: > >> On Wed, Dec 10, 2014 at 1:57 PM, Shaohua Li wrote: > >> > On Wed, Dec 10, 2014 at 11:10:52AM -0800, Andy Lutomirski wrote: > >> >> On Sun, Dec 7, 2014 at 7:03 PM, Shaohua Li wrote: > >> >> > This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTIME_ID, ..). > >> >> > We > >> >> > use the following method to compute the thread cpu time: > >> >> > >> >> I like the idea, and I like making this type of profiling fast. I > >> >> don't love the implementation because it's an information leak (maybe > >> >> we don't care) and it's ugly. > >> >> > >> >> The info leak could be fixed completely by having a per-process array > >> >> instead of a global array. That's currently tricky without wasting > >> >> memory, but it could be created on demand if we wanted to do that, > >> >> once my vvar .fault patches go in (assuming they do -- I need to ping > >> >> the linux-mm people). > >> > > >> > those info leak really doesn't matter. > >> > >> Why not? > > > > Ofcourse I can't make sure completely, but how could this > > info be used as attack? > > It may leak interesting timing info, even from cpus that are > outside your affinity mask / cpuset. I don't know how much > anyone actually cares. Finegraned timing information has been successfully used to recover secret keys (and sometimes even coarse timing information), so it can be a security issue in certain setups. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
Hi, On Thursday 11 December 2014 11:42 AM, Joe Perches wrote: > On Thu, 2014-12-11 at 11:32 +0530, Kishon Vijay Abraham I wrote: >> On Wednesday 10 December 2014 04:16 PM, Yunzhi Li wrote: >>> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c > [] >>> +/* >>> + * The higher 16-bit of this register is used for write protection >>> + * only if BIT(13 + 16) set to 1 the BIT(13) can be written. >>> + */ >>> +#define SIDDQ_MSK BIT(13 + 16) > > huh? > > This #define looks _very_ odd. > > Is this supposed to be a single bit 29 or > some range? >From what I understood, the most significant 16 bits are write locks to the least significant 16 bits. So If I have to write something on bit 0, I have to set bit 16. If I have to write something on bit 1, I have to set bit 17. If I have to write something on bit 2, I have to set bit 18. and so on. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: designware: use {readl|writel}_relaxed instead of readl/writel
readl/writel is too expensive especially on Cortex A9 w/ outer L2 cache.
This introduces i2c read/write errors on Marvell BG2/BG2Q SoCs when there
are heavy L2 cache maintenance operations at the same time.
The driver does not perform DMA, so it's safe to use the relaxed version.
>From another side, the relaxed io accessor macros are available on all
architectures now, so we can use the relaxed versions instead.
Signed-off-by: Jisheng Zhang
---
drivers/i2c/busses/i2c-designware-core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 23628b7..e279948 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -170,10 +170,10 @@ u32 dw_readl(struct dw_i2c_dev *dev, int offset)
u32 value;
if (dev->accessor_flags & ACCESS_16BIT)
- value = readw(dev->base + offset) |
- (readw(dev->base + offset + 2) << 16);
+ value = readw_relaxed(dev->base + offset) |
+ (readw_relaxed(dev->base + offset + 2) << 16);
else
- value = readl(dev->base + offset);
+ value = readl_relaxed(dev->base + offset);
if (dev->accessor_flags & ACCESS_SWAP)
return swab32(value);
@@ -187,10 +187,10 @@ void dw_writel(struct dw_i2c_dev *dev, u32 b, int offset)
b = swab32(b);
if (dev->accessor_flags & ACCESS_16BIT) {
- writew((u16)b, dev->base + offset);
- writew((u16)(b >> 16), dev->base + offset + 2);
+ writew_relaxed((u16)b, dev->base + offset);
+ writew_relaxed((u16)(b >> 16), dev->base + offset + 2);
} else {
- writel(b, dev->base + offset);
+ writel_relaxed(b, dev->base + offset);
}
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] phy: phy-samsung-usb2: Don't use same name for driver name and global structure
On Wed, Nov 12, 2014 at 3:54 PM, Vivek Gautam wrote:
> Using the same driver name for platform driver and a globally defined,
> structure used throughout the file, looks a bit unpleasing.
> So changing the driver name from "samsung_usb2_phy_driver" to
> "samsung_usb2_phy"
>
> Signed-off-by: Vivek Gautam
> Cc: Kamil Debski
> Cc: Kishon Vijay Abraham I
> ---
Although just a trivial change, does it look valid ?
> drivers/phy/phy-samsung-usb2.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
> index 908949d..2934fb7 100644
> --- a/drivers/phy/phy-samsung-usb2.c
> +++ b/drivers/phy/phy-samsung-usb2.c
> @@ -226,7 +226,7 @@ static int samsung_usb2_phy_probe(struct platform_device
> *pdev)
> return 0;
> }
>
> -static struct platform_driver samsung_usb2_phy_driver = {
> +static struct platform_driver samsung_usb2_phy = {
> .probe = samsung_usb2_phy_probe,
> .driver = {
> .of_match_table = samsung_usb2_phy_of_match,
> @@ -234,7 +234,7 @@ static struct platform_driver samsung_usb2_phy_driver = {
> }
> };
>
> -module_platform_driver(samsung_usb2_phy_driver);
> +module_platform_driver(samsung_usb2_phy);
> MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC USB PHY driver");
> MODULE_AUTHOR("Kamil Debski ");
> MODULE_LICENSE("GPL v2");
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL, v2] x86/microcode tree changes for v3.19
* Linus Torvalds wrote:
> On Wed, Dec 10, 2014 at 4:42 AM, Ingo Molnar wrote:
> >
> > Please pull the latest x86-microcode-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > x86-microcode-for-linus
>
> Hmm. There's a conflict with commit 02ecc41abcea ("x86,
> microcode: Limit the microcode reloading to 64-bit for now"),
Sorry, should have mentioned that explicitly, but forgot about
it.
> but I'm going to assume that the issue is fixed now, and that
> commit fbae4ba8c4a3 ("x86, microcode: Reload microcode on
> resume") that causes the conflict also handles the 32-bit case
> correctly. So my merge is going to just remove the X86_64 test,
> effectively undoing that first commit, ratehr than keep it
> around.
>
> If it turns out that the 64-bit limitation needs to be still in
> place, holler. We can re-do the ugly 64-bit limit thing if
> required.
Hm, so in my own conflict resolution I kept that check, last I
heard Boris was still seeing weirdnesses (read: crashes) on
32-bit and I'm not sure even the full series fixes it all.
In any case, would be nice to double check this and reinstate the
limitation explicitly if it's still needed, or apply a fix.
Boris?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT pull] x86 mpx support for 3.19
* Dave Hansen wrote: > @@ -1575,6 +1571,27 @@ config X86_SMAP > > If unsure, say Y. > > +config X86_INTEL_MPX > + prompt "Intel MPX (Memory Protection Extensions)" if EXPERT I think the 'if EXPERT' needs to be dropped. > + def_bool y > + depends on CPU_SUP_INTEL On the one hand, the 'def_bool y' might be acceptable, if we think of MPX as X32 or SECCOMP: ABI extensions that are only really useful if all distros enable it. On the other hand, unlike x32 and seccomp, MPX increases data structure size and adds a few instructions to common, non-MPX code paths, so the cost isn't just kernel image size. Linus, what's your preference? > + Enabling this option will make the kernel larger and > + slightly increase the size of some kernel data > + structures. And will add a few branches to critical code paths, right? It would be nice to give some numeric data in such cases, by what percentage does MPX support increase the x86_64 defconfig kernel for example? By how much does it increase data structure size? Make costs and benefits transparent and most people will chose wisely, or at least well informed. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
On Thu, 2014-12-11 at 11:32 +0530, Kishon Vijay Abraham I wrote: > On Wednesday 10 December 2014 04:16 PM, Yunzhi Li wrote: > > diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c [] > > +/* > > + * The higher 16-bit of this register is used for write protection > > + * only if BIT(13 + 16) set to 1 the BIT(13) can be written. > > + */ > > +#define SIDDQ_MSK BIT(13 + 16) huh? This #define looks _very_ odd. Is this supposed to be a single bit 29 or some range? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] Thermal: introduce INT3406 thermal driver
On 12/11/2014 02:08 PM, Aaron Lu wrote: > On 12/11/2014 10:37 AM, Zhang Rui wrote: >> On Wed, 2014-12-10 at 18:15 -0800, Olof Johansson wrote: >>> On Wed, Dec 10, 2014 at 5:02 PM, Aaron Lu wrote: On Wed, Dec 10, 2014 at 11:53:25AM -0800, Olof Johansson wrote: > Hi, > > [+daniel vetter] > > On Mon, Dec 8, 2014 at 9:47 PM, Aaron Lu wrote: >> INT3406 ACPI device object resembles an ACPI video output device, but its >> _BCM is said to be deprecated and should not be used. So we will make >> use of the raw interface to do the actual cooling. Due to this, the >> backlight core has some modifications. Also, to re-use some of the ACPI >> video module's code, one function has been exported. >> >> Signed-off-by: Aaron Lu >> Signed-off-by: Zhang Rui >> --- >> v5: >> Add the missing file drivers/thermal/int340x_thermal/Kconfig >> Remove the assignment of .owner field from the device_driver structure > > > Did this patch show up in -next for the first time last night, or did > some other change break this? > > It causes a panic in i915 when booting Minnowboard Max for me. Sorry for the trouble, I'm looking at this now. Is there anything special about the Minnowboard Max? I'll try to reproduce the issue here locally with a typical Intel desktop. >>> >>> Another good question is why the code showed up in -next today. Code >>> going in for 3.19 is supposed to have been baking there already, and >>> it's too early to stage anything for 3.20. >>> >>> Zhang? >> >> well, my Linux machine happened to be broken when I was in travel in Oct >> and Nov, so that I got the 3.19 material prepared a little late. >> Thus I just took some fixes and driver specific patches and plan to push >> my pull request next week. >> For this one, it had been pushed to linux-next for 3.18, but was dropped >> because of some Kconfig problem. So I thought it was safe to include >> this one for 3.19. >> sorry for bring the trouble here. > > It's my bad. In the meantime, I think I have found the problem: > If the system has a video output device that does not provide a correct > _BCL, the error path from the newly added code doesn't properly set the > error return value and that caused problem. The fix is simple: BTW, this is verified with a laptop that would expose the same call trace as posted by Olof with the original commit. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] Thermal: introduce INT3406 thermal driver
On 12/11/2014 10:37 AM, Zhang Rui wrote: > On Wed, 2014-12-10 at 18:15 -0800, Olof Johansson wrote: >> On Wed, Dec 10, 2014 at 5:02 PM, Aaron Lu wrote: >>> On Wed, Dec 10, 2014 at 11:53:25AM -0800, Olof Johansson wrote: Hi, [+daniel vetter] On Mon, Dec 8, 2014 at 9:47 PM, Aaron Lu wrote: > INT3406 ACPI device object resembles an ACPI video output device, but its > _BCM is said to be deprecated and should not be used. So we will make > use of the raw interface to do the actual cooling. Due to this, the > backlight core has some modifications. Also, to re-use some of the ACPI > video module's code, one function has been exported. > > Signed-off-by: Aaron Lu > Signed-off-by: Zhang Rui > --- > v5: > Add the missing file drivers/thermal/int340x_thermal/Kconfig > Remove the assignment of .owner field from the device_driver structure Did this patch show up in -next for the first time last night, or did some other change break this? It causes a panic in i915 when booting Minnowboard Max for me. >>> >>> Sorry for the trouble, I'm looking at this now. >>> Is there anything special about the Minnowboard Max? I'll try to >>> reproduce the issue here locally with a typical Intel desktop. >> >> Another good question is why the code showed up in -next today. Code >> going in for 3.19 is supposed to have been baking there already, and >> it's too early to stage anything for 3.20. >> >> Zhang? > > well, my Linux machine happened to be broken when I was in travel in Oct > and Nov, so that I got the 3.19 material prepared a little late. > Thus I just took some fixes and driver specific patches and plan to push > my pull request next week. > For this one, it had been pushed to linux-next for 3.18, but was dropped > because of some Kconfig problem. So I thought it was safe to include > this one for 3.19. > sorry for bring the trouble here. It's my bad. In the meantime, I think I have found the problem: If the system has a video output device that does not provide a correct _BCL, the error path from the newly added code doesn't properly set the error return value and that caused problem. The fix is simple: diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 5a41f89c4ce4..32880e6c8da4 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -721,7 +721,7 @@ int acpi_video_get_levels(struct acpi_device *device, int i, max_level = 0, count = 0, level_ac_battery = 0; union acpi_object *o; struct acpi_video_device_brightness *br = NULL; - int result = 0; + int result = -EINVAL; u32 value; if (!ACPI_SUCCESS(acpi_video_device_lcd_query_levels(device->handle, @@ -799,6 +799,7 @@ int acpi_video_get_levels(struct acpi_device *device, br->count = count; *dev_br = br; + result = 0; out: kfree(obj); Please let me know if you want to take this one incremental patch or an update to the original one. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
Hi,
On Wednesday 10 December 2014 04:16 PM, Yunzhi Li wrote:
> This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
> currently this driver can support RK3288. The RK3288 SoC have
> three independent USB PHY IPs which are all configured through a
> set of registers located in the GRF (general register files)
> module.
>
> Signed-off-by: Yunzhi Li
>
> ---
>
> Changes in v5: None
> Changes in v4:
> - Get number of PHYs from device tree.
> - Model each PHY as subnode of the phy provider node.
>
> Changes in v3:
> - Use BIT macro instead of bit shift ops.
> - Rename the config entry to PHY_ROCKCHIP_USB.
>
> drivers/phy/Kconfig| 7 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-rockchip-usb.c | 211
> +
> 3 files changed, 219 insertions(+)
> create mode 100644 drivers/phy/phy-rockchip-usb.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..8a39d2a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
> depends on OF
> select GENERIC_PHY
>
> +config PHY_ROCKCHIP_USB2
> + tristate "Rockchip USB2 PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> + Enable this to support the Rockchip USB 2.0 PHY.
> +
> config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..8a13f72 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) +=
> phy-exynos5250-usb2.o
> phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
> +obj-$(CONFIG_PHY_ROCKCHIP_USB2) += phy-rockchip-usb.o
> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> new file mode 100644
> index 000..0317c21
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -0,0 +1,211 @@
> +/*
> + * Rockchip usb PHY driver
> + *
> + * Copyright (C) 2014 Yunzhi Li
> + * Copyright (C) 2014 ROCKCHIP, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ROCKCHIP_RK3288_UOC(n) (0x320 + n * 0x14)
> +
> +/*
> + * The higher 16-bit of this register is used for write protection
> + * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
> + */
> +#define SIDDQ_MSKBIT(13 + 16)
I think here the "MSK" is misleading. it should be something that refers write
protection?
> +#define SIDDQ_ON BIT(13)
> +#define SIDDQ_OFF(0 << 13)
> +
> +struct rockchip_usb_phy {
> + struct regmap *reg_base;
> + unsigned intreg_offset;
> + struct clk *clk;
> + struct phy *phy;
> + unsignedindex;
> +};
> +
> +struct rockchip_usb_phy_priv {
> + struct rockchip_usb_phy *phys;
> + unsignednphys;
> +};
> +
> +static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> +bool siddq)
> +{
> + return regmap_write(phy->reg_base, phy->reg_offset,
> + SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
Shouldn't we actually reset the bit for power off?
> +}
> +
> +static int rockchip_usb_phy_power_off(struct phy *_phy)
> +{
> + struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> + int ret = 0;
> +
> + /* Power down usb phy analog blocks by set siddq 1 */
> + ret = rockchip_usb_phy_power(phy, 1);
> + if (ret)
> + return ret;
> +
> + clk_disable_unprepare(phy->clk);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int rockchip_usb_phy_power_on(struct phy *_phy)
> +{
> + struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> + int ret = 0;
> +
> + ret = clk_prepare_enable(phy->clk);
> + if (ret)
> + return ret;
> +
> + /* Power up usb phy analog blocks by set siddq 0 */
> + ret =
[PATCH v4] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification
The number of clock cycles to be written into the CLKDIV register
that determines the I2C clk high phase includes the rise time.
So to meet the timing requirements defined in the I2C specification
which defines the minimal time SCL has to be high, the rise time
has to taken into account. The same applies to the low phase with
falling time.
In my test on RK3288-Pink2 board, which is not an upstream board yet,
if external pull-up resistor is 4.7K, rise_ns is about 700ns.
So the measured high_ns is about 3900ns, which is less than 4000ns
(the minimum high_ns in I2C specification for Standard-mode).
To fix this bug, min_low_ns should include fall time and min_high_ns
should include rise time too.
This patch merged the patch that Doug submitted to chromium project,
which can get the rise and fall times for signals from the device tree.
This allows us to more accurately calculate timings. see:
https://chromium-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke
---
Changes in v2:
- merged the patch that Doug submitted to chromium project
Changes in v3:
- merged the patch that Doug submitted to chromium to projectchange bindins
see: https://chromium-review.googlesource.com/#/c/232774/
Changes in v4:
- Fix some typos pointed out by Uwe
- adjust "i2c" capitalization to "I2C"
Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 11
drivers/i2c/busses/i2c-rk3x.c | 76 +++---
2 files changed, 62 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
index dde6c22..1885bd8 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
@@ -21,6 +21,14 @@ Required on RK3066, RK3188 :
Optional properties :
- clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used.
+ - i2c-scl-rising-time-ns : Number of nanoseconds the signal takes to rise
+ (t(r) in I2C specification). If not specified this is assumed to be
+ the maximum the specification allows(1000 ns for Standard-mode,
+ 300 ns for Fast-mode) which might cause slightly slower communication.
+ - i2c-scl-falling-time-ns : Number of nanoseconds the signal takes to fall
+ (t(f) in the I2C specification). If not specified this is assumed to
+ be the maximum the specification allows (300 ns) which might cause
+ slightly slowercommunication.
Example:
@@ -39,4 +47,7 @@ i2c0: i2c@2002d000 {
clock-names = "i2c";
clocks = < PCLK_I2C0>;
+
+ i2c-scl-rising-time-ns = <800>;
+ i2c-scl-falling-time-ns = <100>;
};
diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 0ee5802..f8eb77e 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -102,6 +102,8 @@ struct rk3x_i2c {
/* Settings */
unsigned int scl_frequency;
+ unsigned int rise_ns;
+ unsigned int fall_ns;
/* Synchronization & notification */
spinlock_t lock;
@@ -435,6 +437,8 @@ out:
*
* @clk_rate: I2C input clock rate
* @scl_rate: Desired SCL rate
+ * @rise_ns: How many ns it takes for signals to rise.
+ * @fall_ns: How many ns it takes for signals to fall.
* @div_low: Divider output for low
* @div_high: Divider output for high
*
@@ -443,11 +447,14 @@ out:
* too high, we silently use the highest possible rate.
*/
static int rk3x_i2c_calc_divs(unsigned long clk_rate, unsigned long scl_rate,
+ unsigned long rise_ns, unsigned long fall_ns,
unsigned long *div_low, unsigned long *div_high)
{
+ unsigned long spec_min_low_ns, spec_min_high_ns;
+ unsigned long spec_max_data_hold_ns;
+ unsigned long spec_data_hold_buffer_ns;
+
unsigned long min_low_ns, min_high_ns;
- unsigned long max_data_hold_ns;
- unsigned long data_hold_buffer_ns;
unsigned long max_low_ns, min_total_ns;
unsigned long clk_rate_khz, scl_rate_khz;
@@ -469,29 +476,33 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate,
unsigned long scl_rate,
scl_rate = 1000;
/*
-* min_low_ns: The minimum number of ns we need to hold low
-* to meet i2c spec
-* min_high_ns: The minimum number of ns we need to hold high
-* to meet i2c spec
-* max_low_ns: The maximum number of ns we can hold low
-* to meet i2c spec
+* min_low_ns: The minimum number of ns we need to hold low to
+* meet I2C specification, should include fall time.
+* min_high_ns: The minimum number of ns we need to hold high to
+* meet I2C specification, should include rise time.
+* max_low_ns: The maximum number of ns we can hold low to meet
+* I2C specification.
*
-*
Re: [GIT PULL] ipmi driver updates
On Wed, 2014-12-10 at 08:21 -0600, Corey Minyard wrote: > On 12/10/2014 04:53 AM, Michael Ellerman wrote: > > Hi Corey, > > > > On Tue, 2014-12-09 at 11:59 -0600, Corey Minyard wrote: > >> Jeremy Kerr (2): > >> powerpc/powernv: Add OPAL IPMI interface > >> drivers/char/ipmi: Add powernv IPMI driver > > I created a topic branch for that powerpc patch, but it looks like you > > didn't > > merge it? > > No, I missed that. I've never had to do any serious merging with other > changes, so I've never had to do this before. I can fix it if Linus > wants to wait. Thanks for the heads up. OK, no stress. I think I sent you instructions on how to do it, but feel free to ask if you're not sure in future. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [v2 17/25] KVM: kvm-vfio: User API for VT-d Posted-Interrupts
> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Monday, December 08, 2014 1:21 PM > To: Wu, Feng > Cc: Eric Auger; t...@linutronix.de; mi...@redhat.com; h...@zytor.com; > x...@kernel.org; g...@kernel.org; pbonz...@redhat.com; > dw...@infradead.org; j...@8bytes.org; jiang@linux.intel.com; > linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org; > k...@vger.kernel.org > Subject: Re: [v2 17/25] KVM: kvm-vfio: User API for VT-d Posted-Interrupts > > On Mon, 2014-12-08 at 04:58 +, Wu, Feng wrote: > > > > > -Original Message- > > > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] > On > > > Behalf Of Eric Auger > > > Sent: Thursday, December 04, 2014 10:05 PM > > > To: Wu, Feng; t...@linutronix.de; mi...@redhat.com; h...@zytor.com; > > > x...@kernel.org; g...@kernel.org; pbonz...@redhat.com; > > > dw...@infradead.org; j...@8bytes.org; alex.william...@redhat.com; > > > jiang@linux.intel.com > > > Cc: linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org; > > > k...@vger.kernel.org > > > Subject: Re: [v2 17/25] KVM: kvm-vfio: User API for VT-d Posted-Interrupts > > > > > > Hi Feng, > > > On 12/03/2014 08:39 AM, Feng Wu wrote: > > > > This patch adds and documents a new attribute > > > > KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE > group. > > > > This new attribute is used for VT-d Posted-Interrupts. > > > > > > > > When guest OS changes the interrupt configuration for an > > > > assigned device, such as, MSI/MSIx data/address fields, > > > > QEMU will use this IRQ attribute to tell KVM to update the > > > > related IRTE according the VT-d Posted-Interrrupts Specification, > > > > such as, the guest vector should be updated in the related IRTE. > > > > > > > > Signed-off-by: Feng Wu > > > > --- > > > > Documentation/virtual/kvm/devices/vfio.txt |9 + > > > > include/uapi/linux/kvm.h | 10 ++ > > > > 2 files changed, 19 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/Documentation/virtual/kvm/devices/vfio.txt > > > b/Documentation/virtual/kvm/devices/vfio.txt > > > > index f7aff29..41e12b7 100644 > > > > --- a/Documentation/virtual/kvm/devices/vfio.txt > > > > +++ b/Documentation/virtual/kvm/devices/vfio.txt > > > > @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has > been > > > called to trigger the IRQ > > > > or associate an eventfd to it. Unforwarding can only be called while > > > > the > > > > signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this > condition > > > is > > > > not satisfied, the command returns an -EBUSY. > > > > + > > > > + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups > > > mechanism to post > > > typo > > > > + the IRQ to guests. > > > > +For this attribute, kvm_device_attr.addr points to a kvm_vfio_dev_irq > > > struct. > > > > + > > > > +When guest OS changes the interrupt configuration for an assigned > device, > > > > +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute > > > > +to tell KVM to update the related IRTE according the VT-d > > > Posted-Interrrupts > > > > +Specification, such as, the guest vector should be updated in the > > > > related > > > IRTE. > > > For my curiosity are there any restrictions about the instant at which > > > the change can be done? > > > I do not get here how you deactivate the posting? > > > > The current method is if the hardware supports interrupts posting, we will > > use it instead of interrupts remapping, since it has good performance. Why > > do I need deactivate interrupts posting? > > > > Here is the reply to Alex for the same question: > > "In fact, I don't think we need to stop the posted-interrupts. For setting > > posted interrupts, we update the related IRTE according to the new > > format. If the guest reboots, or unload the drivers, or some other > > operations, the msi/msix will be disabled first, in this path, the irq > > will be disabled the related IRTE is not used anymore." > > Right, and I'm still not sure I agree with that reasoning. We need to > build the kernel interface to be generic, not tailored for a specific > userspace. I don't really feel comfortable having something that can't > be disabled via a similar path to it being enabled. For instance, what > about a dynamic debug interface where we want to enable tracing and see > each interrupt injected into the guest. At that point we'd want to > disabled posted interrupts and direct KVM injection and route via QEMU. > Thanks, > > Alex I am not quite understand why we need to debug the software delivery path for interrupt when PI is used, in this case, the software injection code will have no chance to execute. If we don't want the use PI, we can disable it from kernel command line. Thanks, Feng > > > > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > > > > index a269a42..7d98650 100644 > >
Re: [PATCH RFC 04/15] drm/dsi: Do not add DSI devices for the child nodes with input-port property
Hi Thierry, On 12/11/2014 10:52 AM, Liu Ying wrote: Hi Thierry, On 12/10/2014 08:21 PM, Thierry Reding wrote: On Wed, Dec 10, 2014 at 04:37:17PM +0800, Liu Ying wrote: The MIPI DSI bus driver would try to add a DSI device for a host's every child node which contains the reg property. Unfortunately, the existing i.MX6Q/SDL MIPI DSI host device tree node's child nodes contain the reg There aren't any existing nodes for the DSI host on i.MX. This patch series adds support for them. There are existing nodes for the DSI host node. Please find them in arch/arm/boot/dts/imx6qdl.dtsi and arch/arm/boot/dts/imx6q.dts. The DSI host node contains two child nodes for i.MX6DL and another two for i.MX6Q. Each child node has a reg property embedded. property, but the child nodes are ports pointing to dedicated CRTCs. So, this patch phases out the child nodes with input-port property before adding DSI devices for them and updates the MIPI DSI bus OF binding documentation. Signed-off-by: Liu Ying --- Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 4 drivers/gpu/drm/drm_mipi_dsi.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) Sorry, but NAK. There's no need for this special-case. I'll go into more detail in response to patch 09/15. Thanks for reviewing the patches. Any idea how to handle the special case? The existing child nodes for the DSI host node do have the reg properties embedded. I see your suggestions on this topic in the comments for patch 09/15. I will try to move the existing child nodes into a parent port node. Liu Ying Thierry ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Driver: Vmxnet3: Make Rx ring 2 size configurable
Rx ring 2 size can be configured by adjusting rx-jumbo parameter
of ethtool -G.
Signed-off-by: Ramya Bolla
Signed-off-by: Shreyas Bhatewara
Signed-off-by: Shrikrishna Khare
---
drivers/net/vmxnet3/vmxnet3_defs.h| 1 +
drivers/net/vmxnet3/vmxnet3_drv.c | 6 +-
drivers/net/vmxnet3/vmxnet3_ethtool.c | 27 ---
drivers/net/vmxnet3/vmxnet3_int.h | 6 --
4 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_defs.h
b/drivers/net/vmxnet3/vmxnet3_defs.h
index 4d84912..25b6fa4 100644
--- a/drivers/net/vmxnet3/vmxnet3_defs.h
+++ b/drivers/net/vmxnet3/vmxnet3_defs.h
@@ -342,6 +342,7 @@ union Vmxnet3_GenericDesc {
#define VMXNET3_TX_RING_MAX_SIZE 4096
#define VMXNET3_TC_RING_MAX_SIZE 4096
#define VMXNET3_RX_RING_MAX_SIZE 4096
+#define VMXNET3_RX_RING2_MAX_SIZE 2048
#define VMXNET3_RC_RING_MAX_SIZE 8192
/* a list of reasons for queue stop */
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index afd2953..7af1f5c 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2505,6 +2505,9 @@ vmxnet3_adjust_rx_ring_size(struct vmxnet3_adapter
*adapter)
ring0_size = min_t(u32, ring0_size, VMXNET3_RX_RING_MAX_SIZE /
sz * sz);
ring1_size = adapter->rx_queue[0].rx_ring[1].size;
+ ring1_size = (ring1_size + sz - 1) / sz * sz;
+ ring1_size = min_t(u32, ring1_size, VMXNET3_RX_RING2_MAX_SIZE /
+ sz * sz);
comp_size = ring0_size + ring1_size;
for (i = 0; i < adapter->num_rx_queues; i++) {
@@ -2585,7 +2588,7 @@ vmxnet3_open(struct net_device *netdev)
err = vmxnet3_create_queues(adapter, adapter->tx_ring_size,
adapter->rx_ring_size,
- VMXNET3_DEF_RX_RING_SIZE);
+ adapter->rx_ring2_size);
if (err)
goto queue_err;
@@ -2964,6 +2967,7 @@ vmxnet3_probe_device(struct pci_dev *pdev,
adapter->tx_ring_size = VMXNET3_DEF_TX_RING_SIZE;
adapter->rx_ring_size = VMXNET3_DEF_RX_RING_SIZE;
+ adapter->rx_ring2_size = VMXNET3_DEF_RX_RING2_SIZE;
spin_lock_init(>cmd_lock);
adapter->adapter_pa = dma_map_single(>pdev->dev, adapter,
diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c
b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index b725fd9..70fb410 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -447,12 +447,12 @@ vmxnet3_get_ringparam(struct net_device *netdev,
param->rx_max_pending = VMXNET3_RX_RING_MAX_SIZE;
param->tx_max_pending = VMXNET3_TX_RING_MAX_SIZE;
param->rx_mini_max_pending = 0;
- param->rx_jumbo_max_pending = 0;
+ param->rx_jumbo_max_pending = VMXNET3_RX_RING2_MAX_SIZE;
param->rx_pending = adapter->rx_ring_size;
param->tx_pending = adapter->tx_ring_size;
param->rx_mini_pending = 0;
- param->rx_jumbo_pending = 0;
+ param->rx_jumbo_pending = adapter->rx_ring2_size;
}
@@ -461,7 +461,7 @@ vmxnet3_set_ringparam(struct net_device *netdev,
struct ethtool_ringparam *param)
{
struct vmxnet3_adapter *adapter = netdev_priv(netdev);
- u32 new_tx_ring_size, new_rx_ring_size;
+ u32 new_tx_ring_size, new_rx_ring_size, new_rx_ring2_size;
u32 sz;
int err = 0;
@@ -473,6 +473,10 @@ vmxnet3_set_ringparam(struct net_device *netdev,
VMXNET3_RX_RING_MAX_SIZE)
return -EINVAL;
+ if (param->rx_jumbo_pending == 0 ||
+ param->rx_jumbo_pending > VMXNET3_RX_RING2_MAX_SIZE)
+ return -EINVAL;
+
/* if adapter not yet initialized, do nothing */
if (adapter->rx_buf_per_pkt == 0) {
netdev_err(netdev, "adapter not completely initialized, "
@@ -500,8 +504,15 @@ vmxnet3_set_ringparam(struct net_device *netdev,
sz) != 0)
return -EINVAL;
- if (new_tx_ring_size == adapter->tx_queue[0].tx_ring.size &&
- new_rx_ring_size == adapter->rx_queue[0].rx_ring[0].size) {
+ /* ring2 has to be a multiple of VMXNET3_RING_SIZE_ALIGN */
+ new_rx_ring2_size = (param->rx_jumbo_pending + VMXNET3_RING_SIZE_MASK) &
+ ~VMXNET3_RING_SIZE_MASK;
+ new_rx_ring2_size = min_t(u32, new_rx_ring2_size,
+ VMXNET3_RX_RING2_MAX_SIZE);
+
+ if (new_tx_ring_size == adapter->tx_ring_size &&
+ new_rx_ring_size == adapter->rx_ring_size &&
+ new_rx_ring2_size == adapter->rx_ring2_size) {
return 0;
}
@@ -522,7 +533,7 @@ vmxnet3_set_ringparam(struct net_device *netdev,
vmxnet3_rq_destroy_all(adapter);
err =
Re: [Xen-devel] [PATCH] xen: switch to post-init routines in xen mmu.c earlier
On 12/10/2014 07:07 PM, David Vrabel wrote:
On 10/12/14 15:56, Juergen Gross wrote:
With the virtual mapped linear p2m list the post-init mmu operations
must be used for setting up the p2m mappings, as in case of
CONFIG_FLATMEM the init routines may trigger BUGs.
Reported-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
---
arch/x86/xen/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6ab6150..a1a429a 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
static void __init xen_pagetable_init(void)
{
paging_init();
+ xen_post_allocator_init();
xen_pagetable_p2m_setup();
This feels very chicken-and-egg to me: To setup the P2M we need to use
the MMU ops that use the P2M...
Please explain very clearly why this is all safe.
Okay. paging_init() sets up all infrastructure needed to switch to the
post-init mmu ops done by xen_post_allocator_init(). With the virtual
mapped linear p2m list we need some mmu ops during setup of this list,
so we have to switch to the correct mmu ops as soon as possible.
The p2m list is usable from the beginning, just expansion requires to
have established the new linear mapping. So the call of
xen_remap_memory() had to be introduced, but this is not due to the
mmu ops requiring this.
Summing it up: calling xen_post_allocator_init() not directly after
paging_init() was conceptually wrong in the beginning, it just didn't
matter up to now as no functions used between the two calls needed
some critical mmu ops (e.g. alloc_pte). This has changed now, so I
corrected it.
Juergen
@@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
xen_remap_memory();
xen_setup_shared_info();
- xen_post_allocator_init();
}
static void xen_write_cr2(unsigned long cr2)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] tracing/NMI/printk: Use seq_buf for safe printing from NMI context
On Wed, Dec 10, 2014 at 8:20 PM, Linus Torvalds wrote: > > Would it perhaps be possible/reasonable to also use this to get rid of > the horrible "early_printk()" stuff [...] Another question: the "preempt_disable/enable()" around the use of the per-cpu vprintk_func thing seems dubious. Why do I say that? I think it cannot possibly make sense. Anybody who sets that function pointer to any per-cpu value has to disable preemption for that to make sense, so doing it inside the printk() paths seems dubious at best. No? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/4] arch: Add lightweight memory barriers for coherent memory access
On 11/25/2014 12:35 PM, Alexander Duyck wrote: > These patches introduce two new primitives for synchronizing cache coherent > memory writes and reads. These two new primitives are: > > dma_rmb() > dma_wmb() > > The first patch cleans up some unnecessary overhead related to the > definition of read_barrier_depends, smp_read_barrier_depends, and comments > related to the barrier. > > The second patch adds the primitives for the applicable architectures and > asm-generic. > > The third patch adds the barriers to r8169 which turns out to be a good > example of where the new barriers might be useful as they have full > rmb()/wmb() barriers ordering accesses to the descriptors and the DescOwn > bit. > > The fourth patch adds support for coherent_rmb() to the Intel fm10k, igb, > and ixgbe drivers. Testing with the ixgbe driver has shown a processing > time reduction of at least 7ns per 64B frame on a Core i7-4930K. > > This patch series is essentially the v7 for: > v4-6: Add lightweight memory barriers for coherent memory access > v3: Add lightweight memory barriers fast_rmb() and fast_wmb() > v2: Introduce load_acquire() and store_release() > v1: Introduce read_acquire() > > The key changes in this patch series versus the earlier patches are: > v7: > - Dropped test/debug patch that was accidentally slipped in > v6: > - Replaced "memory based device I/O" with "consistent memory" in > docs > - Added reference to DMA-API.txt to explain consistent memory > v5: > - Renamed barriers dma_rmb and dma_wmb > - Undid smp_wmb changes in x86 and PowerPC > - Defined smp_rmb as __lwsync for SMP case on PowerPC > v4: > - Renamed barriers coherent_rmb and coherent_wmb > - Added smp_lwsync for use in smp_load_acquire/smp_store_release > v3: > - Moved away from acquire()/store() and instead focused on barriers > - Added cleanup of read_barrier_depends > - Added change in r8169 to fix cur_tx/DescOwn ordering > - Simplified changes to just replacing/moving barriers in r8169 > - Added update to documentation with code example > v2: > - Renamed read_acquire() to be consistent with smp_load_acquire() > - Changed barrier used to be consistent with smp_load_acquire() > - Updated PowerPC code to use __lwsync based on IBM article > - Added store_release() as this is a viable use case for drivers > - Added r8169 patch which is able to fully use primitives > - Added fm10k/igb/ixgbe patch which is able to test performance > > --- > > Alexander Duyck (4): > arch: Cleanup read_barrier_depends() and comments > arch: Add lightweight memory barriers dma_rmb() and dma_wmb() > r8169: Use dma_rmb() and dma_wmb() for DescOwn checks > fm10k/igb/ixgbe: Use dma_rmb on Rx descriptor reads > > > Documentation/memory-barriers.txt | 42 +++ > arch/alpha/include/asm/barrier.h | 51 ++ > arch/arm/include/asm/barrier.h|4 + > arch/arm64/include/asm/barrier.h |3 + > arch/blackfin/include/asm/barrier.h | 51 ++ > arch/ia64/include/asm/barrier.h | 25 - > arch/metag/include/asm/barrier.h | 19 --- > arch/mips/include/asm/barrier.h | 61 ++ > arch/powerpc/include/asm/barrier.h| 19 --- > arch/s390/include/asm/barrier.h |7 ++- > arch/sparc/include/asm/barrier_64.h |7 ++- > arch/x86/include/asm/barrier.h| 70 > - > arch/x86/um/asm/barrier.h | 20 --- > drivers/net/ethernet/intel/fm10k/fm10k_main.c |6 +- > drivers/net/ethernet/intel/igb/igb_main.c |6 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |9 +-- > drivers/net/ethernet/realtek/r8169.c | 29 -- > include/asm-generic/barrier.h |8 +++ > 18 files changed, 258 insertions(+), 179 deletions(-) > > -- It occurs to me that I never got a sign off from any of the maintainers on getting this pulled in. Since the merge window is open I was wondering which tree I should make sure these patches apply to and who will be the one to pull them in? Since I was modifying network drivers should I resubmit them for netdev, or should I submit them for asm-generic or some other tree? - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL, v2] x86/microcode tree changes for v3.19
On Wed, Dec 10, 2014 at 4:42 AM, Ingo Molnar wrote:
>
> Please pull the latest x86-microcode-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-microcode-for-linus
Hmm. There's a conflict with commit 02ecc41abcea ("x86, microcode:
Limit the microcode reloading to 64-bit for now"), but I'm going to
assume that the issue is fixed now, and that commit fbae4ba8c4a3
("x86, microcode: Reload microcode on resume") that causes the
conflict also handles the 32-bit case correctly. So my merge is going
to just remove the X86_64 test, effectively undoing that first commit,
ratehr than keep it around.
If it turns out that the 64-bit limitation needs to be still in place,
holler. We can re-do the ugly 64-bit limit thing if required.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge
On 11 December 2014 at 10:14, Preeti U Murthy wrote: > I was talking of the case where we get an interrupt from the clockevent > device but dont find the hrtimer to service and not really of an anomaly > in timekeeping. For sure that's a problem then and its obviously spurious unless we wanted it to behave that way. >For instance one of the issues that we had seen earlier wherein we > cancel the tick-sched-timer before going tickless, but since we had > programmed the clock event device to fire, we get a spurious interrupt. Yeah and so we need something like ONESHOT_STOPPED there.. I thought you are also talking about some *possible* races which might occur between cancelling a timer and hrtimer_interrupt() getting called. Don't know if such a race is possible though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen: switch to post-init routines in xen mmu.c earlier
On 12/10/2014 05:13 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Dec 10, 2014 at 04:56:03PM +0100, Juergen Gross wrote:
With the virtual mapped linear p2m list the post-init mmu operations
must be used for setting up the p2m mappings, as in case of
CONFIG_FLATMEM the init routines may trigger BUGs.
Um, could you explain a bit more of why the CONFIG_FLATMEM
is such unique? What about the other CONFIG_*MEM cases?
CONFIG_FLATMEM is just the configuration hitting a BUG() in
xen_alloc_pte_init() being used after finishing paging_init().
Juergen
Reported-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
---
arch/x86/xen/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6ab6150..a1a429a 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1225,6 +1225,7 @@ static void __init xen_pagetable_p2m_setup(void)
static void __init xen_pagetable_init(void)
{
paging_init();
+ xen_post_allocator_init();
xen_pagetable_p2m_setup();
@@ -1236,7 +1237,6 @@ static void __init xen_pagetable_init(void)
xen_remap_memory();
xen_setup_shared_info();
- xen_post_allocator_init();
}
static void xen_write_cr2(unsigned long cr2)
{
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull mpe/linux.git powerpc-3.19-1 tag
Hi Linus, Please pull the first batch of powerpc updates for 3.19: The following changes since commit 8a97577a5967c1234ccc3bc1b45e4b1a58b39ea8: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux (2014-11-04 11:18:29 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-3.19-1 for you to fetch changes up to 56548fc0e86cb9156af7a7e1f15ba78f251dafaf: powerpc/powernv: Return to cpu offline loop when finished in KVM guest (2014-12-08 13:16:31 +1100) Some nice cleanups like removing bootmem, and removal of __get_cpu_var(). There is one patch to mm/gup.c. This is the generic GUP implementation, but is only used by us and arm(64). We have an ack from Steve Capper, and although we didn't get an ack from Andrew he told us to take the patch through the powerpc tree. There's one cxl patch. This is in drivers/misc, but Greg said he was happy for us to manage fixes for it. There is an infrastructure patch to support an IPMI driver for OPAL. That patch also appears in Corey Minyard's IPMI tree, you may see a conflict there. There is also an RTC driver for OPAL. We weren't able to get any response from the RTC maintainer, Alessandro Zummo, so in the end we just merged the driver. The usual batch of Freescale updates from Scott. Alexander Graf (1): powerpc: Convert power off logic to pm_power_off Aneesh Kumar K.V (8): powerpc: Disable CPU_FTR_TM if TM is disabled by firmware powerpc/mm: Add missing pmd accessors mm: Update generic gup implementation to handle hugepage directory powerpc/mm: Switch to generic RCU get_user_pages_fast powerpc/mm: Check for matching hpte without taking hpte lock powerpc/mm/thp: Remove code duplication powerpc/mm/thp: Use tlbiel if possible powerpc/mm: don't do tlbie for updatepp request with NO HPTE fault Anshuman Khandual (1): powerpc/xmon: Enable HW instruction breakpoint on POWER8 Anton Blanchard (18): powerpc: Use probe_kernel_address in show_instructions powerpc/pci: Quieten unset I/O resource warning powerpc: Remove ppc64_boot_msg powerpc: Remove ppc_md.remove_memory powerpc: Remove bootmem allocator powerpc: Remove some old bootmem related comments powerpc: Remove superfluous bootmem includes powerpc: Move sparse_init() into initmem_init powerpc: make __ffs return unsigned long powerpc/ftrace: Remove mod_return_to_handler powerpc/ftrace: simplify prepare_ftrace_return powerpc/jump_label: Use HAVE_JUMP_LABEL powerpc: Don't use local named register variable in current_thread_info powerpc: Remove double braces in alignment code. powerpc: LLVM complains about forward declaration of struct rtas_sensors powerpc/pseries: Quieten ibm,pcie-link-speed-stats warning powerpc/pseries: Quieten relocation on exceptions warning powerpc: Fix bad NULL pointer check in udbg_uart_getc_poll() Ashish Kumar (1): powerpc/mpc85xx: Remove SPI and NAND partition from bsc9131rdb.dtsi Boqun Feng (1): powerpc: Fix comment typos in arch/powerpc/include/asm/bitops.h Christoph Lameter (1): powerpc: Replace __get_cpu_var uses Emil Medve (7): powerpc/dts: Factorize the clock control node dt/bindings: qoriq-clock: Add binding for the platform PLL powerpc/dts: Add node(s) for the platform PLL dt/bindings: Introduce the FSL QorIQ DPAA BMan dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s) dt/bindings: Introduce the FSL QorIQ DPAA QMan dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s) Gavin Shan (13): powerpc/mm: Use PAGE_FACTOR powerpc/powernv: Check PHB type in advance powerpc/powernv: Fix condition to remove M64 powerpc/powernv: Rename alloc_m64_pe() to reserve_m64_pe() powerpc/powernv: Initialize M64 PE in time powerpc/powernv: Set PELTV for compound PEs powerpc/powernv: Simplify pnv_ioda_configure_pe() powerpc/powernv: Bail upon invalid master PE powerpc/powernv: Fix potential zero devisor powerpc/eeh: Refactor eeh_reset_pe() powerpc/eeh: Set EEH_PE_RESET on PE reset powerpc/eeh: Recover EEH error on ownership change for BCM5719 powerpc/eeh: Dump PHB diag-data early Greg Kurz (1): powerpc: Drop useless warning in eeh_init() Hongtao Jia (2): powerpc: Add ADT7461 to device tree for supported boards powerpc: Add INA220 to device tree for supported boards Ian Munsie (1): cxl: Return error to PSL if IRQ demultiplexing fails & print clearer warning Igal Liberman (2): powerpc/fsl: Added rcw registers to global utility registers powerpc/fsl: Frame Manager Device Tree binding document James Yang (1):
Re: Re: [PATCH] ftracetest: Replace usleep with sleep 0.000001
Hi, (2014/12/10 17:19), Namhyung Kim wrote: > Hi Michael, > > On Wed, Dec 10, 2014 at 1:38 PM, Michael Ellerman wrote: >> usleep is a Fedoraism, it's not generally available on Debian based >> systems AFAICS. >> >> GNU sleep accepts a floating point argument, so use that instead. > > I tested it on busybox not Debian, sorry. But it seems busybox's > sleep doesn't support floating point argument.. > > / # ls -l `which sleep` > lrwxrwxrwx 1 root rooot 7 May 22 2014 /bin/sleep -> busybox > > / # sleep 0.1 > sleep: invalid number '0.1' I also have same result. Basically, ftracetest should be able to run on busybox. So, I think we'd better check whether usleep is available, and if not, fallback to sleep like as below. if which usleep &> /dev/null; then usleep 1 else sleep 0.01 fi Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface
On Wed, Dec 03, 2014 at 06:41:33PM +0100, Gabriele Mazzotta wrote: > Add the documentation for the new sysfs interface of dell-laptop > that allows to configure the keyboard illumination on Dell systems. Queued to for-next. Thanks, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[kprobes] WARNING: at kernel/trace/trace_kprobe.c:1393 kprobe_trace_self_tests_init()
/kernel/git/rwlove/fcoe
git bisect good e3ff91143eb2a6eaaab4831c85a2837a95fbbea3 # 08:11 20+
0 Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm
git bisect bad 8b4d801b2b123b6c09742f861fe44a8527b84d47 # 08:29 0-
1 hw_breakpoint: Fix cpu check in task_bp_pinned(cpu)
git bisect bad 003002e04ed38618fc37b92ba128f5ca79d39f4f # 08:38 0-
20 kprobes: Fix arch_prepare_kprobe to handle copy insn failures
# first bad commit: [003002e04ed38618fc37b92ba128f5ca79d39f4f] kprobes: Fix
arch_prepare_kprobe to handle copy insn failures
git bisect good f1a527899ef0a8a241eb3bea619eb2e29d797f44 # 09:07 60+
0 perf/x86: Fix broken PEBS-LL support on SNB-EP/IVB-EP
# extra tests on HEAD of linux-devel/devel-hourly-2014121022
git bisect bad 876ed1468bfdd84f401fb63a0e76a3619665fa28 # 09:07 0-
12 0day head guard for 'devel-hourly-2014121022'
# extra tests on tree/branch linus/master
git bisect bad 3a5dc1fafb016560315fe45bb4ef8bde259dd1bc # 09:07 0-
24 Merge branch 'x86-microcode-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
# extra tests on tree/branch linus/master
git bisect bad 3a5dc1fafb016560315fe45bb4ef8bde259dd1bc # 09:07 0-
24 Merge branch 'x86-microcode-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
# extra tests on tree/branch next/master
git bisect bad 12fd07251e19050ca979d9ce5d4b6bcb41dc00e9 # 09:07 0-
24 Add linux-next specific files for 20141210
This script may reproduce the error.
#!/bin/bash
kernel=$1
initrd=yocto-minimal-x86_64.cgz
wget --no-clobber
https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
kvm=(
qemu-system-x86_64
-cpu kvm64
-enable-kvm
-kernel $kernel
-initrd $initrd
-m 320
-smp 1
-net nic,vlan=1,model=e1000
-net user,vlan=1
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
Thanks,
Fengguang
early console in setup code
early console in decompress_kernel
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.10.0-rc3-5-g003002e (kbuild@lkp-ib04) (gcc
version 4.9.1 (Debian 4.9.1-19) ) #25 Thu Dec 11 08:33:00 CST 2014
[0.00] Command line: hung_task_panic=1 earlyprintk=ttyS0,115200 debug
apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal root=/dev/ram0
rw
link=/kbuild-tests/run-queue/kvm/x86_64-randconfig-ib0-12061218/linux-devel:devel-hourly-2014121022:003002e04ed38618fc37b92ba128f5ca79d39f4f:bisect-linux-1/.vmlinuz-003002e04ed38618fc37b92ba128f5ca79d39f4f-20141211083609-15-client9
branch=linux-devel/devel-hourly-2014121022
BOOT_IMAGE=/kernel/x86_64-randconfig-ib0-12061218/003002e04ed38618fc37b92ba128f5ca79d39f4f/vmlinuz-3.10.0-rc3-5-g003002e
drbd.minor_count=8
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x13fd] usable
[0.00] BIOS-e820: [mem 0x13fe-0x13ff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] bootconsole [earlyser0] enabled
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x13fe0 max_arch_pfn = 0x4
[0.00] Scan for SMP in [mem 0x-0x
Re: [RESEND PATCH v5 0/5] acerhdf: adding new models, appropriate governor and minor clean up
On Fri, Nov 28, 2014 at 03:20:47PM +0100, Peter Feuerer wrote: > Hi Darren, > > please apply this series of patches. > > It is intended to: > > * Introduce "manual mode" support (Patch 1 & 2), which is needed to control > the fan of a few new models. > > * Add an appropriate thermal governor (Patch 3). Manipulating and > fiddling around with the step-wise governor has been a very fragile thing > in the past and as it broke again, I used the opportunity to add a two > point thermal governor which implements the actual fan handling required > by > acerhdf and puts from my point of view things straight. > > * Do some minor clean up like: > - adding second trip point for critical temperature (Patch 4) > - removing _t suffix from struct which isn't typedef and replace > unsigned > char by u8 (Patch 5) > > Thanks and kind regards, > peter > > Peter Feuerer (5): > acerhdf: Adding support for "manual mode" > acerhdf: Adding support for new models > acerhdf: Use bang-bang thermal governor > acerhdf: added critical trip point > acerhdf: minor clean up Queued to for-next. Thanks! -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tracing/sched: Check preempt_count() for current when reading task->state
Peter, If you give me your ack, I can pull this through my tree. Otherwise, it can go through tip. I just kicked off my test suite to test it overnight. -- Steve On Wed, 10 Dec 2014 17:44:28 -0500 Steven Rostedt wrote: > > When recording the state of a task for the sched_switch tracepoint a check of > task_preempt_count() is performed to see if PREEMPT_ACTIVE is set. This is > because, technically, a task being preempted is really in the TASK_RUNNING > state, and that is what should be recorded when tracing a sched_switch, > even if the task put itself into another state (it hasn't scheduled out > in that state yet). > > But with the change to use per_cpu preempt counts, the > task_thread_info(p)->preempt_count is no longer used, and instead > task_preempt_count(p) is used. > > The problem is that this does not use the current preempt count but a > stale one from a previous sched_switch. The task_preempt_count(p) uses > saved_preempt_count and not preempt_count(). But for tracing > sched_switch, if p is current, we really want preempt_count(). > > I hit this bug when I was tracing sleep and the call from do_nanosleep() > scheduled out in the "RUNNING" state. > >sleep-4290 [000] 537272.259992: sched_switch: sleep:4290 > [120] R ==> swapper/0:0 [120] >sleep-4290 [000] 537272.260015: kernel_stack: trace> > => __schedule (8150864a) > => schedule (815089f8) > => do_nanosleep (8150b76c) > => hrtimer_nanosleep (8108d66b) > => SyS_nanosleep (8108d750) > => return_to_handler (8150e8e5) > => tracesys_phase2 (8150c844) > > After a bit of hair pulling, I found that the state was really > TASK_INTERRUPTIBLE, but the saved_preempt_count had an old PREEMPT_ACTIVE > set and caused the sched_switch tracepoint to show it as RUNNING. > > Cc: sta...@vger.kernel.org # 3.13+ > Fixes: 01028747559a "sched: Create more preempt_count accessors" > Signed-off-by: Steven Rostedt > --- > include/trace/events/sched.h | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h > index 0a68d5ae584e..13fbadcc172b 100644 > --- a/include/trace/events/sched.h > +++ b/include/trace/events/sched.h > @@ -97,10 +97,14 @@ static inline long __trace_sched_switch_state(struct > task_struct *p) > long state = p->state; > > #ifdef CONFIG_PREEMPT > + unsigned long pc; > + > + pc = (p == current) ? preempt_count() : task_preempt_count(p); > + > /* >* For all intents and purposes a preempted task is a running task. >*/ > - if (task_preempt_count(p) & PREEMPT_ACTIVE) > + if (pc & PREEMPT_ACTIVE) > state = TASK_RUNNING | TASK_STATE_MAX; > #endif > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge
On 11 December 2014 at 10:14, Preeti U Murthy wrote: > On 12/10/2014 06:22 PM, Viresh Kumar wrote: >> On 10 December 2014 at 18:03, Preeti U Murthy >> wrote: >> >>> Right. We get an interrupt when nobody had asked for it to be delivered >>> or had asked for it to be delivered and later canceled the request. It >>> is most often in the latter situation, that there can be race >>> conditions. If these race conditions are not taken care of, they can >>> result in spurious interrupts. >> >> But the delta time will be very small then, right ? > > I was talking of the case where we get an interrupt from the clockevent > device but dont find the hrtimer to service and not really of an anomaly > in timekeeping. >For instance one of the issues that we had seen earlier wherein we > cancel the tick-sched-timer before going tickless, but since we had > programmed the clock event device to fire, we get a spurious interrupt. > I verified this case before reporting; In my case tick_sched_timer do get cancelled before expire duration but then clk_evt_device get reprogrammed for next time node in list. __remove_hrtimer() takes care of that. And in case there is no timer in list; We shut down the clk_evt_device. Therefore no spurious interrupt in either of two possible cases. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: imx-sdma: fix indentation
On Wed, Dec 10, 2014 at 10:00:36AM +0200, Asaf Vertz wrote: > Fixed a coding style error, switch and case should be at the same indent Please use the right subsystem name for the patches Applied, now Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.16][v3.17][v3.18][ Regression] scsi: handle flush errors properly
On Wed, 2014-12-10 at 17:08 -0500, Joseph Salisbury wrote: > Hello James, > > A kernel bug report was opened against Ubuntu [0]. After a kernel > bisect, it was found that reverting the following commit resolved this bug: If I read this bug report correctly, it's saying a USB attached device produces an error when doing a "shred" but the same device PCI attached doesn't. Presumably shred sends some type of zero length command USB storage doesn't like. What is shred actually doing (what commands is it sending)? James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge
On 12/10/2014 06:22 PM, Viresh Kumar wrote: > On 10 December 2014 at 18:03, Preeti U Murthy > wrote: > >> Right. We get an interrupt when nobody had asked for it to be delivered >> or had asked for it to be delivered and later canceled the request. It >> is most often in the latter situation, that there can be race >> conditions. If these race conditions are not taken care of, they can >> result in spurious interrupts. > > But the delta time will be very small then, right ? I was talking of the case where we get an interrupt from the clockevent device but dont find the hrtimer to service and not really of an anomaly in timekeeping. For instance one of the issues that we had seen earlier wherein we cancel the tick-sched-timer before going tickless, but since we had programmed the clock event device to fire, we get a spurious interrupt. > >> Since the difference is 1us and not a noticeably high value, it is most >> probably because during hrtimer handling, we traverse all queued timers >> and call their handlers, till we find timers whose expiry is in the >> future. I would not be surprised if we overshoot the expiry of the >> timers at the end of the list by a microsecond by the time we call their >> handlers. > > Looks like you misunderstood what he wrote. He isn't saying that we > serviced the timers/hrtimers sometime after we should have. > > What he is saying is: we got the clockevent device's interrupt at the > time we requested but hrtimer_update_base() returned a time > lesser than what it *should* have. And that results in a spurious > interrupt.. We enqueue again for 1 us and service the timer then. Oh ok I see. I understand this better now after reading Thomas's explanation. Regards Preeti U Murthy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v18 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Hi Andy,
This driver adds HDMI to rockchip/drm. The fact that rockchip's hdmi
uses dw_hdmi is an implementation detail. I do not think that the names
used for rk3288-hdmi should include "dw" in them.
See inline for what I mean...
On Thu, Dec 4, 2014 at 10:34 PM, Andy Yan wrote:
> Rockchip RK3288 hdmi is compatible with dw_hdmi
>
> this patch is depend on patch by Mark Yao
> drm: rockchip: Add basic drm driver
> see https://lkml.org/lkml/2014/12/2/161
>
> Signed-off-by: Andy Yan
>
> ---
>
> Changes in v18: None
> Changes in v17:
> - parse resource and irq in platform driver
>
> Changes in v16: None
> Changes in v15:
> - remove THIS_MODULE in platform driver
>
> Changes in v14: None
> Changes in v13: None
> Changes in v12:
> - add comment for the depend on patch
>
> Changes in v11: None
> Changes in v10:
> - add more display mode support mpll configuration for rk3288
>
> Changes in v9:
> - move some phy configuration to platform driver
>
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
>
> drivers/gpu/drm/bridge/dw_hdmi.c| 3 +
> drivers/gpu/drm/rockchip/Kconfig| 10 +
> drivers/gpu/drm/rockchip/Makefile | 2 +
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 341
>
> include/drm/bridge/dw_hdmi.h| 1 +
> 5 files changed, 357 insertions(+)
> create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index cecc46a..01c95a8 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -852,6 +852,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> unsigned char prep,
> dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> dw_hdmi_phy_gen2_pddq(hdmi, 0);
>
> + if (hdmi->dev_type == RK3288_HDMI)
> + dw_hdmi_phy_enable_spare(hdmi, 1);
> +
> /*Wait for PHY PLL lock */
> msec = 5;
> do {
> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig
> index ca9f085..6ebebe8 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -15,3 +15,13 @@ config DRM_ROCKCHIP
> management to userspace. This driver does not provide
> 2D or 3D acceleration; acceleration is performed by other
> IP found on the SoC.
> +
> +config ROCKCHIP_DW_HDMI
I would rather call this ROCKCHIP_HDMI, since this driver implements
the HDMI for Rockchip. The fact that it uses dw_hdmi is an
implementation detail.
> +bool "Rockchip specific extensions for Synopsys DW HDMI"
> +depends on DRM_ROCKCHIP
> +select DRM_DW_HDMI
> +help
> + This selects support for Rockchip SoC specific extensions
> + for the Synopsys DesignWare HDMI driver. If you want to
> + enable HDMI on RK3288 based SoC, you should selet this
> + option.
This could become simply:
Select this option to enable HDMI support for Rockchip SoCs.
> diff --git a/drivers/gpu/drm/rockchip/Makefile
> b/drivers/gpu/drm/rockchip/Makefile
> index 2cb0672..beed7df 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -5,4 +5,6 @@
> rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
> rockchip_drm_gem.o
>
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> +
> obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> new file mode 100644
> index 000..11d54b0
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
Similarly, I'd rather this file be called drm_rockchip_hdmi.c to be
consistent with the rest of the files in drm/rockchip.
> @@ -0,0 +1,341 @@
> +/*
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rockchip_drm_drv.h"
> +#include "rockchip_drm_vop.h"
> +
> +#define GRF_SOC_CON60x025c
> +#define HDMI_SEL_VOP_LIT(1 << 4)
> +
> +struct rockchip_hdmi {
> + struct device *dev;
> + struct regmap *regmap;
> + struct drm_encoder encoder;
> +};
> +
> +#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
> +
> +static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
Let's stick to mpll_config. Not much value to abbreviate an abbreviation.
> +
Re: [PATCH net-next] net: sock: fix access via invalid file descriptor
From: Alexei Starovoitov
Date: Wed, 10 Dec 2014 20:14:55 -0800
> 0day robot reported the following crash:
> [ 21.233581] BUG: unable to handle kernel NULL pointer dereference at
> 0007
> [ 21.234709] IP: [] sk_attach_bpf+0x39/0xc2
>
> It's due to bpf_prog_get() returning ERR_PTR.
> Check it properly.
>
> Reported-by: Fengguang Wu
> Fixes: 89aa075832b0 ("net: sock: allow eBPF programs to be attached to
> sockets")
> Signed-off-by: Alexei Starovoitov
> ---
> Silly mistake. I was sure I've checked this error path. Apparently not :(
Applied, thanks Alexei.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v5 0/5] acerhdf: adding new models, appropriate governor and minor clean up
On Fri, Nov 28, 2014 at 03:20:47PM +0100, Peter Feuerer wrote: > Hi Darren, > > please apply this series of patches. Applied to testing, and given the level of review and testing already received, I will include in for-next for a late merge-window submission. Thanks, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] tracing/NMI/printk: Use seq_buf for safe printing from NMI context
On Mon, Dec 8, 2014 at 7:08 AM, Steven Rostedt wrote: > > One added bonus is that this code also makes the NMI dump stack work on > PREEMPT_RT kernels. As printk() includes sleeping locks on PREEMPT_RT, > printk() only writes to console if the console does not use any > rt_mutex converted spin locks. Which a lot do. Would it perhaps be possible/reasonable to also use this to get rid of the horrible "early_printk()" stuff, and switch to "vprintk_default" only once the system is sufficiently up-and-running? Hmm? Not that there are very many users of that horrible thing. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ASoC: rt5677: add a platform config option for DACREF source
DACREF power source can come from external 1.8V or codec internal 1.8V.
This patch adds the option to enable the internal DACREF power source.
Signed-off-by: Ben Zhang
---
Documentation/devicetree/bindings/sound/rt5677.txt | 3 +++
include/sound/rt5677.h | 2 ++
sound/soc/codecs/rt5677.c | 9 +
3 files changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rt5677.txt
b/Documentation/devicetree/bindings/sound/rt5677.txt
index f54d0dd..f06d52a 100644
--- a/Documentation/devicetree/bindings/sound/rt5677.txt
+++ b/Documentation/devicetree/bindings/sound/rt5677.txt
@@ -22,6 +22,9 @@ Optional properties:
- realtek,micbias1
Select 0/1/2/3 to set MICBIAS1 voltage to 1.476V/2.970V/1.242V/2.475V
+- realtek,internal-dacref-en
+ Select codec internal 1.8V as DACREF source optionally.
+
- realtek,in1-differential
- realtek,in2-differential
- realtek,lout1-differential
diff --git a/include/sound/rt5677.h b/include/sound/rt5677.h
index efa74bb..42866f3 100644
--- a/include/sound/rt5677.h
+++ b/include/sound/rt5677.h
@@ -28,6 +28,8 @@ enum rt5677_dmic2_clk {
struct rt5677_platform_data {
/* MICBIAS output voltage control */
enum rt5677_micbias micbias1;
+ /* Select codec internal 1.8V as DACREF source optionally */
+ bool internal_dacref_en;
/* IN1/IN2/LOUT1/LOUT2/LOUT3 can optionally be differential */
bool in1_diff;
bool in2_diff;
diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c
index ac4bee8..e6d7bb4 100644
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@ -4552,6 +4552,8 @@ MODULE_DEVICE_TABLE(i2c, rt5677_i2c_id);
static int rt5677_parse_dt(struct rt5677_priv *rt5677, struct device_node *np)
{
of_property_read_u32(np, "realtek,micbias1", >pdata.micbias1);
+ rt5677->pdata.internal_dacref_en = of_property_read_bool(np,
+ "realtek,internal-dacref-en");
rt5677->pdata.in1_diff = of_property_read_bool(np,
"realtek,in1-differential");
rt5677->pdata.in2_diff = of_property_read_bool(np,
@@ -4728,6 +4730,13 @@ static int rt5677_i2c_probe(struct i2c_client *i2c,
RT5677_MICBIAS1_CTRL_VDD_MASK,
rt5677->pdata.micbias1 << RT5677_MICBIAS1_CTRL_VDD_SFT);
+ if (rt5677->pdata.internal_dacref_en) {
+ regmap_update_bits(rt5677->regmap, RT5677_PR_BASE +
+ RT5677_TEST_CTRL1, 1 << 9, 1 << 9);
+ regmap_update_bits(rt5677->regmap, RT5677_PR_BASE +
+ RT5677_SOFT_DEPOP_DAC_CLK_CTRL, 1 << 5, 1 << 5);
+ }
+
if (rt5677->pdata.in1_diff)
regmap_update_bits(rt5677->regmap, RT5677_IN1,
RT5677_IN_DF1, RT5677_IN_DF1);
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ASoC: rt5677: add a platform config option for MICBIAS voltage
The MICBIAS voltage for IN1 can be set to 1.476V/2.970V/1.242V/2.475V
Signed-off-by: Ben Zhang
---
Documentation/devicetree/bindings/sound/rt5677.txt | 4
include/sound/rt5677.h | 9 +
sound/soc/codecs/rt5677.c | 6 ++
3 files changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rt5677.txt
b/Documentation/devicetree/bindings/sound/rt5677.txt
index 740ff77..f54d0dd 100644
--- a/Documentation/devicetree/bindings/sound/rt5677.txt
+++ b/Documentation/devicetree/bindings/sound/rt5677.txt
@@ -19,6 +19,9 @@ Optional properties:
- realtek,pow-ldo2-gpio : The GPIO that controls the CODEC's POW_LDO2 pin.
+- realtek,micbias1
+ Select 0/1/2/3 to set MICBIAS1 voltage to 1.476V/2.970V/1.242V/2.475V
+
- realtek,in1-differential
- realtek,in2-differential
- realtek,lout1-differential
@@ -70,6 +73,7 @@ rt5677 {
realtek,pow-ldo2-gpio =
< TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
+ realtek,micbias1 = <1> /* MICBIAS1 = 2.970V */
realtek,in1-differential = "true";
realtek,gpio-config = /bits/ 8 <0 0 0 0 0 2>; /* pull up GPIO6 */
realtek,jd2-gpio = <3>; /* Enables Jack detection for GPIO6 */
diff --git a/include/sound/rt5677.h b/include/sound/rt5677.h
index d9eb7d8..efa74bb 100644
--- a/include/sound/rt5677.h
+++ b/include/sound/rt5677.h
@@ -12,6 +12,13 @@
#ifndef __LINUX_SND_RT5677_H
#define __LINUX_SND_RT5677_H
+enum rt5677_micbias {
+ RT5677_MICBIAS_1_476V = 0,
+ RT5677_MICBIAS_2_970V = 1,
+ RT5677_MICBIAS_1_242V = 2,
+ RT5677_MICBIAS_2_475V = 3,
+};
+
enum rt5677_dmic2_clk {
RT5677_DMIC_CLK1 = 0,
RT5677_DMIC_CLK2 = 1,
@@ -19,6 +26,8 @@ enum rt5677_dmic2_clk {
struct rt5677_platform_data {
+ /* MICBIAS output voltage control */
+ enum rt5677_micbias micbias1;
/* IN1/IN2/LOUT1/LOUT2/LOUT3 can optionally be differential */
bool in1_diff;
bool in2_diff;
diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c
index 81fe146..ac4bee8 100644
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@ -4551,6 +4551,7 @@ MODULE_DEVICE_TABLE(i2c, rt5677_i2c_id);
static int rt5677_parse_dt(struct rt5677_priv *rt5677, struct device_node *np)
{
+ of_property_read_u32(np, "realtek,micbias1", >pdata.micbias1);
rt5677->pdata.in1_diff = of_property_read_bool(np,
"realtek,in1-differential");
rt5677->pdata.in2_diff = of_property_read_bool(np,
@@ -4722,6 +4723,11 @@ static int rt5677_i2c_probe(struct i2c_client *i2c,
if (ret != 0)
dev_warn(>dev, "Failed to apply regmap patch: %d\n", ret);
+ regmap_update_bits(rt5677->regmap, RT5677_MICBIAS,
+ RT5677_MICBIAS1_OUTVOLT_MASK |
+ RT5677_MICBIAS1_CTRL_VDD_MASK,
+ rt5677->pdata.micbias1 << RT5677_MICBIAS1_CTRL_VDD_SFT);
+
if (rt5677->pdata.in1_diff)
regmap_update_bits(rt5677->regmap, RT5677_IN1,
RT5677_IN_DF1, RT5677_IN_DF1);
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ASoC: rt5677: add REGMAP_I2C and REGMAP_IRQ dependency
The codec driver uses regmap to do i2c read/write. The codec driver started to use REGMAP_IRQ since: 5e3363ad1b7b2e1f197a3f56b01e21cb155ad454 ASoC: rt5677: add GPIO IRQ support Signed-off-by: Ben Zhang --- sound/soc/codecs/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 6f21a76..60f9425 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -503,6 +503,8 @@ config SND_SOC_RT5670 config SND_SOC_RT5677 tristate + select REGMAP_I2C + select REGMAP_IRQ config SND_SOC_RT5677_SPI tristate -- 2.2.0.rc0.207.ga3a616c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] net: sock: fix access via invalid file descriptor
0day robot reported the following crash:
[ 21.233581] BUG: unable to handle kernel NULL pointer dereference at
0007
[ 21.234709] IP: [] sk_attach_bpf+0x39/0xc2
It's due to bpf_prog_get() returning ERR_PTR.
Check it properly.
Reported-by: Fengguang Wu
Fixes: 89aa075832b0 ("net: sock: allow eBPF programs to be attached to sockets")
Signed-off-by: Alexei Starovoitov
---
Silly mistake. I was sure I've checked this error path. Apparently not :(
net/core/filter.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 8cc3c03078b3..ec9baea10c16 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1103,8 +1103,8 @@ int sk_attach_bpf(u32 ufd, struct sock *sk)
return -EPERM;
prog = bpf_prog_get(ufd);
- if (!prog)
- return -EINVAL;
+ if (IS_ERR(prog))
+ return PTR_ERR(prog);
if (prog->aux->prog_type != BPF_PROG_TYPE_SOCKET_FILTER) {
/* valid fd, but invalid program type */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, 2014-12-10 at 17:57 -0800, Yinghai Lu wrote: > On Wed, Dec 10, 2014 at 4:35 PM, Borislav Petkov wrote: > > On Wed, Dec 10, 2014 at 04:31:22PM -0800, Yinghai Lu wrote: > >> > 2) Send patches inline. It's a pain to review and reply and I can't > >> >use my normal tooling. > >> > >> I can not, as gmail does not allow that. > > > > Lemme guess, this is some kind of a joke you're making, right? > > I am using yhlu.ker...@gmail.com to send as ying...@kernel.org. > > Tried with mutt or thunderbird etc, all kept on downloading All mail clients are sh*t :) Evolution has it's annoyances too, but this ain't one of them. I've set up both imap and pop evolution accounts for gmail. I generally only enable the pop account, but can enable both simultaneously. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ftrace/fgraph/x86] BUG: unable to handle kernel paging request at 3d00c17d
On Wed, 10 Dec 2014 15:17:32 -0800 Fengguang Wu wrote: > Hi Steven, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > commit 6a06bdbf7f9c669743f58084991ba280f2925586 > Author: Steven Rostedt (Red Hat) > AuthorDate: Mon Nov 24 21:00:34 2014 -0500 > Commit: Steven Rostedt > CommitDate: Mon Dec 1 14:08:58 2014 -0500 > > ftrace/fgraph/x86: Have prepare_ftrace_return() take ip as first parameter > > The function graph helper function prepare_ftrace_return() which does the > work > to hijack the parent pointer has that parent pointer as its first > parameter. > Instead, if we make it the second parameter and have ip as the first > parameter > (self_addr), then it can use the %rdi from save_mcount_regs that loads it > already. > > Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos > > Reviewed-by: Thomas Gleixner > Signed-off-by: Steven Rostedt Crap! Yeah, I was wondering how this could be the bug, but then I realized this was i386 not x86_64 and I never updated the i386 call to prepare_ftrace_return(). Does this patch fix it? -- Steve diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index b553ed89e5f5..df3e608d409b 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -1192,10 +1192,10 @@ ENTRY(ftrace_graph_caller) pushl %eax pushl %ecx pushl %edx - movl 0xc(%esp), %edx - lea 0x4(%ebp), %eax + movl 0xc(%esp), %eax + lea 0x4(%ebp), %edx movl (%ebp), %ecx - subl $MCOUNT_INSN_SIZE, %edx + subl $MCOUNT_INSN_SIZE, %eax call prepare_ftrace_return popl %edx popl %ecx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] net: introduce helper macro for_each_cmsghdr
From: Gu Zheng Date: Thu, 11 Dec 2014 11:22:04 +0800 > Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating > cmsghdr from msghdr, just cleanup. > > Signed-off-by: Gu Zheng > --- > v3: > -drop the changes about user-land programs as David suggested. > v2: > -use the lower-case macro name as Joe suggested. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] net: introduce helper macro for_each_cmsghdr
Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
cmsghdr from msghdr, just cleanup.
Signed-off-by: Gu Zheng
---
v3:
-drop the changes about user-land programs as David suggested.
v2:
-use the lower-case macro name as Joe suggested.
crypto/af_alg.c|2 +-
include/linux/socket.h |4
net/core/scm.c |3 +--
net/dccp/proto.c |5 ++---
net/ipv4/ip_sockglue.c |2 +-
net/ipv6/datagram.c|2 +-
net/iucv/af_iucv.c |4 +---
net/rds/send.c |4 ++--
net/rxrpc/ar-output.c |2 +-
net/sctp/socket.c |3 +--
10 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 6a3ad80..bc21f52 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -399,7 +399,7 @@ int af_alg_cmsg_send(struct msghdr *msg, struct
af_alg_control *con)
{
struct cmsghdr *cmsg;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
if (cmsg->cmsg_level != SOL_ALG)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index bb9b836..0e71278 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -94,6 +94,10 @@ struct cmsghdr {
(cmsg)->cmsg_len <= (unsigned long) \
((mhdr)->msg_controllen - \
((char *)(cmsg) - (char *)(mhdr)->msg_control)))
+#define for_each_cmsghdr(cmsg, msg) \
+ for (cmsg = CMSG_FIRSTHDR(msg); \
+cmsg; \
+cmsg = CMSG_NXTHDR(msg, cmsg))
/*
* Get the next cmsg header
diff --git a/net/core/scm.c b/net/core/scm.c
index b442e7e..3b6899b 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -129,8 +129,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg,
struct scm_cookie *p)
struct cmsghdr *cmsg;
int err;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg))
- {
+ for_each_cmsghdr(cmsg, msg) {
err = -EINVAL;
/* Verify that cmsg_len is at least sizeof(struct cmsghdr) */
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index 5ab6627..e7413a9 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -703,7 +703,7 @@ EXPORT_SYMBOL_GPL(compat_dccp_getsockopt);
static int dccp_msghdr_parse(struct msghdr *msg, struct sk_buff *skb)
{
- struct cmsghdr *cmsg = CMSG_FIRSTHDR(msg);
+ struct cmsghdr *cmsg;
/*
* Assign an (opaque) qpolicy priority value to skb->priority.
@@ -717,8 +717,7 @@ static int dccp_msghdr_parse(struct msghdr *msg, struct
sk_buff *skb)
*/
skb->priority = 0;
- for (; cmsg != NULL; cmsg = CMSG_NXTHDR(msg, cmsg)) {
-
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 9daf217..839db9d 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -192,7 +192,7 @@ int ip_cmsg_send(struct net *net, struct msghdr *msg,
struct ipcm_cookie *ipc,
int err, val;
struct cmsghdr *cmsg;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
#if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 2cdc383..7252965 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -640,7 +640,7 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
int len;
int err = 0;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
int addr_type;
if (!CMSG_OK(msg, cmsg)) {
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index a089b6b..b69d87e 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -1070,9 +1070,7 @@ static int iucv_sock_sendmsg(struct kiocb *iocb, struct
socket *sock,
txmsg.class = 0;
/* iterate over control messages */
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg;
- cmsg = CMSG_NXTHDR(msg, cmsg)) {
-
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg)) {
err = -EINVAL;
goto out;
diff --git a/net/rds/send.c b/net/rds/send.c
index 0a64541..b23e7b8 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -826,7 +826,7 @@ static int rds_rm_size(struct msghdr *msg, int data_len)
int cmsg_groups = 0;
int retval;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
@@ -878,7 +878,7 @@ static int
Re: [PATCH] sched/fair: change where we report sched stats
On Wed, 2014-12-10 at 16:48 -0500, Josef Bacik wrote: > On 12/10/2014 01:23 AM, Mike Galbraith wrote: > > On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote: > > > >> This patch moves stat stuff to after the schedule, right as we are waking > >> up, > > > > But sleep/block ends when the task is awakened/enqueued, not when it > > gets the CPU. You're adding scheduling latency, breaking accounting. > > > > Yes I'm aware of that. I don't care if the delay time is slightly > higher than normal, I care about knowing exactly why we were sleeping to > begin with. I suppose I could leave the accounting part where it is and > then just fire the tracepoint when it's put on the CPU so we get the > best of both worlds, but honestly I don't feel like adding the extra > scheduling latency into the accounting is that big of a deal. Thanks, I think sleep/iowait should remain what they are, sleep/iowait end at wakeup. I don't think waker trace is useless either for that matter. Who/when ends a sleep period is just as much a part of the picture as what triggered that sleep. Waker scheduling latency, thumb twiddling etc. extend sleep. Shrug, maintainer call. I don't recall ever having any difficulty determining why a task went to sleep, so don't get it. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3 V2] acpi:apd:add AMD ACPI2Platform device support
This is a new feature to interpret AMD specific ACPI device to
platform device such as I2C, UART found on AMD CZ and later
chipsets. It based on acpi soc.
Signed-off-by: Ken Xue
---
arch/x86/Kconfig| 11
drivers/acpi/Makefile | 2 +-
drivers/acpi/acpi_apd.c | 71 +
drivers/acpi/internal.h | 2 ++
drivers/acpi/scan.c | 1 +
5 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 drivers/acpi/acpi_apd.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ded8a67..030f508 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -495,6 +495,17 @@ config X86_INTEL_LPSS
things like clock tree (common clock framework) and pincontrol
which are needed by the LPSS peripheral drivers.
+config X86_AMD_PLATFORM_DEVICE
+ bool "AMD ACPI2Platform devices support"
+ depends on ACPI
+ select COMMON_CLK
+ select PINCTRL
+ ---help---
+ Select to interpret AMD specific ACPI device to platform device
+ such as I2C, UART found on AMD Carrizo and later chipsets. Selecting
+ this option enables things like clock tree (common clock framework)
+ and pinctrl.
+
config IOSF_MBI
tristate "Intel SoC IOSF Sideband support for SoC platforms"
depends on PCI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index ae3397d..b07003a 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -40,7 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-y += acpi_soc.o acpi_lpss.o
+acpi-y += acpi_soc.o acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-y += int340x_thermal.o
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
new file mode 100644
index 000..b46e2af
--- /dev/null
+++ b/drivers/acpi/acpi_apd.c
@@ -0,0 +1,71 @@
+/*
+ * AMD ACPI support for ACPI2platform device.
+ *
+ * Copyright (c) 2014, AMD Corporation.
+ * Authors: Ken Xue
+ * Wu, Jeff
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+#include "acpi_soc.h"
+#include "internal.h"
+
+static struct acpi_soc a_soc;
+
+#ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
+#define APD_ADDR(desc) ((unsigned long))
+
+static int acpi_apd_setup(struct acpi_soc_dev_private_data *pdata)
+{
+ struct acpi_soc_dev_desc *dev_desc = pdata->dev_desc;
+ struct clk *clk = ERR_PTR(-ENODEV);
+
+ if (dev_desc->fixed_clk_rate) {
+ clk = clk_register_fixed_rate(>adev->dev,
+ dev_name(>adev->dev),
+ NULL, CLK_IS_ROOT,
+ dev_desc->fixed_clk_rate);
+ clk_register_clkdev(clk, NULL, dev_name(>adev->dev));
+ }
+
+ return 0;
+}
+
+static struct acpi_soc_dev_desc cz_i2c_desc = {
+ .setup = acpi_apd_setup,
+ .fixed_clk_rate = 13300,
+};
+
+static struct acpi_soc_dev_desc cz_uart_desc = {
+ .setup = acpi_apd_setup,
+ .fixed_clk_rate = 4800,
+};
+
+#else
+
+#define APD_ADDR(desc) (0UL)
+
+#endif /* CONFIG_X86_AMD_PLATFORM_DEVICE */
+
+static struct acpi_device_id acpi_apd_device_ids[] = {
+ /* Generic apd devices */
+ { "AMD0010", APD_ADDR(cz_i2c_desc) },
+ { "AMD0020", APD_ADDR(cz_uart_desc) },
+ { }
+};
+
+void __init acpi_apd_init(void)
+{
+ a_soc.ids = acpi_apd_device_ids;
+#ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
+ register_acpi_soc(_soc, false);
+#else
+ register_acpi_soc(_soc, true);
+#endif /* CONFIG_X86_AMD_PLATFORM_DEVICE */
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 447f6d6..bade825 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -68,6 +68,8 @@ static inline void acpi_debugfs_init(void) { return; }
#endif
void acpi_lpss_init(void);
+void acpi_apd_init(void);
+
acpi_status acpi_hotplug_schedule(struct acpi_device *adev, u32 src);
bool acpi_queue_hotplug_work(struct work_struct *work);
void acpi_device_hotplug(struct acpi_device *adev, u32 src);
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 0476e90..24fef2b 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2349,6 +2349,7 @@ int __init acpi_scan_init(void)
acpi_pci_link_init();
acpi_processor_init();
acpi_lpss_init();
+ acpi_apd_init();
acpi_cmos_rtc_init();
acpi_container_init();
acpi_memory_hotplug_init();
--
1.9.1
--
To unsubscribe from this list: send the line
[PATCH 1/3 V2] acpi:soc: merge common codes for creating platform device
This patch is supposed to deliver some common codes for AMD APD and
INTEL LPSS. It can help to convert some specific acpi devices to be
platform devices.
Signed-off-by: Ken Xue
---
drivers/acpi/Makefile | 2 +-
drivers/acpi/acpi_soc.c | 224
drivers/acpi/acpi_soc.h | 98 +
3 files changed, 323 insertions(+), 1 deletion(-)
create mode 100644 drivers/acpi/acpi_soc.c
create mode 100644 drivers/acpi/acpi_soc.h
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index c3b2fcb..ae3397d 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -40,7 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-y += acpi_lpss.o
+acpi-y += acpi_soc.o acpi_lpss.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-y += int340x_thermal.o
diff --git a/drivers/acpi/acpi_soc.c b/drivers/acpi/acpi_soc.c
new file mode 100644
index 000..46901d5
--- /dev/null
+++ b/drivers/acpi/acpi_soc.c
@@ -0,0 +1,224 @@
+/*
+ * ACPI SOC support for Intel Lynxpoint LPSS and AMD APD.
+ *
+ * Copyright (C) 2015, Intel Corporation & AMD Corporation
+ * Authors: Ken Xue
+ * Mika Westerberg
+ * Rafael J. Wysocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "acpi_soc.h"
+#include "internal.h"
+
+ACPI_MODULE_NAME("acpi_soc");
+
+/* A list for all acpi soc device */
+static LIST_HEAD(a_soc_list);
+
+static int is_memory(struct acpi_resource *res, void *not_used)
+{
+ struct resource r;
+
+ return !acpi_dev_resource_memory(res, );
+}
+
+static int acpi_soc_create_device(struct acpi_device *adev,
+ const struct acpi_device_id *id)
+{
+ struct acpi_soc_dev_desc *dev_desc;
+ struct acpi_soc_dev_private_data *pdata;
+ struct resource_list_entry *rentry;
+ struct list_head resource_list;
+ struct platform_device *pdev;
+ int ret;
+
+ dev_desc = (struct acpi_soc_dev_desc *)id->driver_data;
+ if (!dev_desc) {
+ pdev = acpi_create_platform_device(adev);
+ return IS_ERR_OR_NULL(pdev) ? PTR_ERR(pdev) : 1;
+ }
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(_list);
+ ret = acpi_dev_get_resources(adev, _list, is_memory, NULL);
+ if (ret < 0)
+ goto err_out;
+
+ list_for_each_entry(rentry, _list, node)
+ if (resource_type(>res) == IORESOURCE_MEM) {
+ if (dev_desc->mem_size_override)
+ pdata->mmio_size = dev_desc->mem_size_override;
+ else
+ pdata->mmio_size = resource_size(>res);
+ pdata->mmio_base = ioremap(rentry->res.start,
+ pdata->mmio_size);
+ break;
+ }
+
+ acpi_dev_free_resource_list(_list);
+
+ pdata->adev = adev;
+ pdata->dev_desc = dev_desc;
+
+ if (dev_desc->setup) {
+ ret = dev_desc->setup(pdata);
+ if (ret)
+ goto err_out;
+ }
+
+ /*
+* This works around a known issue in ACPI tables where acpi soc devices
+* have _PS0 and _PS3 without _PSC (and no power resources), so
+* acpi_bus_init_power() will assume that the BIOS has put them into D0.
+*/
+ ret = acpi_device_fix_up_power(adev);
+ if (ret) {
+ /* Skip the device, but continue the namespace scan. */
+ ret = 0;
+ goto err_out;
+ }
+
+ adev->driver_data = pdata;
+ pdev = acpi_create_platform_device(adev);
+ if (!IS_ERR_OR_NULL(pdev))
+ return 1;
+
+ ret = PTR_ERR(pdev);
+ adev->driver_data = NULL;
+
+ err_out:
+ kfree(pdata);
+ return ret;
+}
+
+static int acpi_soc_platform_notify(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+ struct platform_device *pdev = to_platform_device(data);
+ struct acpi_soc_dev_private_data *pdata;
+ struct acpi_device *adev;
+ struct acpi_soc *a_soc_entry;
+ const struct acpi_device_id *id = NULL;
+
+ list_for_each_entry(a_soc_entry, _soc_list, list) {
+ id = acpi_match_device(a_soc_entry->ids, >dev);
+ if (id)
+ break;
+ }
+
[PATCH v2 0/2] add the dvs support for rk808
rk808 has a dvs function, there are 3 pins for dvs, dvs1 & dvs2 & dvsok. Normally, the voltage of DCDC1/DCDC2 are controlled by BUCKn_ON_VSEL, when we pull dvs1/dvs2 pin to active, they would be controlled by BUCKn_DVS_VSEL. And the dvsok pin is used to indicate whether regulating has been completed. When dvs1/dvs2 pin change, dvsok would be pull down, and it would be pull up once the regulating is complete. Changes in v2: - increase description about dvs pins - modify the multiline commenting Chris Zhong (2): mfd: dt-bindings: add the description about dvs gpio for rk808 regulator: rk808: add dvs support Documentation/devicetree/bindings/mfd/rk808.txt | 13 +- drivers/regulator/rk808-regulator.c | 192 ++-- 2 files changed, 192 insertions(+), 13 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] mfd: dt-bindings: add the description about dvs gpio for rk808
add the description about dvs1, dvs2, dvsok, and add the example. Signed-off-by: Chris Zhong --- Changes in v2: - increase description about dvs pins Documentation/devicetree/bindings/mfd/rk808.txt | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt b/Documentation/devicetree/bindings/mfd/rk808.txt index 9e6e259..923cdca 100644 --- a/Documentation/devicetree/bindings/mfd/rk808.txt +++ b/Documentation/devicetree/bindings/mfd/rk808.txt @@ -24,6 +24,14 @@ Optional properties: - vcc10-supply: The input supply for LDO_REG6 - vcc11-supply: The input supply for LDO_REG8 - vcc12-supply: The input supply for SWITCH_REG2 +- dvs-gpios: buck1/2 can be controlled by gpio dvs, this is GPIO specifiers + for 2 host gpio's used for dvs. The format of the gpio specifier depends in + the gpio controller. If DVS GPIOs aren't present, voltage changes will happen + without being very quickly with no slow ramp time. +- dvsok-gpios: if we use dvs gpio to control buck1/2, this gpio will be pull + high, once RK808 completed the adjustment of voltage. If the DVSOK isn't + present, we'll just delay based on whatever is specified in the regulator + constraints. Regulators: All the regulators of RK808 to be instantiated shall be listed in a child node named 'regulators'. Each regulator is represented @@ -55,7 +63,10 @@ Example: interrupt-parent = <>; interrupts = <4 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; - pinctrl-0 = <_int>; + pinctrl-0 = <_int _ok _1 _2>; + dvsok-gpios = < 9 GPIO_ACTIVE_HIGH>; + dvs-gpios = < 11 GPIO_ACTIVE_HIGH>, + < 15 GPIO_ACTIVE_HIGH>; reg = <0x1b>; rockchip,system-power-controller; wakeup-source; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] regulator: rk808: add dvs support
rk808 has a dvs function, there are 3 pins for dvs, dvs1 & dvs2 & dvsok.
Normally, the voltage of DCDC1/DCDC2 are controlled by BUCKn_ON_VSEL, when
we pull dvs1/dvs2 pin to active, they would be controlled by BUCKn_DVS_VSEL.
And the dvsok pin is used to indicate whether regulating has been completed.
When dvs1/dvs2 pin change, dvsok would be pull down, and it would be pull up
once the regulating is complete.
Signed-off-by: Chris Zhong
---
Changes in v2:
- modify the multiline commenting
drivers/regulator/rk808-regulator.c | 192 +---
1 file changed, 180 insertions(+), 12 deletions(-)
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
index 33042eb..f31e4fc 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -16,10 +16,13 @@
* more details.
*/
-#include
+#include
+#include
#include
-#include
+#include
#include
+#include
+#include
#include
#include
@@ -36,12 +39,23 @@
#define RK808_RAMP_RATE_6MV_PER_US (2 << RK808_RAMP_RATE_OFFSET)
#define RK808_RAMP_RATE_10MV_PER_US(3 << RK808_RAMP_RATE_OFFSET)
+#define RK808_DVS2_POL BIT(2)
+#define RK808_DVS1_POL BIT(1)
+
/* Offset from XXX_ON_VSEL to XXX_SLP_VSEL */
#define RK808_SLP_REG_OFFSET 1
+/* Offset from XXX_ON_VSEL to XXX_DVS_VSEL */
+#define RK808_DVS_REG_OFFSET 2
+
/* Offset from XXX_EN_REG to SLEEP_SET_OFF_XXX */
#define RK808_SLP_SET_OFF_REG_OFFSET 2
+struct rk808_regulator_data {
+ struct gpio_desc *dvsok_gpio;
+ struct gpio_desc *dvs_gpio[2];
+};
+
static const int rk808_buck_config_regs[] = {
RK808_BUCK1_CONFIG_REG,
RK808_BUCK2_CONFIG_REG,
@@ -70,6 +84,97 @@ static const struct regulator_linear_range
rk808_ldo6_voltage_ranges[] = {
REGULATOR_LINEAR_RANGE(80, 0, 17, 10),
};
+int rk808_buck1_2_get_voltage_sel_regmap(struct regulator_dev *rdev)
+{
+ struct rk808_regulator_data *pdata = rdev_get_drvdata(rdev);
+ int id = rdev->desc->id - RK808_ID_DCDC1;
+ struct gpio_desc *gpio = pdata->dvs_gpio[id];
+ unsigned int val;
+ int ret;
+
+ if (IS_ERR(gpio) || gpiod_get_value(gpio) == 0)
+ return regulator_get_voltage_sel_regmap(rdev);
+
+ ret = regmap_read(rdev->regmap,
+ rdev->desc->vsel_reg + RK808_DVS_REG_OFFSET,
+ );
+ if (ret != 0)
+ return ret;
+
+ val &= rdev->desc->vsel_mask;
+ val >>= ffs(rdev->desc->vsel_mask) - 1;
+
+ return val;
+}
+
+int rk808_buck1_2_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
+{
+ struct rk808_regulator_data *pdata = rdev_get_drvdata(rdev);
+ int id = rdev->desc->id - RK808_ID_DCDC1;
+ struct gpio_desc *gpio = pdata->dvs_gpio[id];
+ unsigned int reg = rdev->desc->vsel_reg;
+ unsigned long timeout;
+ unsigned old_sel;
+ int ret, gpio_level;
+
+ if (IS_ERR(gpio))
+ return regulator_set_voltage_sel_regmap(rdev, sel);
+
+ gpio_level = gpiod_get_value(gpio);
+ if (gpio_level == 0) {
+ reg += RK808_DVS_REG_OFFSET;
+ ret = regmap_read(rdev->regmap, rdev->desc->vsel_reg, _sel);
+ } else {
+ ret = regmap_read(rdev->regmap,
+ reg + RK808_DVS_REG_OFFSET,
+ _sel);
+ }
+
+ if (ret != 0)
+ return ret;
+
+ sel <<= ffs(rdev->desc->vsel_mask) - 1;
+ sel |= old_sel & ~rdev->desc->vsel_mask;
+
+ ret = regmap_write(rdev->regmap, reg, sel);
+ if (ret)
+ return ret;
+
+ gpiod_set_value(gpio, !gpio_level);
+
+ /*
+* dvsok pin would be pull down when dvs1/2 pin changed, and
+* it would be pull up once the voltage regulate complete.
+* No need to wait dvsok signal when voltage falling.
+*/
+ if (old_sel < sel && !IS_ERR(pdata->dvsok_gpio)) {
+ timeout = jiffies + msecs_to_jiffies(1);
+ while (!time_after(jiffies, timeout)) {
+ udelay(1);
+ if (gpiod_get_value(pdata->dvsok_gpio))
+ return 0;
+ }
+ gpiod_set_value(gpio, gpio_level);
+ pr_err("%s wait dvsok timeout\n", rdev->desc->name);
+ ret = -EBUSY;
+ }
+
+ return ret;
+}
+
+int rk808_buck1_2_set_voltage_time_sel(struct regulator_dev *rdev,
+ unsigned int old_selector,
+ unsigned int new_selector)
+{
+ struct rk808_regulator_data *pdata = rdev_get_drvdata(rdev);
+
+ /* if there is a dvsok pin, we don't need wait extra time here */
+ if (!IS_ERR(pdata->dvsok_gpio))
+ return 0;
+
+ return regulator_set_voltage_time_sel(rdev, old_selector, new_selector);
+}
+
[PATCH 3/3] acpi:lpss:Refine lpss codes to fit acpi soc.
Signed-off-by: Ken Xue
---
drivers/acpi/acpi_lpss.c | 566 ++-
1 file changed, 221 insertions(+), 345 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 93d1606..554c932 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -10,7 +10,6 @@
* published by the Free Software Foundation.
*/
-#include
#include
#include
#include
@@ -21,10 +20,13 @@
#include
#include
+#include "acpi_soc.h"
#include "internal.h"
ACPI_MODULE_NAME("acpi_lpss");
+static struct acpi_soc a_soc;
+
#ifdef CONFIG_X86_INTEL_LPSS
#define LPSS_ADDR(desc) ((unsigned long))
@@ -58,170 +60,71 @@ ACPI_MODULE_NAME("acpi_lpss");
#define LPSS_CLK BIT(0)
#define LPSS_CLK_GATE BIT(1)
#define LPSS_CLK_DIVIDER BIT(2)
-#define LPSS_LTR BIT(3)
-#define LPSS_SAVE_CTX BIT(4)
-
-struct lpss_private_data;
-
-struct lpss_device_desc {
- unsigned int flags;
- unsigned int prv_offset;
- size_t prv_size_override;
- void (*setup)(struct lpss_private_data *pdata);
-};
-
-static struct lpss_device_desc lpss_dma_desc = {
- .flags = LPSS_CLK,
-};
-
-struct lpss_private_data {
- void __iomem *mmio_base;
- resource_size_t mmio_size;
- unsigned int fixed_clk_rate;
- struct clk *clk;
- const struct lpss_device_desc *dev_desc;
- u32 prv_reg_ctx[LPSS_PRV_REG_COUNT];
-};
/* UART Component Parameter Register */
#define LPSS_UART_CPR 0xF4
#define LPSS_UART_CPR_AFCE BIT(4)
-static void lpss_uart_setup(struct lpss_private_data *pdata)
+static u32 __lpss_reg_read(struct acpi_soc_dev_private_data *pdata,
+ unsigned int reg)
{
- unsigned int offset;
- u32 val;
-
- offset = pdata->dev_desc->prv_offset + LPSS_TX_INT;
- val = readl(pdata->mmio_base + offset);
- writel(val | LPSS_TX_INT_MASK, pdata->mmio_base + offset);
-
- val = readl(pdata->mmio_base + LPSS_UART_CPR);
- if (!(val & LPSS_UART_CPR_AFCE)) {
- offset = pdata->dev_desc->prv_offset + LPSS_GENERAL;
- val = readl(pdata->mmio_base + offset);
- val |= LPSS_GENERAL_UART_RTS_OVRD;
- writel(val, pdata->mmio_base + offset);
- }
+ return readl(pdata->mmio_base + pdata->dev_desc->prv_offset + reg);
}
-static void byt_i2c_setup(struct lpss_private_data *pdata)
+static void __lpss_reg_write(u32 val, struct acpi_soc_dev_private_data *pdata,
+unsigned int reg)
{
- unsigned int offset;
- u32 val;
-
- offset = pdata->dev_desc->prv_offset + LPSS_RESETS;
- val = readl(pdata->mmio_base + offset);
- val |= LPSS_RESETS_RESET_APB | LPSS_RESETS_RESET_FUNC;
- writel(val, pdata->mmio_base + offset);
-
- if (readl(pdata->mmio_base + pdata->dev_desc->prv_offset))
- pdata->fixed_clk_rate = 13300;
+ writel(val, pdata->mmio_base + pdata->dev_desc->prv_offset + reg);
}
-static struct lpss_device_desc lpt_dev_desc = {
- .flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_LTR,
- .prv_offset = 0x800,
-};
-
-static struct lpss_device_desc lpt_i2c_dev_desc = {
- .flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_LTR,
- .prv_offset = 0x800,
-};
-
-static struct lpss_device_desc lpt_uart_dev_desc = {
- .flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_LTR,
- .prv_offset = 0x800,
- .setup = lpss_uart_setup,
-};
-
-static struct lpss_device_desc lpt_sdio_dev_desc = {
- .flags = LPSS_LTR,
- .prv_offset = 0x1000,
- .prv_size_override = 0x1018,
-};
-
-static struct lpss_device_desc byt_pwm_dev_desc = {
- .flags = LPSS_SAVE_CTX,
-};
-
-static struct lpss_device_desc byt_uart_dev_desc = {
- .flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX,
- .prv_offset = 0x800,
- .setup = lpss_uart_setup,
-};
-
-static struct lpss_device_desc byt_spi_dev_desc = {
- .flags = LPSS_CLK | LPSS_CLK_GATE | LPSS_CLK_DIVIDER | LPSS_SAVE_CTX,
- .prv_offset = 0x400,
-};
-
-static struct lpss_device_desc byt_sdio_dev_desc = {
- .flags = LPSS_CLK,
-};
-
-static struct lpss_device_desc byt_i2c_dev_desc = {
- .flags = LPSS_CLK | LPSS_SAVE_CTX,
- .prv_offset = 0x800,
- .setup = byt_i2c_setup,
-};
-
-#else
-
-#define LPSS_ADDR(desc) (0UL)
-
-#endif /* CONFIG_X86_INTEL_LPSS */
-
-static const struct acpi_device_id acpi_lpss_device_ids[] = {
- /* Generic LPSS devices */
- { "INTL9C60", LPSS_ADDR(lpss_dma_desc) },
-
- /* Lynxpoint LPSS devices */
- { "INT33C0", LPSS_ADDR(lpt_dev_desc) },
- { "INT33C1", LPSS_ADDR(lpt_dev_desc) },
- { "INT33C2", LPSS_ADDR(lpt_i2c_dev_desc) },
- { "INT33C3", LPSS_ADDR(lpt_i2c_dev_desc) },
- { "INT33C4",
[PATCH 2/3] ARM: at91: sama5d3xek/dt: use dt ids for wm8904
From: Alexander Morozov
Using the wm8904 device tree compatible string.
Signed-off-by: Alexander Morozov
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/sama5d3xmb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 49c10d3..2a1aa58 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -45,7 +45,7 @@
*/
i2c0: i2c@f0014000 {
wm8904: wm8904@1a {
- compatible = "wm8904";
+ compatible = "wlf,wm8904";
reg = <0x1a>;
clocks = <>;
clock-names = "mclk";
--
2.1.0.24.g4109c28
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: at91: at91sam9n12ek/dt: use dt ids for wm8904
Using the device tree ids for wm8904 codec.
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/at91sam9n12ek.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 13bb24e..9575c0d 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -54,7 +54,7 @@
status = "okay";
wm8904: codec@1a {
- compatible = "wm8904";
+ compatible = "wlf,wm8904";
reg = <0x1a>;
clocks = <>;
clock-names = "mclk";
--
2.1.0.24.g4109c28
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ASoC: codecs: wm8904: add dt ids table
From: Alexander Morozov
Signed-off-by: Alexander Morozov
Signed-off-by: Bo Shen
---
sound/soc/codecs/wm8904.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index 4d2d2b1..23831a5 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -2255,10 +2255,19 @@ static const struct i2c_device_id wm8904_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, wm8904_i2c_id);
+static const struct of_device_id wm8904_of_match[] = {
+ { .compatible = "wlf,wm8904", },
+ { .compatible = "wlf,wm8912", },
+ { .compatible = "wlf,wm8918", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, wm8904_of_match);
+
static struct i2c_driver wm8904_i2c_driver = {
.driver = {
.name = "wm8904",
.owner = THIS_MODULE,
+ .of_match_table = wm8904_of_match,
},
.probe =wm8904_i2c_probe,
.remove = wm8904_i2c_remove,
--
2.1.0.24.g4109c28
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mm/compaction: stop the isolation when we isolate enough freepage
On Wed, Dec 10, 2014 at 04:19:13PM +0100, Vlastimil Babka wrote:
> On 12/10/2014 08:00 AM, Joonsoo Kim wrote:
> >On Mon, Dec 08, 2014 at 10:59:17AM +0100, Vlastimil Babka wrote:
> >>On 12/08/2014 08:16 AM, Joonsoo Kim wrote:
> >>>From: Joonsoo Kim
> >>>
> >>>Currently, freepage isolation in one pageblock doesn't consider how many
> >>>freepages we isolate. When I traced flow of compaction, compaction
> >>>sometimes isolates more than 256 freepages to migrate just 32 pages.
> >>>
> >>>In this patch, freepage isolation is stopped at the point that we
> >>>have more isolated freepage than isolated page for migration. This
> >>>results in slowing down free page scanner and make compaction success
> >>>rate higher.
> >>>
> >>>stress-highalloc test in mmtests with non movable order 7 allocation shows
> >>>increase of compaction success rate and slight improvement of allocation
> >>>success rate.
> >>>
> >>>Allocation success rate on phase 1 (%)
> >>>62.70 : 64.00
> >>>
> >>>Compaction success rate (Compaction success * 100 / Compaction stalls, %)
> >>>35.13 : 41.50
> >>
> >>This is weird. I could maybe understand that isolating too many
> >
> >In fact, I also didn't fully understand why it results in this
> >result. :)
> >
> >>freepages and then returning them is a waste of time if compaction
> >>terminates immediately after the following migration (otherwise we
> >>would keep those free pages for the future migrations within same
> >>compaction run). And wasting time could reduce success rates for
> >>async compaction terminating prematurely due to cond_resched(), but
> >>that should be all the difference, unless there's another subtle
> >>bug, no?
> >
> >My guess is that there is bad effect when we release isolated
> >freepages. In asynchronous compaction, this happens quite easily.
> >In this case, freepages are returned to page allocator and, maybe,
> >they are on pcp list or front of buddy list so they would be used by
> >another user at first. This reduces freepages we can utilize so
> >compaction is finished earlier.
>
> Hmm, some might even stay on the pcplists and we won't isolate them
> again. So we will leave them behind. I wouldn't expect such big
> difference here, but anyway...
> It might be interesting to evaluate if a pcplists drain after
> returning isolated freepages (unless the scanners have already met,
> that's pointless) would make any difference.
Yes, I will check it.
>
> >>
> >>>pfn where both scanners meets on compaction complete
> >>>(separate test due to enormous tracepoint buffer)
> >>>(zone_start=4096, zone_end=1048576)
> >>>586034 : 654378
> >>
> >>The difference here suggests that there is indeed another subtle bug
> >>related to where free scanner restarts, and we must be leaving the
> >>excessively isolated (and then returned) freepages behind. Otherwise
> >>I think the scanners should meet at the same place regardless of
> >>your patch.
> >
> >I tried to find another subtle bug, but, can't find any critical one.
> >Hmm...
> >
> >Anyway, regardless of the reason of result, this patch seems reasonable,
> >because we don't need to waste time to isolate unneeded freepages.
>
> Right.
>
> >Thanks.
> >
> >>
> >>>Signed-off-by: Joonsoo Kim
> >>>---
> >>> mm/compaction.c | 17 ++---
> >>> 1 file changed, 10 insertions(+), 7 deletions(-)
> >>>
> >>>diff --git a/mm/compaction.c b/mm/compaction.c
> >>>index 2fd5f79..12223b9 100644
> >>>--- a/mm/compaction.c
> >>>+++ b/mm/compaction.c
> >>>@@ -422,6 +422,13 @@ static unsigned long isolate_freepages_block(struct
> >>>compact_control *cc,
> >>>
> >>> /* If a page was split, advance to the end of it */
> >>> if (isolated) {
> >>>+ cc->nr_freepages += isolated;
> >>>+ if (!strict &&
> >>>+ cc->nr_migratepages <= cc->nr_freepages) {
> >>>+ blockpfn += isolated;
> >>>+ break;
> >>>+ }
> >>>+
> >>> blockpfn += isolated - 1;
> >>> cursor += isolated - 1;
> >>> continue;
> >>>@@ -831,7 +838,6 @@ static void isolate_freepages(struct compact_control
> >>>*cc)
> >>> unsigned long isolate_start_pfn; /* exact pfn we start at */
> >>> unsigned long block_end_pfn;/* end of current pageblock */
> >>> unsigned long low_pfn; /* lowest pfn scanner is able to scan */
> >>>- int nr_freepages = cc->nr_freepages;
> >>> struct list_head *freelist = >freepages;
> >>>
> >>> /*
> >>>@@ -856,11 +862,11 @@ static void isolate_freepages(struct compact_control
> >>>*cc)
> >>>* pages on cc->migratepages. We stop searching if the migrate
> >>>* and free page scanners meet or enough free pages are isolated.
> >>>*/
> >>>- for (; block_start_pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
> >>>+ for (; block_start_pfn >= low_pfn &&
> >>>+ cc->nr_migratepages > cc->nr_freepages;
> >>>
default enable sparse __CHECK_ENDIAN__ (was: Re: [PATCH v7 2/3] net: Add Keystone NetCP ethernet driver)
On Wed, 2014-12-10 at 20:41 -0500, David Miller wrote: > From: Murali Karicheri > > Are you referring to the static code analyser sparse that is invoked > > through? > You have to explicitly enable endian checking, it's not on by > default. There don't seem to be thousands of warnings anymore. Maybe it's time to default enable it when using C=? from: Documentation/sparse.txt: The optional make variable CF can be used to pass arguments to sparse. The build system passes -Wbitwise to sparse automatically. To perform endianness checks, you may define __CHECK_ENDIAN__: make C=2 CF="-D__CHECK_ENDIAN__" These checks are disabled by default as they generate a host of warnings. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/16] genirq: Introduce callback irq_chip.irq_write_msi_msg
On 2014/12/10 18:25, Thomas Gleixner wrote: > On Wed, 10 Dec 2014, Yun Wu (Abel) wrote: >> On 2014/11/19 19:11, Thomas Gleixner wrote: >> I spent last two weeks implementing and testing my original idea about making >> the sub domains generic, based on stacked domain feature. Now it comes real, >> please see the attached patch. > > Can you please send patches inline? Attached is a pain to reply to. Sure, why not. > >> With this patch applied, I think things will get easier. > > I don't see what gets easier. It's just another infrastructure which > is painfully similar to MSI. Then please help me feel that pain when I post inline patches, thanks. :) > >> This patch (also with several other patches) is tested on Hisilicon ARM64 >> SoC, >> with non PCI devices capable of message based interrupts. The PCI part is not >> tested because it needs large refactoring work to do. So yes, the testing >> work >> is not sufficient, but I think the patch is enough to present what I really >> wanted to express. :) > > Not really. > > If you provide proper patches which make use of it and most important > a proper refactoring of the PCI/MSI side then we can discuss that, but > for now it's just handwaving. > OK, I will start a new thread when I finished PCI/MSI refactoring work. Thanks, Abel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] soc: samsung: add exynos chipid driver support
Hi Yadwinder,
On Thursday 04 December 2014 11:56 PM, Yadwinder Singh Brar wrote:
Hi Pankaj,
On Wed, Dec 3, 2014 at 1:47 PM, Pankaj Dubey mailto:pankaj.du...@samsung.com>> wrote:
Exynos SoCs have Chipid, for identification of product IDs
and SoC revisions. This patch intendes to provide initialization
code for all these functionalites, at the same time it provides some
sysfs entries for accessing these information to userspace.
This driver usese existing binding for exnos-chipid.
[ ... ]
+
+static unsigned int soc_product_id;
+static unsigned int soc_revision;
+
+int exynos_product_id(void)
+{
+ return soc_product_id;
+}
+EXPORT_SYMBOL(exynos_product_id);
+
+int exynos_revision(void)
+{
+ return soc_revision;
+}
+EXPORT_SYMBOL(exynos_revision);
+
How about exporting only a struct containing members : soc_revision,
soc_product_id
OK, keeping in mind that chipid driver might be used from other drivers
as well (such as asv) other than from mach-exynos, we can do this.
and may be some more like asv/fused_info and keeping these function as
Other members such as fused_info etc. can be added as and when required.
As of now there is no active user of all those.
inlines ?
+static const char *exynos_product_id_to_name(unsigned int product_id)
__init ? hmm .. I think almost whole driver other than __ATTR funcs.
OK, I'll take care of this in next patch version.
Otherwise it looks nice to me :)
Best Regards,
Yadwinder
Thanks for review.
Pankaj Dubey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] misc: sram: switch to ioremap_wc from ioremap
Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.
Signed-off-by: Abhilash Kesavan
---
This is based on the discussion about the crash here:
http://www.spinics.net/lists/arm-kernel/msg384647.html
drivers/misc/sram.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 21181fa..15b4d4e 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -69,12 +69,23 @@ static int sram_probe(struct platform_device *pdev)
INIT_LIST_HEAD(_list);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- virt_base = devm_ioremap_resource(>dev, res);
- if (IS_ERR(virt_base))
- return PTR_ERR(virt_base);
+ if (!res) {
+ dev_err(>dev, "found no memory resource\n");
+ return -EINVAL;
+ }
size = resource_size(res);
+ if (!devm_request_mem_region(>dev,
+ res->start, size, pdev->name)) {
+ dev_err(>dev, "could not request region for resource\n");
+ return -EBUSY;
+ }
+
+ virt_base = devm_ioremap_wc(>dev, res->start, size);
+ if (IS_ERR(virt_base))
+ return PTR_ERR(virt_base);
+
sram = devm_kzalloc(>dev, sizeof(*sram), GFP_KERNEL);
if (!sram)
return -ENOMEM;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] lib: devres: add a helper function for ioremap_wc
Implement a resource managed writecombine ioremap function.
Signed-off-by: Abhilash Kesavan
---
Documentation/driver-model/devres.txt |1 +
include/linux/io.h|2 ++
lib/devres.c | 28
3 files changed, 31 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index b5ab416..0f80cee 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -274,6 +274,7 @@ IOMAP
devm_ioport_unmap()
devm_ioremap()
devm_ioremap_nocache()
+ devm_ioremap_wc()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_iounmap()
pcim_iomap()
diff --git a/include/linux/io.h b/include/linux/io.h
index fa02e55..42b33f0 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
resource_size_t size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
resource_size_t size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 0f1dd2e..e8e1738 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev,
resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: at91/dt: sama5d4: fix the timer reg length
The second property of reg is the length, so correct it for timer.
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/sama5d4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 2cc3cfe..0901706 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -940,7 +940,7 @@
pit: timer@fc068630 {
compatible = "atmel,at91sam9260-pit";
- reg = <0xfc068630 0xf>;
+ reg = <0xfc068630 0x10>;
interrupts = <3 IRQ_TYPE_LEVEL_HIGH 5>;
clocks = <>;
};
--
2.1.0.24.g4109c28
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 04/15] drm/dsi: Do not add DSI devices for the child nodes with input-port property
Hi Thierry, On 12/10/2014 08:21 PM, Thierry Reding wrote: On Wed, Dec 10, 2014 at 04:37:17PM +0800, Liu Ying wrote: The MIPI DSI bus driver would try to add a DSI device for a host's every child node which contains the reg property. Unfortunately, the existing i.MX6Q/SDL MIPI DSI host device tree node's child nodes contain the reg There aren't any existing nodes for the DSI host on i.MX. This patch series adds support for them. There are existing nodes for the DSI host node. Please find them in arch/arm/boot/dts/imx6qdl.dtsi and arch/arm/boot/dts/imx6q.dts. The DSI host node contains two child nodes for i.MX6DL and another two for i.MX6Q. Each child node has a reg property embedded. property, but the child nodes are ports pointing to dedicated CRTCs. So, this patch phases out the child nodes with input-port property before adding DSI devices for them and updates the MIPI DSI bus OF binding documentation. Signed-off-by: Liu Ying --- Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 4 drivers/gpu/drm/drm_mipi_dsi.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) Sorry, but NAK. There's no need for this special-case. I'll go into more detail in response to patch 09/15. Thanks for reviewing the patches. Any idea how to handle the special case? The existing child nodes for the DSI host node do have the reg properties embedded. Regards, Liu Ying Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, 3.18] sleeping function called from invalid context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2014 08:53 PM, Andy Lutomirski wrote: > On Wed, Dec 10, 2014 at 5:32 PM, Rik van Riel > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 12/10/2014 07:51 PM, Andy Lutomirski wrote: >>> On Wed, Dec 10, 2014 at 4:49 PM, Rik van Riel >>> wrote: On 12/10/2014 07:46 PM, Daniel J >>> Blueman wrote: >> Gah. I had some non-temporal copy changes in the wrong >> tree. I'll check with a definitely clean tree and follow >> up if it still occurs. >>> >>> The exception handlers should definitely allow sleeping, so I >>> suspect those changes may be related. >>> It would be really, really nice if we could arrange for kernel_fpu_begin to be unconditionally usable in anything except NMI context. The crypto code would be much less scary, we could make non-temporal copies safe, etc. Can we have ponies, too? >> >> Isn't it already? >> >> I see nothing in __kernel_fpu_begin that looks like it would ever >> need to sleep. >> > > It never needs to sleep, but it does need somewhere to save the > previous state. See irq_fpu_usable. > > FWIW, I don't understand what the comments above > interrupted_kernel_fpu_idle are talking about. The issue that I > understand is: > > kernel_fpu_begin() > > irq: kernel_fpu_begin() use xstate kernel_fpu_end() > > we're screwed now :( > > kernel_fpu_end() > > IOW we need somewhere to put the state from the thing we > interrupted. Good point. An interruptible kernel_fpu_begin needs to provide a place to put the state. Alternatively, the one that runs from irq context could provide the place to store the current context, with a kernel_fpu_begin_irq() function... > This gets extra fun if some thread does something that takes a > page fault that uses fpu that gets interrupted, etc. Fortunately, > I think that can't happen -- kernel_fpu_begin disables preemption. > So I think we have a maximum of one active FPU context per thread > plus some number per cpu. Maybe we could have a percpu array of > ten or twenty xstates to handle all possible nesting. > > Also, can we just delete the non-eager code some day? The XSAVEOPT and XRSTOR optimizations do not work across VMENTER and VMEXIT, so with the eager code we end up always loading and saving 384 bytes of state at every context switch, even for tasks that never once touched the FPU. That is 6 cache lines worth of unused stuff for each task involved in the context switch. Somehow I am not convinced that is a good idea... - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUiP0yAAoJEM553pKExN6DD24H/jCcahi8z3LP6JEL4tpJUMpv NIYuAdzdIbns4ycijSqYJSVGxZJEx2c7w8QSrRgTslx6zPfP2Q0MYZQ9J++CJbgQ FZZcbnor6OL/KQtJWnPNSTN0ElBehWo+nZqK4SIbBoAwqJDQpBqo1Me9alxGoZ3P SixN4NAwfDMP3nz0wNGuxV/Hr3/T1Hz5tDYS4226z5yhz84Sd4ODzAuu9NDGANHg 5g08uocMz6lpMlxO2m+bSElDxh6V0J6bqedgxzZbjVZM3zYk+txFw1TwmMSJoHT3 /rUzwfwGmA/8WDNWgSEscUZILJiEZgrGAtWVyJed0IZTg+A7MSqP9y57OXrDD60= =YmP/ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] Thermal: introduce INT3406 thermal driver
On Wed, 2014-12-10 at 18:15 -0800, Olof Johansson wrote: > On Wed, Dec 10, 2014 at 5:02 PM, Aaron Lu wrote: > > On Wed, Dec 10, 2014 at 11:53:25AM -0800, Olof Johansson wrote: > >> Hi, > >> > >> [+daniel vetter] > >> > >> On Mon, Dec 8, 2014 at 9:47 PM, Aaron Lu wrote: > >> > INT3406 ACPI device object resembles an ACPI video output device, but its > >> > _BCM is said to be deprecated and should not be used. So we will make > >> > use of the raw interface to do the actual cooling. Due to this, the > >> > backlight core has some modifications. Also, to re-use some of the ACPI > >> > video module's code, one function has been exported. > >> > > >> > Signed-off-by: Aaron Lu > >> > Signed-off-by: Zhang Rui > >> > --- > >> > v5: > >> > Add the missing file drivers/thermal/int340x_thermal/Kconfig > >> > Remove the assignment of .owner field from the device_driver structure > >> > >> > >> Did this patch show up in -next for the first time last night, or did > >> some other change break this? > >> > >> It causes a panic in i915 when booting Minnowboard Max for me. > > > > Sorry for the trouble, I'm looking at this now. > > Is there anything special about the Minnowboard Max? I'll try to > > reproduce the issue here locally with a typical Intel desktop. > > Another good question is why the code showed up in -next today. Code > going in for 3.19 is supposed to have been baking there already, and > it's too early to stage anything for 3.20. > > Zhang? well, my Linux machine happened to be broken when I was in travel in Oct and Nov, so that I got the 3.19 material prepared a little late. Thus I just took some fixes and driver specific patches and plan to push my pull request next week. For this one, it had been pushed to linux-next for 3.18, but was dropped because of some Kconfig problem. So I thought it was safe to include this one for 3.19. sorry for bring the trouble here. Now my intention is to see if we can have this problem fixed by this Fri. If not, I will drop it for 3.19. is it okay for you? thanks, rui > > > Is it the next/master branch? > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > Yes. But I've confirmed that it happens with Zhang's next branch too > without the rest of linux-next. > > > -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: mce: Avoid timer double-add during CMCI interrupt storms.
On Wednesday 12/10 at 20:23 +0100, Borislav Petkov wrote:
> On Tue, Dec 09, 2014 at 07:11:02PM -0800, Calvin Owens wrote:
> > Just to make sure I understand what you're looking for:
> >
> > When MCE is initialized, spawn a kthread for each CPU instead of the
> > current timers. If CMCI is supported, we just leave this thread parked,
> > and only process errors from the CMCI interrupt handler.
> >
> > When a CMCI storm happens, we disable CMCI interrupts and kick the
> > kthread, which polls every HZ/100 until the storm has subsided, at which
> > point it re-enables CMCI interrupts and parks itself.
> >
> > If CMCI isn't supported though, how is the polling done? You said the
> > dynamic interval is desirable, wouldn't that need to be in the kthread?
> > Having both the kthread and the timer around seems ugly, even if only
> > one is used on a given machine.
>
> Ok, so in talking with the guys here internally it sounds to me like
> a kernel thread or a workqueue or whatever other facility relying on
> wake_up_process() we take, would have scheduling latency in there and
> get delayed when polling the MCA banks. In a storm condition, this might
> not be such a good idea.
>
> So we maybe better off with the timer interrupt after all but try
> to decouple the dynamic adjusting of polling frequency for non-CMCI
> machines and do an on/off simpler polling on CMCI machines.
>
> So what I'm thinking of is:
>
> * once we've detected CMCI storm, we immediately start polling with
> CMCI_STORM_INTERVAL, i.e. once per second.
>
> * as long as we keep seeing errors during polling in storm mode, we keep
> that polling frequency.
>
> * the moment we don't see any errors anymore, we go to
> CMCI_STORM_SUBSIDED and then eventually to CMCI_STORM_NONE.
>
> The code remains unchanged for CMCI machines which are not in storm
> mode and for non-CMCI machines.
>
> Anyway, this below is completely untested but it seems simpler to me and
> does away with the adaptive logic for CMCI storms (you might want to
> apply it first as the diff is hardly readable and this code is nasty as
> hell anyway).
>
> Thoughts?
This doens't fix the original issue though: the timer double-add can
still happen if the CMCI interrupt that hits the STORM threshold pops
off during mce_timer_fn() and calls mce_timer_kick().
The polling is unnecessary on a CMCI-capable machine except in STORMs,
right? Wouldn't it be better to eliminate it in that case?
That said, I ran mce-test with your patch on top of 3.18, looks good
there. But that doesn't simulate CMCI interrupts.
Thanks,
Calvin
> ---
> diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
> index 51b26e895933..1b9733614e4c 100644
> --- a/arch/x86/include/asm/mce.h
> +++ b/arch/x86/include/asm/mce.h
> @@ -108,6 +108,7 @@ struct mca_config {
> bool disabled;
> bool ser;
> bool bios_cmci_threshold;
> + bool cmci;
> u8 banks;
> s8 bootlog;
> int tolerant;
> diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h
> b/arch/x86/kernel/cpu/mcheck/mce-internal.h
> index 10b46906767f..6e4984fc37ce 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
> +++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
> @@ -30,18 +30,19 @@ extern struct mce_bank *mce_banks;
> extern mce_banks_t mce_banks_ce_disabled;
>
> #ifdef CONFIG_X86_MCE_INTEL
> -unsigned long mce_intel_adjust_timer(unsigned long interval);
> +unsigned long cmci_intel_adjust_timer(unsigned long interval);
> void mce_intel_cmci_poll(void);
> void mce_intel_hcpu_update(unsigned long cpu);
> void cmci_disable_bank(int bank);
> #else
> -# define mce_intel_adjust_timer mce_adjust_timer_default
> +# define cmci_intel_adjust_timer mce_adjust_timer_default
> static inline void mce_intel_cmci_poll(void) { }
> static inline void mce_intel_hcpu_update(unsigned long cpu) { }
> static inline void cmci_disable_bank(int bank) { }
> #endif
>
> void mce_timer_kick(unsigned long interval);
> +int ce_error_seen(void);
>
> #ifdef CONFIG_ACPI_APEI
> int apei_write_mce(struct mce *m);
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index d2c611699cd9..e3f426698164 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1324,7 +1324,7 @@ static unsigned long mce_adjust_timer_default(unsigned
> long interval)
> static unsigned long (*mce_adjust_timer)(unsigned long interval) =
> mce_adjust_timer_default;
>
> -static int cmc_error_seen(void)
> +int ce_error_seen(void)
> {
> unsigned long *v = this_cpu_ptr(_polled_error);
>
> @@ -1334,36 +1334,36 @@ static int cmc_error_seen(void)
> static void mce_timer_fn(unsigned long data)
> {
> struct timer_list *t = this_cpu_ptr(_timer);
> + int cpu = smp_processor_id();
> unsigned long iv;
> - int notify;
>
> - WARN_ON(smp_processor_id() != data);
> + WARN_ON(cpu != data);
>
> if
Re: linux-next: build failure after merge of the vfs tree
On Wed, Dec 10, 2014 at 06:45:37PM +1100, Stephen Rothwell wrote: > Hi Al, > > After merging the vfs tree, today's linux-next build (powerpc > allnoconfig) failed like this: > diff --git a/fs/nsfs.c b/fs/nsfs.c > index 0791d086804d..7d98db03c2ce 100644 > --- a/fs/nsfs.c > +++ b/fs/nsfs.c > @@ -3,6 +3,8 @@ > #include > #include > #include > +#include > +#include Umm... Either it's time.h + timekeeping.h or ktime.h alone - ktime.h pulls timekeeping.h and time.h. For now I went with the latter variant. However, I wonder if longer term it would be better to provide a variant of new_inode_pseudo() that would set the timestamps that way - only two callers (new_inode() and sock_alloc()) do not do exactly that. Oh, well - that can wait... For now, fixed and force-pushed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT pull] x86 mpx support for 3.19
On 12/10/2014 06:14 PM, Eric W. Biederman wrote: > Thomas Gleixner writes: >> please pull the latest x86-mpx-for-linus git tree from: >> >>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git >> x86-mpx-for-linus >> >> This enables support for x86 MPX: >> >> MPX is a new debug feature for bound checking in user space. It >> requires kernel support to handle the bound tables and decode the >> bound violating instruction in the trap handler. > > I some really dumb questions. > > Given that mpx is both architecture and cpu specific why use prctl? > I would think arch_prctl would be a much more appropriate place to > expose this logic. I actually never considered arch_prctl(). It doesn't seem a bad fit for any reason, just that I never thought of it and no one suggested it up to this point. Is there any *real* advantage to arch_prctl()? We have some gcc code that's going to be using these prctls and if we need to change the interface, we've got to get that code changed too... fast. > Why don't you have a call to let an application query to see if mpx > management is enabled? I am trying to imagine how checkpoint/restart is > going to be supported for mpx applications. If I can't even query if > mpx is enabled I don't have a clue how we could save this state and > duplicate it in another process on another machine. You probably need to actually save off the contents of mm->bd_addr itself. I guess you can do it along with all the other internals of the mm that get saved off currently. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] extcon: Remove duplicated include from extcon-class.c
Hi Wei, On 12/09/2014 10:08 AM, weiyj...@163.com wrote: > From: Wei Yongjun > > Remove duplicated include. > > Signed-off-by: Wei Yongjun > --- > drivers/extcon/extcon-class.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c > index 043dcd9..8319f25 100644 > --- a/drivers/extcon/extcon-class.c > +++ b/drivers/extcon/extcon-class.c > @@ -32,7 +32,6 @@ > #include > #include > #include > -#include > > /* > * extcon_cable_name suggests the standard cable names for commonly used > > I'll apply it on extcon-next branch. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] Thermal: introduce INT3406 thermal driver
On Wed, Dec 10, 2014 at 6:17 PM, Aaron Lu wrote: > On 12/11/2014 10:15 AM, Olof Johansson wrote: >> On Wed, Dec 10, 2014 at 5:02 PM, Aaron Lu wrote: >>> On Wed, Dec 10, 2014 at 11:53:25AM -0800, Olof Johansson wrote: Hi, [+daniel vetter] On Mon, Dec 8, 2014 at 9:47 PM, Aaron Lu wrote: > INT3406 ACPI device object resembles an ACPI video output device, but its > _BCM is said to be deprecated and should not be used. So we will make > use of the raw interface to do the actual cooling. Due to this, the > backlight core has some modifications. Also, to re-use some of the ACPI > video module's code, one function has been exported. > > Signed-off-by: Aaron Lu > Signed-off-by: Zhang Rui > --- > v5: > Add the missing file drivers/thermal/int340x_thermal/Kconfig > Remove the assignment of .owner field from the device_driver structure Did this patch show up in -next for the first time last night, or did some other change break this? It causes a panic in i915 when booting Minnowboard Max for me. >>> >>> Sorry for the trouble, I'm looking at this now. >>> Is there anything special about the Minnowboard Max? I'll try to >>> reproduce the issue here locally with a typical Intel desktop. >> >> Another good question is why the code showed up in -next today. Code >> going in for 3.19 is supposed to have been baking there already, and >> it's too early to stage anything for 3.20. >> >> Zhang? >> >>> Is it the next/master branch? >>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git >> >> Yes. But I've confirmed that it happens with Zhang's next branch too >> without the rest of linux-next. > > Can you please give me your kernel config file too? http://arm-soc.lixom.net/minnowmax_defconfig -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCHv2 4/7] devfreq: event: Add exynos-ppmu devfreq event driver
Hi Krzysztof,
On 12/10/2014 06:59 PM, Krzysztof Kozlowski wrote:
> On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote:
>> This patch add exynos-ppmu devfreq event driver to provider raw data about
>> the utilization of each IP in Exynos SoC series.
>>
>> Cc: MyungJoo Ham
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>> ---
>> drivers/devfreq/Kconfig | 9 +
>> drivers/devfreq/event/Makefile | 1 +
>> drivers/devfreq/event/exynos-ppmu.c | 409
>>
>> 3 files changed, 419 insertions(+)
>> create mode 100644 drivers/devfreq/event/exynos-ppmu.c
>
> I would rather see this as an incremental change for existing
> exynos_ppmu.c file. However I do not insists on that.
>
>>
>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>> index 4d15b62..d4559f7 100644
>> --- a/drivers/devfreq/Kconfig
>> +++ b/drivers/devfreq/Kconfig
>> @@ -89,4 +89,13 @@ config ARM_EXYNOS5_BUS_DEVFREQ
>>
>> comment "DEVFREQ Event Drivers"
>>
>> +config DEVFREQ_EVENT_EXYNOS_PPMU
>> +bool "EXYNOS PPMU (Performance Profiling Monitoring Unit) DEVFREQ event
>> Driver"
>> +depends on ARCH_EXYNOS
>> +select PM_OPP
>> +help
>> + This add the DEVFREQ event driver for Exynos SoC. It provides PPMU
>> + (Performance Profiling Monitoring Unit) counters to estimate the
>> + utilization of each module.
>> +
>> endif # PM_DEVFREQ
>> diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
>> index dc56005..be146ea 100644
>> --- a/drivers/devfreq/event/Makefile
>> +++ b/drivers/devfreq/event/Makefile
>> @@ -1 +1,2 @@
>> # Exynos DEVFREQ Event Drivers
>> +obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
>> diff --git a/drivers/devfreq/event/exynos-ppmu.c
>> b/drivers/devfreq/event/exynos-ppmu.c
>> new file mode 100644
>> index 000..2706f23
>> --- /dev/null
>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>> @@ -0,0 +1,409 @@
>> +/*
>> + * exynos_ppmu.c - EXYNOS PPMU (Performance Profiling Monitoring Units)
>> support
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * Author : Chanwoo Choi
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This driver is based on drivers/devfreq/exynos/exynos_ppmu.c
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define PPMU_ENABLE BIT(0)
>> +#define PPMU_DISABLE0x0
>> +#define PPMU_CYCLE_RESETBIT(1)
>> +#define PPMU_COUNTER_RESET BIT(2)
>> +
>> +#define PPMU_ENABLE_COUNT0 BIT(0)
>> +#define PPMU_ENABLE_COUNT1 BIT(1)
>> +#define PPMU_ENABLE_COUNT2 BIT(2)
>> +#define PPMU_ENABLE_COUNT3 BIT(3)
>> +#define PPMU_ENABLE_CYCLE BIT(31)
>> +
>> +#define PPMU_CNTENS 0x10
>> +#define PPMU_FLAG 0x50
>> +#define PPMU_CCNT_OVERFLOW BIT(31)
>> +#define PPMU_CCNT 0x100
>> +
>> +#define PPMU_PMCNT0 0x110
>> +#define PPMU_PMCNT_OFFSET 0x10
>> +#define PMCNT_OFFSET(x) (PPMU_PMCNT0 + (PPMU_PMCNT_OFFSET * x))
>> +
>> +#define PPMU_BEVT0SEL 0x1000
>> +#define PPMU_BEVTSEL_OFFSET 0x100
>> +#define PPMU_BEVTSEL(x) (PPMU_BEVT0SEL + (x *
>> PPMU_BEVTSEL_OFFSET))
>> +
>> +#define RD_DATA_COUNT 0x5
>> +#define WR_DATA_COUNT 0x6
>> +#define RDWR_DATA_COUNT 0x7
>> +
>> +enum ppmu_counter {
>> +PPMU_PMNCNT0,
>> +PPMU_PMNCNT1,
>> +PPMU_PMNCNT2,
>> +PPMU_PMNCNT3,
>> +PPMU_PMNCNT_MAX,
>> +};
>> +
>> +/* Platform data */
>> +struct exynos_ppmu_data {
>> +struct devfreq *devfreq;
>
> Looks like not used here.
Right. I'll remove it.
>
>> +struct devfreq_event_dev **event_dev;
>> +struct devfreq_event_desc *desc;
>> +unsigned int num_events;
>> +
>> +struct device *dev;
>> +struct clk *clk_ppmu;
>> +struct mutex lock;
>> +
>> +struct __exynos_ppmu {
>> +void __iomem *hw_base;
>> +unsigned int ccnt;
>> +unsigned int event[PPMU_PMNCNT_MAX];
>> +unsigned int count[PPMU_PMNCNT_MAX];
>> +unsigned long long ns;
>> +ktime_t reset_time;
>> +bool ccnt_overflow;
>> +bool count_overflow[PPMU_PMNCNT_MAX];
>> +} ppmu;
>> +};
>> +
>> +struct __exynos_ppmu_events {
>> +char *name;
>> +int id;
>> +} ppmu_events[] = {
>> +{ "ppmu-dmc0-pmcnt0", PPMU_PMNCNT0 },
>> +{ "ppmu-dmc0-pmcnt1", PPMU_PMNCNT1 },
>> +{ "ppmu-dmc0-pmcnt2", PPMU_PMNCNT2 },
>> +{ "ppmu-dmc0-pmcnt3", PPMU_PMNCNT3 },
>> +
>> +{ "ppmu-dmc1-pmcnt0", PPMU_PMNCNT0 },
>> +{ "ppmu-dmc1-pmcnt1", PPMU_PMNCNT1 },
>> +{ "ppmu-dmc1-pmcnt2", PPMU_PMNCNT2 },
>> +{ "ppmu-dmc1-pmcnt3", PPMU_PMNCNT3 },
>> +
>> +{
Re: [PATCH v5] Thermal: introduce INT3406 thermal driver
On 12/11/2014 10:15 AM, Olof Johansson wrote: > On Wed, Dec 10, 2014 at 5:02 PM, Aaron Lu wrote: >> On Wed, Dec 10, 2014 at 11:53:25AM -0800, Olof Johansson wrote: >>> Hi, >>> >>> [+daniel vetter] >>> >>> On Mon, Dec 8, 2014 at 9:47 PM, Aaron Lu wrote: INT3406 ACPI device object resembles an ACPI video output device, but its _BCM is said to be deprecated and should not be used. So we will make use of the raw interface to do the actual cooling. Due to this, the backlight core has some modifications. Also, to re-use some of the ACPI video module's code, one function has been exported. Signed-off-by: Aaron Lu Signed-off-by: Zhang Rui --- v5: Add the missing file drivers/thermal/int340x_thermal/Kconfig Remove the assignment of .owner field from the device_driver structure >>> >>> >>> Did this patch show up in -next for the first time last night, or did >>> some other change break this? >>> >>> It causes a panic in i915 when booting Minnowboard Max for me. >> >> Sorry for the trouble, I'm looking at this now. >> Is there anything special about the Minnowboard Max? I'll try to >> reproduce the issue here locally with a typical Intel desktop. > > Another good question is why the code showed up in -next today. Code > going in for 3.19 is supposed to have been baking there already, and > it's too early to stage anything for 3.20. > > Zhang? > >> Is it the next/master branch? >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > Yes. But I've confirmed that it happens with Zhang's next branch too > without the rest of linux-next. Can you please give me your kernel config file too? Thanks, Aaron > > > -Olof > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT pull] x86 mpx support for 3.19
Thomas Gleixner writes: > Linus, > > please pull the latest x86-mpx-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mpx-for-linus > > This enables support for x86 MPX: > > MPX is a new debug feature for bound checking in user space. It > requires kernel support to handle the bound tables and decode the > bound violating instruction in the trap handler. I some really dumb questions. Given that mpx is both architecture and cpu specific why use prctl? I would think arch_prctl would be a much more appropriate place to expose this logic. Why don't you have a call to let an application query to see if mpx management is enabled? I am trying to imagine how checkpoint/restart is going to be supported for mpx applications. If I can't even query if mpx is enabled I don't have a clue how we could save this state and duplicate it in another process on another machine. > +Adding new prctl commands > +- > + > +Two new prctl commands are added to enable and disable MPX bounds tables > +management in kernel. > + > +155 #define PR_MPX_ENABLE_MANAGEMENT43 > +156 #define PR_MPX_DISABLE_MANAGEMENT 44 > + > +Runtime library in userspace is responsible for allocation of bounds > +directory. So kernel have to use XSAVE instruction to get the base > +of bounds directory from BNDCFG register. > + > +But XSAVE is expected to be very expensive. In order to do performance > +optimization, we have to get the base of bounds directory and save it > +into struct mm_struct to be used in future during PR_MPX_ENABLE_MANAGEMENT > +command execution. > + Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] Thermal: introduce INT3406 thermal driver
On Wed, Dec 10, 2014 at 5:02 PM, Aaron Lu wrote: > On Wed, Dec 10, 2014 at 11:53:25AM -0800, Olof Johansson wrote: >> Hi, >> >> [+daniel vetter] >> >> On Mon, Dec 8, 2014 at 9:47 PM, Aaron Lu wrote: >> > INT3406 ACPI device object resembles an ACPI video output device, but its >> > _BCM is said to be deprecated and should not be used. So we will make >> > use of the raw interface to do the actual cooling. Due to this, the >> > backlight core has some modifications. Also, to re-use some of the ACPI >> > video module's code, one function has been exported. >> > >> > Signed-off-by: Aaron Lu >> > Signed-off-by: Zhang Rui >> > --- >> > v5: >> > Add the missing file drivers/thermal/int340x_thermal/Kconfig >> > Remove the assignment of .owner field from the device_driver structure >> >> >> Did this patch show up in -next for the first time last night, or did >> some other change break this? >> >> It causes a panic in i915 when booting Minnowboard Max for me. > > Sorry for the trouble, I'm looking at this now. > Is there anything special about the Minnowboard Max? I'll try to > reproduce the issue here locally with a typical Intel desktop. Another good question is why the code showed up in -next today. Code going in for 3.19 is supposed to have been baking there already, and it's too early to stage anything for 3.20. Zhang? > Is it the next/master branch? > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Yes. But I've confirmed that it happens with Zhang's next branch too without the rest of linux-next. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCHv2 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Hi Krzysztof, First of all, thanks for your review. On 12/10/2014 06:37 PM, Krzysztof Kozlowski wrote: > On wto, 2014-12-09 at 23:13 +0900, Chanwoo Choi wrote: >> This patch add new devfreq_event class for devfreq_event device which provide >> raw data (e.g., memory bus utilization/GPU utilization). This raw data from >> devfreq_event data would be used for the governor of devfreq subsystem. >> - devfreq_event device : Provide raw data for governor of existing devfreq >> device >> - devfreq device : Monitor device state and change frequency/voltage >> of device >> using the raw data from devfreq_event device >> >> The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) >> for Non-CPU Devices. The devfreq device would dertermine current device state >> using various governor (e.g., ondemand, performance, powersave). After >> completed >> determination of system state, devfreq device would change the >> frequency/voltage >> of devfreq device according to the result of governor. >> >> But, devfreq governor must need basic data which indicates current device >> state. >> Existing devfreq subsystem only consider devfreq device which check current >> system >> state and determine proper system state using basic data. There is no >> subsystem >> for device providing basic data to devfreq device. >> >> The devfreq subsystem must need devfreq_event device(data-provider device) >> for >> existing devfreq device. So, this patch add new devfreq_event class for >> devfreq_event device which read various basic data(e.g, memory bus >> utilization, >> GPU utilization) and provide measured data to existing devfreq device through >> standard APIs of devfreq_event class. >> >> The following description explains the feature of two kind of devfreq class: >> - devfreq class (existing) >> : devfreq consumer device use raw data from devfreq_event device for >>determining proper current system state and change voltage/frequency >>dynamically using various governors. >> >> - devfreq_event class (new) >> : Provide measured raw data to devfreq device for governor >> >> Cc: MyungJoo Ham >> Cc: Kyungmin Park >> Signed-off-by: Chanwoo Choi >> --- >> drivers/devfreq/Kconfig | 2 + >> drivers/devfreq/Makefile| 5 +- >> drivers/devfreq/devfreq-event.c | 302 >> >> drivers/devfreq/event/Makefile | 1 + >> include/linux/devfreq.h | 141 +++ >> 5 files changed, 450 insertions(+), 1 deletion(-) >> create mode 100644 drivers/devfreq/devfreq-event.c >> create mode 100644 drivers/devfreq/event/Makefile >> >> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >> index faf4e70..4d15b62 100644 >> --- a/drivers/devfreq/Kconfig >> +++ b/drivers/devfreq/Kconfig >> @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ >>It reads PPMU counters of memory controllers and adjusts the >>operating frequencies and voltages with OPP support. >> >> +comment "DEVFREQ Event Drivers" >> + >> endif # PM_DEVFREQ >> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile >> index 16138c9..a1ffabe 100644 >> --- a/drivers/devfreq/Makefile >> +++ b/drivers/devfreq/Makefile >> @@ -1,4 +1,4 @@ >> -obj-$(CONFIG_PM_DEVFREQ)+= devfreq.o >> +obj-$(CONFIG_PM_DEVFREQ)+= devfreq.o devfreq-event.o >> obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) += governor_simpleondemand.o >> obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o >> obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o >> @@ -7,3 +7,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o >> # DEVFREQ Drivers >> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/ >> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/ >> + >> +# DEVFREQ Event Drivers >> +obj-$(CONFIG_PM_DEVFREQ)+= event/ >> diff --git a/drivers/devfreq/devfreq-event.c >> b/drivers/devfreq/devfreq-event.c >> new file mode 100644 >> index 000..b47329f >> --- /dev/null >> +++ b/drivers/devfreq/devfreq-event.c >> @@ -0,0 +1,302 @@ >> +/* >> + * devfreq-event: Generic DEVFREQ Event class driver >> + * >> + * Copyright (C) 2014 Samsung Electronics >> + * Chanwoo Choi >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * This driver is based on drivers/devfreq/devfreq.c >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include "governor.h" >> + >> +static struct class *devfreq_event_class; >> + >> +/* The list of all devfreq event list */ >> +static LIST_HEAD(devfreq_event_list); >> +static DEFINE_MUTEX(devfreq_event_list_lock);
Re: [PATCH V3 1/1] Drivers: hv: vmbus: Fix a bug in vmbus_establish_gpadl()
K. Y. Srinivasan, On Wed, Dec 10, 2014 at 05:13:00PM -0800, K. Y. Srinivasan wrote: > Correctly compute the local (gpadl) handle. This description is still too sparse for me. How was it computed before and why was this incorrect? Pretend like you are trying to explain your patch to someone who has no idea what you did. > I would like to thank Michael Brown for seeing this bug. > > Signed-off-by: K. Y. Srinivasan > Reported-by: Michael Brown > --- > Changes in V2: Added the Reported-by tag. > Changes in V3: Cleaned up the commit log. > > drivers/hv/channel.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c > index 433f72a..c76ffbe 100644 > --- a/drivers/hv/channel.c > +++ b/drivers/hv/channel.c > @@ -366,8 +366,8 @@ int vmbus_establish_gpadl(struct vmbus_channel *channel, > void *kbuffer, > unsigned long flags; > int ret = 0; > > - next_gpadl_handle = atomic_read(_connection.next_gpadl_handle); > - atomic_inc(_connection.next_gpadl_handle); > + next_gpadl_handle = > + (atomic_inc_return(_connection.next_gpadl_handle) - 1); > Tell me if I understand this correctly. Before it read the handle and incremented it. y = x + 1 Now it reads the handle, increments it, then decrements it. y = (x + 1) - 1 = x > ret = create_gpadl_header(kbuffer, size, , ); > if (ret) > -- > 1.7.4.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - Jeremiah Mahler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] net: introduce helper macro for_each_cmsghdr
Hi David, On 12/11/2014 09:47 AM, David Miller wrote: > From: Gu Zheng > Date: Thu, 11 Dec 2014 09:05:59 +0800 > >> IMO, the user-land programs need to be build with the matched >> headers separately. > > You absolutely cannot provide this new interface to userland and > expect programs to be able to just use it, it's non-standard and does > not exist in older headers. Got it, sorry for my mistake, and thanks for your correction. > > I do not want this new interface available to userland programs. > They can just open-code the list traversal just like every program > in history has had to do since BSD UNIX. Agree. Let's leave the user-land ones as they are. I'll send a new version (without changing user-land ones) soon. Best regards, Gu > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/apic] x86, PCI, ACPI: Kill private function resource_to_addr() in arch/x86/pci/acpi.c
On Wed, Dec 10, 2014 at 4:35 PM, Borislav Petkov wrote: > On Wed, Dec 10, 2014 at 04:31:22PM -0800, Yinghai Lu wrote: >> > 2) Send patches inline. It's a pain to review and reply and I can't >> >use my normal tooling. >> >> I can not, as gmail does not allow that. > > Lemme guess, this is some kind of a joke you're making, right? I am using yhlu.ker...@gmail.com to send as ying...@kernel.org. Tried with mutt or thunderbird etc, all kept on downloading so have to stuck with the gmail web gui. and it does not allow insert plain text in the mail. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next RESEND 2/2] ipv6: fix sparse warning
On 12/11/2014 12:04 AM, Paul E. McKenney wrote: > On Wed, Dec 10, 2014 at 04:46:07PM +0800, Ying Xue wrote: >> This fixes the following spare warning when using >> >> make C=1 CF=-D__CHECK_ENDIAN__ net/ipv6/addrconf.o >> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison >> expression (different address spaces) >> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison >> expression (different address spaces) >> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison >> expression (different address spaces) >> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison >> expression (different address spaces) >> >> To silence above spare complaint, an RCU annotation should be added >> to "next" pointer of hlist_node structure through hlist_next_rcu() >> macro when iterating over a hlist with >> hlist_for_each_entry_continue_rcu_bh(). >> >> By the way, this commit also resolves the same error appearing in >> hlist_for_each_entry_continue_rcu(). >> >> Signed-off-by: Ying Xue > > If you pull the rculist.h changes from the first patch into this one, > I will queue it up through -rcu. > Please just queue this patch into your RCU tree. Some changes of the first patch currently only exists in net-next tree, so it cannot be merged into RCU tree now. Therefore, please temporarily ignore it. In next 3.19 development cycle, I will resubmit it to you. Thanks, Ying > Thanx, Paul > >> --- >> include/linux/rculist.h | 16 >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/include/linux/rculist.h b/include/linux/rculist.h >> index 866d9c9..32bd4ad 100644 >> --- a/include/linux/rculist.h >> +++ b/include/linux/rculist.h >> @@ -524,11 +524,11 @@ static inline void hlist_add_behind_rcu(struct >> hlist_node *n, >> * @member: the name of the hlist_node within the struct. >> */ >> #define hlist_for_each_entry_continue_rcu(pos, member) >> \ >> -for (pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\ >> -typeof(*(pos)), member);\ >> +for (pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \ >> +&(pos)->member)), typeof(*(pos)), member); \ >> pos; \ >> - pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\ >> -typeof(*(pos)), member)) >> + pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \ >> +&(pos)->member)), typeof(*(pos)), member)) >> >> /** >> * hlist_for_each_entry_continue_rcu_bh - iterate over a hlist continuing >> after current point >> @@ -536,11 +536,11 @@ static inline void hlist_add_behind_rcu(struct >> hlist_node *n, >> * @member: the name of the hlist_node within the struct. >> */ >> #define hlist_for_each_entry_continue_rcu_bh(pos, member) \ >> -for (pos = hlist_entry_safe(rcu_dereference_bh((pos)->member.next),\ >> -typeof(*(pos)), member);\ >> +for (pos = hlist_entry_safe(rcu_dereference_bh(hlist_next_rcu( \ >> +&(pos)->member)), typeof(*(pos)), member); \ >> pos; \ >> - pos = hlist_entry_safe(rcu_dereference_bh((pos)->member.next),\ >> -typeof(*(pos)), member)) >> + pos = hlist_entry_safe(rcu_dereference_bh(hlist_next_rcu( \ >> +&(pos)->member)), typeof(*(pos)), member)) >> >> /** >> * hlist_for_each_entry_from_rcu - iterate over a hlist continuing from >> current point >> -- >> 1.7.9.5 >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 09/22] [SCSI] mpt2sas, mpt3sas: Added a support to set cpu affinity for each MSIX vector enabled by the HBA
> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Sreekanth Reddy > Sent: Tuesday, 09 December, 2014 6:17 AM > To: martin.peter...@oracle.com; j...@kernel.org; h...@infradead.org ... > Change_set: > 1. Added affinity_hint varable of type cpumask_var_t in adapter_reply_queue >structure. And allocated a memory for this varable by calling > zalloc_cpumask_var. > 2. Call the API irq_set_affinity_hint for each MSIx vector to affiniate it >with calculated cpus at driver inilization time. > 3. While freeing the MSIX vector, call this same API to release the cpu > affinity mask >for each MSIx vector by providing the NULL value in cpumask argument. > 4. then call the free_cpumask_var API to free the memory allocated in step 2. > ... > diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c > b/drivers/scsi/mpt3sas/mpt3sas_base.c > index 1560115..f0f8ba0 100644 > --- a/drivers/scsi/mpt3sas/mpt3sas_base.c > +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c ... > @@ -1609,6 +1611,10 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 > index, u32 vector) > reply_q->ioc = ioc; > reply_q->msix_index = index; > reply_q->vector = vector; > + > + if (!zalloc_cpumask_var(_q->affinity_hint, GFP_KERNEL)) > + return -ENOMEM; I think this will create the problem Alex Thorlton just reported with lpfc on a system with a huge number (6144) of CPUs. See this thread: [BUG] kzalloc overflow in lpfc driver on 6k core system --- Rob ElliottHP Server Storage -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, 3.18] sleeping function called from invalid context
On Wed, Dec 10, 2014 at 5:32 PM, Rik van Riel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/10/2014 07:51 PM, Andy Lutomirski wrote: >> On Wed, Dec 10, 2014 at 4:49 PM, Rik van Riel >> wrote: On 12/10/2014 07:46 PM, Daniel J Blueman wrote: > Gah. I had some non-temporal copy changes in the wrong tree. > I'll check with a definitely clean tree and follow up if it > still occurs. >> >> The exception handlers should definitely allow sleeping, so I >> suspect those changes may be related. >> >>> It would be really, really nice if we could arrange for >>> kernel_fpu_begin to be unconditionally usable in anything except >>> NMI context. The crypto code would be much less scary, we could >>> make non-temporal copies safe, etc. Can we have ponies, too? > > Isn't it already? > > I see nothing in __kernel_fpu_begin that looks like it would > ever need to sleep. > It never needs to sleep, but it does need somewhere to save the previous state. See irq_fpu_usable. FWIW, I don't understand what the comments above interrupted_kernel_fpu_idle are talking about. The issue that I understand is: kernel_fpu_begin() irq: kernel_fpu_begin() use xstate kernel_fpu_end() we're screwed now :( kernel_fpu_end() IOW we need somewhere to put the state from the thing we interrupted. This gets extra fun if some thread does something that takes a page fault that uses fpu that gets interrupted, etc. Fortunately, I think that can't happen -- kernel_fpu_begin disables preemption. So I think we have a maximum of one active FPU context per thread plus some number per cpu. Maybe we could have a percpu array of ten or twenty xstates to handle all possible nesting. Also, can we just delete the non-eager code some day? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [net: sock] BUG: unable to handle kernel NULL pointer dereference at 0000000000000007
On Wed, Dec 10, 2014 at 03:51:33PM -0800, Alexei Starovoitov wrote: > On Wed, Dec 10, 2014 at 3:29 PM, Fengguang Wu wrote: > > Greetings, > > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > > > net: sock: allow eBPF programs to be attached to sockets > > > [init] Kernel was tainted on startup. Will ignore flags that are already > > set. > > [init] Started watchdog process, PID is 9354 > > [main] Main thread is alive. > > [ 21.233581] BUG: unable to handle kernel NULL pointer dereference at > > 0007 > > [ 21.234709] IP: [] sk_attach_bpf+0x39/0xc2 > > thanks for the report! syscall fuzzer is great. > I missed an extra check. Working on a fix. This might be the first time I've seen it trip up the bpf code iirc. Daniel wrote some pretty nifty bpf generator code in trinity, (net/bpf.c) that you might want to see if you can think of enhancing. Though it might be the case that we're not even needing to do anything that complicated to hit this particular bug.. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] net: introduce helper macro for_each_cmsghdr
From: Gu Zheng Date: Thu, 11 Dec 2014 09:05:59 +0800 > IMO, the user-land programs need to be build with the matched > headers separately. You absolutely cannot provide this new interface to userland and expect programs to be able to just use it, it's non-standard and does not exist in older headers. I do not want this new interface available to userland programs. They can just open-code the list traversal just like every program in history has had to do since BSD UNIX. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: add MAX3355 driver
Hi Sergei,
I reviewed this patch quickly. This driver has just two gpio without any
registers for IP.
I wonder whether MAX3355E is separate chip to detect external connector or just
use gpio of AP.
Could you send the datasheet of MAX3355E to me?
Thanks,
Chanwoo Choi
On 12/11/2014 08:28 AM, Sergei Shtylyov wrote:
> MAX3355E chip integrates a charge pump and comparators to enable a system with
> an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> device. In addition to sensing/controlling Vbus, the chip also passes thru the
> ID signal from the USB OTG connector. On some Renesas boards, this signal is
> just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
> host and gadget USB controllers sharing the same USB bus; however, we'd like
> to allow host or gadget drivers to be loaded depending on the cable type,
> hence
> the need for the MAX3355 extcon driver. The Vbus status signals are also wired
> to GPIOs (however, we're not currently intested in them), the OFFVBUS# signal
> is controlled by the host controllers, there's also the SHDN# signal wired to
> GPIO, which should be high for normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
> drivers/extcon/Kconfig |6
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 122
>
> 4 files changed, 150 insertions(+)
>
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +MAX3355 USB OTG chip
> +
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
> +- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpio = < 4 GPIO_ACTIVE_LOW>;
> + maxim,id-gpio = < 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: extcon/drivers/extcon/Kconfig
> ===
> --- extcon.orig/drivers/extcon/Kconfig
> +++ extcon/drivers/extcon/Kconfig
> @@ -45,6 +45,12 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
> detector and switch.
>
> +config EXTCON_MAX3355
> + tristate "MAX3355 USB OTG EXTCON Support"
> + help
> + Say Y here to enable support for the USB host detection by MAX3355
> + OTG USB chip.
> +
> config EXTCON_MAX77693
> tristate "MAX77693 EXTCON Support"
> depends on MFD_MAX77693 && INPUT
> Index: extcon/drivers/extcon/Makefile
> ===
> --- extcon.orig/drivers/extcon/Makefile
> +++ extcon/drivers/extcon/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-
> obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
> obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
> +obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> Index: extcon/drivers/extcon/extcon-max3355.c
> ===
> --- /dev/null
> +++ extcon/drivers/extcon/extcon-max3355.c
> @@ -0,0 +1,122 @@
> +/*
> + * MAX3355 USB OTG chip extcon driver
> + *
> + * Copyright (C) 2014 Cogent Embedded, Inc.
> + * Author: Sergei Shtylyov
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct max3355_data {
> + struct extcon_dev *edev;
> + int id_gpio;
> +};
> +
> +static const char *max3355_cable[] = {
> + [0] = "USB-HOST",
> + NULL,
> +};
> +
> +static irqreturn_t max3355_id_irq(int irq, void *dev_id)
> +{
> + struct max3355_data *data = dev_id;
> + int id = gpio_get_value(data->id_gpio);
> +
> +
