Re: [PATCH 2/4] ARM: multi_v7_defconfig: Enable ACT8865 PMIC driver
Hi Andy, Am Montag, 7. September 2015, 18:49:02 schrieb Andy Yan: > PMIC RK808 used on many rk3288 boards ,such as Popmetal. > It is a MFD with function regulator and RTC. So if you plan to enable > RK808, please also enable CONFIG_RTC_DRV_RK808. I think that could go into a separate patch5 ... enabling CONFIG_RTC_DRV_RK808=m CONFIG_RTC_DRV_HYM8563=m the two rtc types used on all(?) Rockchip boards. So enable the rk808 mfd+regulator here and do the rtcs separately later. > On 2015年09月07日 17:33, Heiko Stübner wrote: > > Hi, > > > > I guess one could rename that to something like > > "ARM: multi_v7_defconfig: Enable regulators used on most rockchip boards" > > > > and as well add > > > > CONFIG_REGULATOR_FAN53555=y > > CONFIG_MFD_RK808=y > > CONFIG_REGULATOR_RK808=y > > > > fan5355 is the driver providing support for the syr82x used on all rk3288 > > boards with an act8846. > > > > Am Sonntag, 6. September 2015, 22:16:04 schrieb Sjoerd Simons: > >> Active Semi act8846 is used as the PMIC on various Rockchip boards, > >> enable the ACT8865 driver to support this. > >> > >> Signed-off-by: Sjoerd Simons > >> > >> --- > >> > >> arch/arm/configs/multi_v7_defconfig | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/arch/arm/configs/multi_v7_defconfig > >> b/arch/arm/configs/multi_v7_defconfig index 25a1d574..7058fef 100644 > >> --- a/arch/arm/configs/multi_v7_defconfig > >> +++ b/arch/arm/configs/multi_v7_defconfig > >> @@ -401,6 +401,7 @@ CONFIG_MFD_TPS65090=y > >> > >> CONFIG_MFD_TPS6586X=y > >> CONFIG_MFD_TPS65910=y > >> CONFIG_REGULATOR_AB8500=y > >> > >> +CONFIG_REGULATOR_ACT8865=y > >> > >> CONFIG_REGULATOR_AS3711=y > >> CONFIG_REGULATOR_AS3722=y > >> CONFIG_REGULATOR_AXP20X=y > > > > ___ > > Linux-rockchip mailing list > > linux-rockc...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-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 v4 07/13] usb: otg: add OTG core
On 07/09/15 10:40, Li Jun wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> The OTG core instantiates the OTG Finite State Machine
>> per OTG controller and manages starting/stopping the
>> host and gadget controllers based on the bus state.
>>
>> It provides APIs for the following tasks
>>
>> - Registering an OTG capable controller
>> - Registering Host and Gadget controllers to OTG core
>> - Providing inputs to and kicking the OTG state machine
>>
>> Signed-off-by: Roger Quadros
>> ---
>> MAINTAINERS |4 +-
>> drivers/usb/Kconfig |2 +-
>> drivers/usb/Makefile |1 +
>> drivers/usb/common/Makefile |3 +-
>> drivers/usb/common/usb-otg.c | 1061
>> ++
>> drivers/usb/common/usb-otg.h | 71 +++
>> drivers/usb/core/Kconfig | 11 +-
>> include/linux/usb/otg.h | 189 +++-
>> 8 files changed, 1321 insertions(+), 21 deletions(-)
>> create mode 100644 drivers/usb/common/usb-otg.c
>> create mode 100644 drivers/usb/common/usb-otg.h
>>
>
> ... ...
>
>> +
>> +/**
>> + * Get OTG device from host or gadget device.
>> + *
>> + * For non device tree boot, the OTG controller is assumed to be
>> + * the parent of the host/gadget device.
>
> This assumption/restriction maybe a problem, as I pointed in your previous
> version, usb_create_hcd() use the passed dev as its dev, but,
> usb_add_gadget_udc() use the passed dev as its parent dev, so often the
> host and gadget don't share the same parent device, at least it doesn't
> apply to chipidea case.
Let's provide a way for OTG driver to provide the OTG core exactly which is
the related host/gadget device.
>
>> + * For device tree boot, the OTG controller is derived from the
>> + * "otg-controller" property.
>> + */
>> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
>> +{
>> +struct device *otg_dev;
>> +
>> +if (!hcd_gcd_dev)
>> +return NULL;
>> +
>> +if (hcd_gcd_dev->of_node) {
>> +struct device_node *np;
>> +struct platform_device *pdev;
>> +
>> +np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
>> + 0);
>> +if (!np)
>> +goto legacy;/* continue legacy way */
>> +
>> +pdev = of_find_device_by_node(np);
>> +of_node_put(np);
>> +if (!pdev) {
>> +dev_err(&pdev->dev, "couldn't get otg-controller
>> device\n");
>> +return NULL;
>> +}
>> +
>> +otg_dev = &pdev->dev;
>> +return otg_dev;
>> +}
>> +
>> +legacy:
>> +/* otg device is parent and must be registered */
>> +otg_dev = hcd_gcd_dev->parent;
>> +if (!usb_otg_get_data(otg_dev))
>> +return NULL;
>> +
>> +return otg_dev;
>> +}
>> +
>
> ... ...
>
>> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
>> +{
>> +struct otg_fsm *fsm = &otgd->fsm;
>> +unsigned long tmouts[NUM_OTG_FSM_TIMERS];
>> +int i;
>> +
>> +/* set default timeouts */
>> +tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
>> +tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
>> +tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
>> +tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
>> +tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
>> +tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
>> +tmouts[B_SE0_SRP] = TB_SE0_SRP;
>> +tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
>> +
>> +/* set controller provided timeouts */
>> +if (timeouts) {
>> +for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
>> +if (timeouts[i])
>> +tmouts[i] = timeouts[i];
>> +}
>> +}
>> +
>> +otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
>> + &fsm->a_wait_vrise_tmout);
>> +otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
>> + &fsm->a_wait_vfall_tmout);
>> +otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
>> + &fsm->a_wait_bcon_tmout);
>> +otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
>> + &fsm->a_aidl_bdis_tmout);
>> +otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
>> + &fsm->a_bidl_adis_tmout);
>> +otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
>> + &fsm->b_ase0_brst_tmout);
>> +
>> +otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
>> + &fsm->b_se0_srp);
>> +otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
>> + &fsm->b_srp_done);
>> +
>> +/* FIXME: what about A_WAIT_ENUM? */
>
> Either you init it as other timers, or you remove all of it, otherwise
> there will be NULL pointer crash.
I want to initialize it but was not sure about the timeout value.
What timeout value I must use?
>
>> +}
>> +
>> +/**
>> + * OTG FSM ops function to ad
Re: [PATCH 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses
Hi There are also many other devices like display and mmc and even the cpu(if the cpu want run a high frequency when boot up)need to get power supply from PMIC, so it is better to load PMIC as early as possible.Built-in is a better choice. On 2015年09月07日 18:24, Sjoerd Simons wrote: On Mon, 2015-09-07 at 11:26 +0200, Javier Martinez Canillas wrote: Hello Sjoerd, On 09/06/2015 10:16 PM, Sjoerd Simons wrote: Enable Rockchip I2C, SPI, PWM, thermal drivers. Builtin are: * I2C as it often controls the pmic. Having I2C as a module will cause more probe deferrals due missing regulators and slow down the boot but it should not cause issues. Or am I missing something? In fact, I think even the PMIC could be built as a module. It could in principle. However as a lot of other drivers do need the regulators provided by the pmic, they'll be deferred until that driver is loaded. So e.g. with the i2c/pmic drivers as a module you cannot boot to an NFS rootfs without using an initramfs. But I don't have a strong opinion on this so patch looks good: Reviewed-by: Javier Martinez Canillas Best regards, -- 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 V8 3/7] perf, record: introduce --freq-perf option
On Thu, Sep 03, 2015 at 08:30:59AM -0400, kan.li...@intel.com wrote:
> From: Kan Liang
>
> To generate the frequency and performance output, perf must sample read
> special events like cycles, ref-cycles, msr/tsc/, msr/aperf/ or
> msr/mperf/.
> With the --freq-perf option, perf record can automatically check and add
> those event into evlist for sampling read.
hum, not sure this is a big or small thing:
[jolsa@ibm-x3650m4-01 perf]$ ./perf record --freq-perf -e cache-misses ls
SNIP
[ perf record: Woken up 13 times to write data ]
[ perf record: Captured and wrote 0.014 MB perf.data (147 samples) ]
[jolsa@ibm-x3650m4-01 perf]$ ./perf report -D
non matching read_format[jolsa@ibm-x3650m4-01 perf]$
jirka
>
> Signed-off-by: Kan Liang
> ---
> tools/perf/Documentation/perf-record.txt | 4
> tools/perf/builtin-record.c | 39
> +++-
> tools/perf/util/session.h| 10
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/Documentation/perf-record.txt
> b/tools/perf/Documentation/perf-record.txt
> index 2e9ce77..3f40712 100644
> --- a/tools/perf/Documentation/perf-record.txt
> +++ b/tools/perf/Documentation/perf-record.txt
> @@ -308,6 +308,10 @@ This option sets the time out limit. The default value
> is 500 ms.
> Record context switch events i.e. events of type PERF_RECORD_SWITCH or
> PERF_RECORD_SWITCH_CPU_WIDE.
>
> +--freq-perf::
> +Add frequency and performance related events to do sample read.
> +These events include cycles, ref-cycles, msr/tsc/, msr/aperf/ and msr/mperf/.
> +
> SEE ALSO
>
> linkperf:perf-stat[1], linkperf:perf-list[1]
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 142eeb3..e87dda3 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -13,7 +13,7 @@
> #include "util/util.h"
> #include "util/parse-options.h"
> #include "util/parse-events.h"
> -
> +#include "util/pmu.h"
> #include "util/callchain.h"
> #include "util/cgroup.h"
> #include "util/header.h"
> @@ -50,6 +50,7 @@ struct record {
> boolno_buildid;
> boolno_buildid_cache;
> longsamples;
> + boolfreq_perf;
> };
>
> static int record__write(struct record *rec, void *bf, size_t size)
> @@ -948,6 +949,35 @@ out_free:
> return ret;
> }
>
> +const char *freq_perf_events[FREQ_PERF_MAX][3] = {
> + { "msr", "tsc", "msr/tsc/" },
> + { "msr", "aperf", "msr/aperf/" },
> + { "msr", "mperf", "msr/mperf/" },
> + { NULL, "cycles", "cycles" },
> + { NULL, "ref-cycles", "ref-cycles" },
> +};
> +
> +static int
> +record_add_freq_perf_events(struct perf_evlist *evlist)
> +{
> + int i;
> + char freq_perf_attrs[100];
> +
> + strcpy(freq_perf_attrs, "{cycles,ref-cycles");
> + for (i = 0; i < FREQ_PERF_MAX; i++) {
> + if ((i == FREQ_PERF_CYCLES) ||
> + (i == FREQ_PERF_REF_CYCLES))
> + continue;
> + if (pmu_have_event(freq_perf_events[i][0],
> freq_perf_events[i][1])) {
> + strcat(freq_perf_attrs, ",");
> + strcat(freq_perf_attrs, freq_perf_events[i][2]);
> + }
> + }
> + strcat(freq_perf_attrs, "}:S");
> +
> + return parse_events(evlist, freq_perf_attrs, NULL);
> +}
> +
> static const char * const __record_usage[] = {
> "perf record [] []",
> "perf record [] -- []",
> @@ -1096,6 +1126,8 @@ struct option __record_options[] = {
> "per thread proc mmap processing timeout in ms"),
> OPT_BOOLEAN(0, "switch-events", &record.opts.record_switch_events,
> "Record context switch events"),
> + OPT_BOOLEAN(0, "freq-perf", &record.freq_perf,
> + "Add frequency and performance related events to do sample
> read."),
> OPT_END()
> };
>
> @@ -1157,6 +1189,11 @@ int cmd_record(int argc, const char **argv, const char
> *prefix __maybe_unused)
> if (rec->no_buildid_cache || rec->no_buildid)
> disable_buildid_cache();
>
> + if (rec->freq_perf && record_add_freq_perf_events(rec->evlist)) {
> + pr_err("Cannot set up freq and performance events\n");
> + goto out_symbol_exit;
> + }
> +
> if (rec->evlist->nr_entries == 0 &&
> perf_evlist__add_default(rec->evlist) < 0) {
> pr_err("Not enough memory for event selector list\n");
> diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
> index b44afc7..3915be7 100644
> --- a/tools/perf/util/session.h
> +++ b/tools/perf/util/session.h
> @@ -42,6 +42,16 @@ struct perf_session {
> #define PRINT_IP_OPT_ONELINE (1<<4)
> #define PRINT_IP_OPT_SRCLINE (1<<5)
>
> +enum perf_freq_perf_index {
> + FREQ_PERF_TSC = 0,
> + FREQ_PERF_APERF = 1,
> + FREQ_PERF_MPERF = 2,
>
RE: [GIT] Networking
From: Rustad, Mark D
...
> >> static int smp_ah(struct crypto_blkcipher *tfm, const u8 irk[16],
> >> const u8 r[3], u8 res[3])
> >
> > Expect that it looks like you are passing arrays by value,
> > but instead you are passing by reference.
> >
> > Explicitly pass by reference and sizeof works.
>
> It depends on what you mean by works. It at least doesn't look so misleading
> when passing by reference
> and so works more as expected. The sizeof in either case will never return
> the size of the array. To
> have sizeof return the size of the array would require a typedef of the array
> to pass by reference. In
> some cases that could be the right thing to do.
Feed:
int bar(int (*f)[10]) { return sizeof *f; }
into cc -O2 -S and look at the generated code - returns 40 not 4.
David
--
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] vfio: Enable VFIO device for powerpc
On 26/08/2015 20:54, Paul Mackerras wrote: > On Wed, Aug 26, 2015 at 11:34:26AM +0200, Alexander Graf wrote: >> >> >> On 13.08.15 03:15, David Gibson wrote: >>> ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is >>> used to handle any necessary interactions between KVM and VFIO. >>> >>> Currently that device is built on x86 and ARM, but not powerpc, although >>> powerpc does support both KVM and VFIO. This makes things awkward in >>> userspace >>> >>> Currently qemu prints an alarming error message if you attempt to use VFIO >>> and it can't initialize the KVM VFIO device. We don't want to remove the >>> warning, because lack of the KVM VFIO device could mean coherency problems >>> on x86. On powerpc, however, the error is harmless but looks disturbing, >>> and a test based on host architecture in qemu would be ugly, and break if >>> we do need the KVM VFIO device for something important in future. >>> >>> There's nothing preventing the KVM VFIO device from being built for >>> powerpc, so this patch turns it on. It won't actually do anything, since >>> we don't define any of the arch_*() hooks, but it will make qemu happy and >>> we can extend it in future if we need to. >>> >>> Signed-off-by: David Gibson >>> Reviewed-by: Eric Auger >> >> Paul is going to take care of the kvm-ppc tree for 4.3. Also, ppc kvm >> patches should get CC on the kvm-ppc@vger mailing list ;). >> >> Paul, could you please pick this one up? > > Sure, I'll do that once I get home (end of this week). This was not in the 4.3 pull request, but I think we can apply it after the end of the merge window. Paolo -- 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 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses
Hello Andy, On 09/07/2015 12:55 PM, Andy Yan wrote: > Hi > There are also many other devices like display and mmc and even > the cpu(if the cpu want run a high frequency when boot up)need to > get power supply from PMIC, so it is better to load PMIC as early as > possible.Built-in is a better choice. > Please don't top post, it makes following the conversation much harder. Yes, I know that many devices needs the regulators provided by the PMIC but that it's also true for all the regulators in all the PMICs for all the boards supported by multi_v7_defconfig. So to keep the kernel binary on a reasonable size, the current multi_v7 policy is to enable as much as possible as a module so just saying that many other devices are using regulators from this PMIC is not enough. Saying that it will allow mounting a NFS rootfs without an initramfs as Sjoerd said is a much better justification IMHO. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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/
[RESEND PATCH 2/2] i2c: added I2C_FUNC_NO_CLK_STRETCH to i2c-algo-bit.c
Added I2C_FUNC_NO_CLK_STRETCH to drivers/i2c/algos/i2c-algo-bit.c when
getscl is not available.
Signed-off-by: Nicola Corna
---
drivers/i2c/algos/i2c-algo-bit.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 899bede..82cad0b 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -602,10 +602,13 @@ bailout:
static u32 bit_func(struct i2c_adapter *adap)
{
+ struct i2c_algo_bit_data *bit_adap = adap->algo_data;
+
return I2C_FUNC_I2C | I2C_FUNC_NOSTART | I2C_FUNC_SMBUS_EMUL |
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
- I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
+ I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING |
+ (bit_adap->getscl ? 0 : I2C_FUNC_NO_CLK_STRETCH);
}
--
2.5.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 v2] QEMU fw_cfg DMA interface documentation
Hi, > It's just simplicity. If you want to read a few times from the same > field (like in ACPI tables, read the data size and then the data), you > need a way to enable and disable the selector and manage the current > offset for that entry. This is already provided with the "old" > interface. Could be handled with a 'select' control bit. Only when set select entry and reset offset to zero. Also: would it make sense to allow an *array* of FWCfgDmaAccess structs? With a 'more' bit in control we could indicate that there are more entries. I'm not sure firmware would actually use that though ... cheers, Gerd -- 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] zram: fix possible use after free in zcomp_create()
On (09/07/15 11:33), Luis Henriques wrote:
> zcomp_create() verifies the success of zcomp_strm_{multi,siggle}_create()
> through comp->stream, which can potentially be pointing to memory that was
> freed if these functions returned an error.
>
good catch.
we probably better start checking the zcomp_strm_multi_create()/
zcomp_strm_single_create() status in zcomp_create(); that's much
more obvious and that's why we return it in the first place.
what do you think?
---
drivers/block/zram/zcomp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 3456d5a..16bbc8c 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -360,6 +360,7 @@ struct zcomp *zcomp_create(const char *compress, int
max_strm)
{
struct zcomp *comp;
struct zcomp_backend *backend;
+ int ret;
backend = find_backend(compress);
if (!backend)
@@ -371,10 +372,10 @@ struct zcomp *zcomp_create(const char *compress, int
max_strm)
comp->backend = backend;
if (max_strm > 1)
- zcomp_strm_multi_create(comp, max_strm);
+ ret = zcomp_strm_multi_create(comp, max_strm);
else
- zcomp_strm_single_create(comp);
- if (!comp->stream) {
+ ret = zcomp_strm_single_create(comp);
+ if (ret != 0) {
kfree(comp);
return ERR_PTR(-ENOMEM);
}
--
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] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts
Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
as well as absolute timeout.
Signed-off-by: Jesper Nilsson
---
Longer background:
One of the uses for TFD_TIMER_CANCEL_ON_SET is to get
an event when the CLOCK_REALTIME changes (as by NTP or user action).
In this case, the timeout irrelevant, and the maximum
available value could be selected to avoid mis-triggers.
However, timerfd uses time_t for configuration, and the maximum
value on a 32bit time_t system is actually a valid time
(near 2038-01-19 03:14) in the 64bit ktime_t used internally in timerfd.
One way of provoking this problem would be to set the time
using "date '2038-01-19 03:14'" and letting the time roll over
a few seconds later.
After this time, a timerfd will continuously fire
when configured with a maximum absolute timeout,
potentially stealing all CPU and stopping the application
from doing what it really should be doing.
Which would be fine, unless the application is systemd
and loops at startup, leaving the system in a state where
the kernel is up, but nothing running in userspace. :-(
This problem was further exposed in kernel v3.19 by
commit a6d6e1c879efa4b77e250c34fe5fe1c34e6ef070
which introduced 64bit time in the RTC subsystem.
On an unconfigured RTC or an RTC with flat/removed battery
the date on could be random, and in some cases past 2038.
Of course, the proposed patch only allows the setting of relative
timeouts with TFD_TIMER_CANCEL_ON_SET, any application using
it would also need to be patched to use the relative timer
for this solve the described problem.
Another solution would be to add a new flag to timerfd_settime()
to indicate that the timer value is irrelevant, but I considered
it an unnecessary waste of a flag-bit.
Tested on a MIPS 34Kc with kernel v4.1.
fs/timerfd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index b94fa6c..8ec3aeb 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -134,7 +134,7 @@ static void timerfd_setup_cancel(struct timerfd_ctx *ctx,
int flags)
{
if ((ctx->clockid == CLOCK_REALTIME ||
ctx->clockid == CLOCK_REALTIME_ALARM) &&
- (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) {
+ (flags & TFD_TIMER_CANCEL_ON_SET)) {
if (!ctx->might_cancel) {
ctx->might_cancel = true;
spin_lock(&cancel_lock);
--
1.7.10.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.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 V4 2/2] arm64: Change memcpy in kernel to use the copy template file
On Fri, Aug 21, 2015 at 03:01:41PM -0700, Feng Kan wrote: > This converts the memcpy.S to use the copy template file. The copy > template file was based originally on the memcpy.S. Minor changes > was made to it to accommodate the copy to/from/in user files. I think it will be easier to follow if you make this patch the first, just a simple move of code without any functional change. > > Signed-off-by: Feng Kan > --- > arch/arm64/lib/memcpy.S | 179 > +++- > 1 file changed, 26 insertions(+), 153 deletions(-) > > diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S > index 8a9a96d..761acd7 100644 > --- a/arch/arm64/lib/memcpy.S > +++ b/arch/arm64/lib/memcpy.S [...] > +.macro strh1 label, ptr, regB, val > +strh \ptr, [\regB], \val > +.endm There is a problem with the tab/space conversion, either in your editor or the email server. The above indentation should use tabs (and the subsequent ones). -- Catalin -- 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: Kernel 4.1.6 Panic due to slab corruption
Did a bit more investigation and it turns out the corruption is happening in slab_alloc_node, in the 'else' branch when get_freepointer is being called: 0x81182a50 <+144>: movsxd rax,DWORD PTR [r12+0x20] 0x81182a55 <+149>: movrdi,QWORD PTR [r12] 0x81182a59 <+153>: movrbx,QWORD PTR [r13+rax*1+0x0] The problematic line is the +153 offset, running addr2line shows that, this is get_freepointer: addr2line -f -e vmlinux-4.1.6-clouder1 81182a59 get_freepointer /home/projects/linux-stable/mm/slub.c:247 In this case the values of the arguments of this function are completely bogus (or so it seems): 1. RAX is shown to be 0 and rax is supposed to hold the pointer to struct kmem_cache. But curiously there isn't an error for NULL ptr, as well as the check for the return value of slab_pre_alloc_hook would have terminated the function early. 2. The value of r13 (which holds the pointer to the first free object from the freelist) is also bogus: 00028001 I'm a bit puzzled as to why am I not getting a NULL ptr error. But in any case it looks that the per-cpu slub cache freelist has been corrupted. Doing addr2line on the other paging request failures also show that the issue is in the same function - get_freepointer: addr2line -f -e vmlinux-4.1.6-clouder1 811824e5 get_freepointer /home/projects/linux-stable/mm/slub.c:247 Regards, Nikolay On 09/07/2015 11:41 AM, Nikolay Borisov wrote: > Hello, > > On one of our servers I've observed the a kernel pannic > happening with the following backtrace: > > [654405.527070] BUG: unable to handle kernel paging request at > 00028001 > [654405.527076] IP: [] kmem_cache_alloc_node+0x99/0x1e0 > [654405.527085] PGD 14bef58067 PUD 2ab358067 PMD 0 > [654405.527089] Oops: [#11] SMP > [654405.527093] Modules linked in: xt_multiport tcp_diag inet_diag act_police > cls_basic sch_ingress scsi_transport_iscsi ipt_REJECT nf_reject_ipv4 > xt_pkttype xt_state veth openvswitch xt_owner xt_conntrack iptable_filter > iptable_mangle xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 > nf_nat_ipv4 nf_nat xt_CT nf_conntrack iptable_raw ip_tables ib_ipoib rdma_ucm > ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr > ipv6 ext2 dm_thin_pool dm_bio_prison dm_persistent_data dm_bufio libcrc32c > dm_mirror dm_region_hash dm_log iTCO_wdt iTCO_vendor_support sb_edac > edac_core i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core ioatdma dca > ipmi_devintf ipmi_si ipmi_msghandler mpt2sas scsi_transport_sas raid_class > [654405.527145] CPU: 14 PID: 32267 Comm: httpd Tainted: G D L > 4.1.6-clouder1 #1 > [654405.527147] Hardware name: Supermicro > X9DRD-7LN4F(-JBOD)/X9DRD-EF/X9DRD-7LN4F, BIOS 3.0 07/09/2013 > [654405.527149] task: 88139d3b1ec0 ti: 8808eda14000 task.ti: > 8808eda14000 > [654405.527151] RIP: 0010:[] [] > kmem_cache_alloc_node+0x99/0x1e0 > [654405.527155] RSP: 0018:88407fcc3a98 EFLAGS: 00210246 > [654405.527156] RAX: RBX: RCX: > 8814ce9acf80 > [654405.527157] RDX: 837ad864 RSI: 00050200 RDI: > 00018ce0 > [654405.527158] RBP: 88407fcc3af8 R08: 88407fcd8ce0 R09: > a033d990 > [654405.527159] R10: 88058676fdd8 R11: 7b4a R12: > 881fff807ac0 > [654405.527161] R13: 00028001 R14: 0001 R15: > 881fff807ac0 > [654405.527162] FS: () GS:88407fcc(0063) > knlGS:55c832e0 > [654405.527164] CS: 0010 DS: 002b ES: 002b CR0: 80050033 > [654405.527165] CR2: 00028001 CR3: 001467b64000 CR4: > 000406e0 > [654405.527166] Stack: > [654405.527167] > 881ff2d05000 > [654405.527170] 88407fcc3ae8 00050200812b5903 88407fcc3ae8 > 01a2 > [654405.527172] 0001 88058676fc60 88058676fe80 > 1800 > [654405.527175] Call Trace: > [654405.527177] > [654405.527184] [] ovs_flow_stats_update+0x110/0x160 > [openvswitch] > [654405.527189] [] ovs_dp_process_packet+0x64/0xf0 > [openvswitch] > [654405.527193] [] ? netdev_port_receive+0x110/0x110 > [openvswitch] > [654405.527197] [] ? netdev_port_receive+0x110/0x110 > [openvswitch] > [654405.527201] [] ovs_vport_receive+0x85/0xb0 > [openvswitch] > [654405.527207] [] ? blk_mq_free_hctx_request+0x36/0x40 > [654405.527209] [] ? blk_mq_free_request+0x31/0x40 > [654405.527214] [] ? read_tsc+0x9/0x10 > [654405.527220] [] ? ktime_get+0x54/0xc0 > [654405.527225] [] ? put_device+0x17/0x20 > [654405.527227] [] ? tcf_act_police+0x150/0x210 > [act_police] > [654405.527232] [] ? tcf_action_exec+0x51/0xa0 > [654405.527235] [] ? basic_classify+0x75/0xe0 [cls_basic] > [654405.527237] [] ? tc_classify+0x55/0xc0 > [654405.527241] [] netdev_port_receive+0x9d/0x110 > [openvswitch] > [654405.527245] [] netdev_frame_hook+0x34/0x50 > [
Re: [PATCH V8 7/7] perf,tools: Show freq/CPU%/CORE_BUSY% in perf report --stdio
On Thu, Sep 03, 2015 at 08:31:03AM -0400, kan.li...@intel.com wrote:
> From: Kan Liang
>
> Show frequency, CPU Utilization and percent performance for each symbol
> in perf report by --stdio --show-freq-perf
>
> In sampling group, only group leader do sampling. So only need to print
> group leader's freq in --group.
>
> Here is an example.
>
> $ perf report --stdio --group --show-freq-perf
Ithink the --show-freq-perf option should imply --group, so user would type:
perf record --freq-perf
perf report --show-freq-perf
I wonder we should use --freq-perf for report as well 'perf report --freq-perf'
jirka
>
> Overhead FREQ MHz CPU% CORE_BUSY%
> Command Shared Object Symbol
> . . ..
> ... ..
>
> 99.54% 99.54% 99.53% 99.53% 99.53% 2301 96 99
> tchain_edit tchain_edit [.] f3
> 0.20% 0.20% 0.20% 0.20% 0.20% 2301 98 99
> tchain_edit tchain_edit [.] f2
> 0.05% 0.05% 0.05% 0.05% 0.05% 2300 98 99
> tchain_edit [kernel.vmlinux] [k] read_tsc
>
> Signed-off-by: Kan Liang
> ---
> tools/perf/Documentation/perf-report.txt | 12 ++
> tools/perf/builtin-report.c | 22 +-
> tools/perf/ui/hist.c | 71
> +---
> tools/perf/util/hist.h | 3 ++
> tools/perf/util/session.c| 33 ---
> tools/perf/util/sort.c | 3 ++
> tools/perf/util/symbol.h | 12 +-
> 7 files changed, 134 insertions(+), 22 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-report.txt
> b/tools/perf/Documentation/perf-report.txt
> index 9c7981b..6280e22 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -306,6 +306,18 @@ OPTIONS
> special event -e cpu/mem-loads/ or -e cpu/mem-stores/. See
> 'perf mem' for simpler access.
>
> +--show-freq-perf::
> + Show CPU frequency and performance result from sample read.
> + To generate the frequency and performance output, the perf.data file
> + must have been obtained by group read and using special events cycles,
> + ref-cycles, msr/tsc/, msr/aperf/ or msr/mperf/
> + Freq MHz: The frequency during the sample interval. Needs cycles and
> + ref-cycles event.
> + CPU%: CPU utilization during the sample interval. Needs ref-cycles and
> + msr/tsc/ events.
> + CORE_BUSY%: actual percent performance (APERF/MPERF%) during the
> + sample interval. Needs msr/aperf/ and msr/mperf/ events.
> +
> --percent-limit::
> Do not show entries which have an overhead under that percent.
> (Default: 0).
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 7673f1c..ebcbe4c 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -133,7 +133,8 @@ static int hist_iter__report_callback(struct
> hist_entry_iter *iter,
> struct branch_info *bi;
>
> if ((iter->ops == &hist_iter_normal) &&
> - perf_evsel__is_group_leader(evsel))
> + perf_evsel__is_group_leader(evsel) &&
> + symbol_conf.show_freq_perf)
> set_he_freq_perf(rep->session, iter);
>
> if (!ui__has_annotation())
> @@ -772,6 +773,8 @@ int cmd_report(int argc, const char **argv, const char
> *prefix __maybe_unused)
> OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
> "Enable kernel symbol demangling"),
> OPT_BOOLEAN(0, "mem-mode", &report.mem_mode, "mem access profile"),
> + OPT_BOOLEAN(0, "show-freq-perf", &symbol_conf.show_freq_perf,
> + "show CPU freqency and performance info"),
> OPT_CALLBACK(0, "percent-limit", &report, "percent",
>"Don't show entries under that percent",
> parse_percent_limit),
> OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
> @@ -788,7 +791,9 @@ int cmd_report(int argc, const char **argv, const char
> *prefix __maybe_unused)
> struct perf_data_file file = {
> .mode = PERF_DATA_MODE_READ,
> };
> + struct perf_evsel *pos;
> int ret = hists__init();
> + perf_freq_t freq_data_status = { 0 };
>
> if (ret < 0)
> return ret;
> @@ -873,6 +878,21 @@ repeat:
> symbol_conf.cumulate_callchain = false;
> }
>
> +
> + if (symbol_conf.show_freq_perf) {
> + symbol_conf.freq_perf_type = 0;
> + evlist__for_each(session->evlist, pos) {
> + perf_freq__init(session->header.env.msr_pmu_type,
> + pos, freq_data_status, 1);
> + }
> + if (perf_freq__has_freq(freq_data_status))
> +
Re: [PATCH 3/9] KVM: x86: add pcommit support
On 21/08/2015 06:50, Xiao Guangrong wrote:
> Pass PCOMMIT CPU feature to guest to enable PCOMMIT instruction
>
> Currently we do not catch pcommit instruction for L1 guest and
> allow L1 to catch this instruction for L2
>
> The specification locates at:
> https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/include/asm/vmx.h | 2 +-
> arch/x86/include/uapi/asm/vmx.h | 4 +++-
> arch/x86/kvm/cpuid.c| 2 +-
> arch/x86/kvm/cpuid.h| 8
> arch/x86/kvm/vmx.c | 29 -
> 5 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> index 9299ae5..e2ad08a 100644
> --- a/arch/x86/include/asm/vmx.h
> +++ b/arch/x86/include/asm/vmx.h
> @@ -72,7 +72,7 @@
> #define SECONDARY_EXEC_SHADOW_VMCS 0x4000
> #define SECONDARY_EXEC_ENABLE_PML 0x0002
> #define SECONDARY_EXEC_XSAVES0x0010
> -
> +#define SECONDARY_EXEC_PCOMMIT 0x0020
>
> #define PIN_BASED_EXT_INTR_MASK 0x0001
> #define PIN_BASED_NMI_EXITING 0x0008
> diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
> index 37fee27..5b15d94 100644
> --- a/arch/x86/include/uapi/asm/vmx.h
> +++ b/arch/x86/include/uapi/asm/vmx.h
> @@ -78,6 +78,7 @@
> #define EXIT_REASON_PML_FULL62
> #define EXIT_REASON_XSAVES 63
> #define EXIT_REASON_XRSTORS 64
> +#define EXIT_REASON_PCOMMIT 65
>
> #define VMX_EXIT_REASONS \
> { EXIT_REASON_EXCEPTION_NMI, "EXCEPTION_NMI" }, \
> @@ -126,7 +127,8 @@
> { EXIT_REASON_INVVPID, "INVVPID" }, \
> { EXIT_REASON_INVPCID, "INVPCID" }, \
> { EXIT_REASON_XSAVES,"XSAVES" }, \
> - { EXIT_REASON_XRSTORS, "XRSTORS" }
> + { EXIT_REASON_XRSTORS, "XRSTORS" }, \
> + { EXIT_REASON_PCOMMIT, "PCOMMIT" }
>
> #define VMX_ABORT_SAVE_GUEST_MSR_FAIL1
> #define VMX_ABORT_LOAD_HOST_MSR_FAIL 4
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 962fc7d..faeb0b3 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -348,7 +348,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
> *entry, u32 function,
> F(FSGSBASE) | F(BMI1) | F(HLE) | F(AVX2) | F(SMEP) |
> F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | f_mpx | F(RDSEED) |
> F(ADX) | F(SMAP) | F(AVX512F) | F(AVX512PF) | F(AVX512ER) |
> - F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB);
> + F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB) | F(PCOMMIT);
>
> /* cpuid 0xD.1.eax */
> const u32 kvm_supported_word10_x86_features =
> diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
> index dd05b9c..aed7bfe 100644
> --- a/arch/x86/kvm/cpuid.h
> +++ b/arch/x86/kvm/cpuid.h
> @@ -133,4 +133,12 @@ static inline bool guest_cpuid_has_mpx(struct kvm_vcpu
> *vcpu)
> best = kvm_find_cpuid_entry(vcpu, 7, 0);
> return best && (best->ebx & bit(X86_FEATURE_MPX));
> }
> +
> +static inline bool guest_cpuid_has_pcommit(struct kvm_vcpu *vcpu)
> +{
> + struct kvm_cpuid_entry2 *best;
> +
> + best = kvm_find_cpuid_entry(vcpu, 7, 0);
> + return best && (best->ebx & bit(X86_FEATURE_PCOMMIT));
> +}
> #endif
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 4cf25b9..b526c61 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -2474,7 +2474,8 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx
> *vmx)
> SECONDARY_EXEC_APIC_REGISTER_VIRT |
> SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
> SECONDARY_EXEC_WBINVD_EXITING |
> - SECONDARY_EXEC_XSAVES;
> + SECONDARY_EXEC_XSAVES |
> + SECONDARY_EXEC_PCOMMIT;
>
> if (enable_ept) {
> /* nested EPT: emulate EPT also to L1 */
> @@ -3015,7 +3016,8 @@ static __init int setup_vmcs_config(struct vmcs_config
> *vmcs_conf)
> SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY |
> SECONDARY_EXEC_SHADOW_VMCS |
> SECONDARY_EXEC_XSAVES |
> - SECONDARY_EXEC_ENABLE_PML;
> + SECONDARY_EXEC_ENABLE_PML |
> + SECONDARY_EXEC_PCOMMIT;
> if (adjust_vmx_controls(min2, opt2,
> MSR_IA32_VMX_PROCBASED_CTLS2,
> &_cpu_based_2nd_exec_control) < 0)
> @@ -4570,6 +4572,9 @@ static u32 vmx_secondary_exec_control(struct vcpu_vmx
> *vmx)
> /* PML is enabled/disabled in creating/destorying vcpu */
> exec_control &= ~SECONDARY_EXEC_ENABLE_PML;
>
> + /* Currently, we allow L1 guest to directly run pcommit ins
[PATCH-v2 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller
PXA1928 SDHCI controller has few differences, for example, PXAxxxPXA1928 ===== SDCLK_DELAY field 0x10A 0x114 SDCLK_DELAY mask0x1F 0x3FF SDCLK_DELAY shift9 8 SDCLK_SEL shift 8 2 (SEL1) So this patch series introduces new compatible device_id (marvell,pxav3-1928-sdhci), and makes use of .data for handling such differences. The series also adds support like, - independent ->set_clock() api, as we need to enable internal clock gate and TX clock - pinctrl configuration based on bus speed. - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the clocks, so it is important to configure them as part of ->set_power() More detailed description is written into commit log. - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id - Enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk for pxa1928 device V1 => V2: = - Fixed typo issue (residual change remained by mistake) - Added new patch updating DT binding document for pxa1928 support - Added new patch enabling CARD_ON_NEEDS_BUS_ON for pxa1928 device Testing: I have done basic testing on both eMMC and SD card on PXA1928 based platform. Note: I tried to made sure that I do not break any other platform, which used sdhci, except HS200 configuration.· Unfortunately I do not have access to any other datasheets, where I can cross check the details on HS200 bit-fields. Probably someone who has access can confirm [PATCH 4/5], whether it impacts other platforms. Kevin Liu (1): mmc: sdhci-pxav3: Fix HS200 mode support Vaibhav Hiremath (6): mmc: sdhci-pxav3: Enable pxa1928 device support mmc: sdhci-pxav3: binding: Add pxa1928 compatible support mmc: sdhci-pxav3: Add platform specific set_clock ops mmc: sdhci-pxav3: Add pinctl setting according to bus clock mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields mmc: sdhci: enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON for pxa1928 .../devicetree/bindings/mmc/sdhci-pxa.txt | 2 +- drivers/mmc/host/sdhci-pltfm.c | 4 + drivers/mmc/host/sdhci-pxav3.c | 168 +++-- drivers/mmc/host/sdhci.c | 3 +- drivers/mmc/host/sdhci.h | 2 + 5 files changed, 165 insertions(+), 14 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 3/7] mmc: sdhci-pxav3: Add platform specific set_clock ops
In case of PXA1928 & family of devices, the TX BUS and internal clock
need to be set as part of ->set_clock() ops, so this patch adds
platform specific ->set_clock() operation.
Note that, in order to not break other platforms, this patch
introduced the flag, which controls whether controller/platform
specific clock configuration needs to be executed.
Signed-off-by: Vaibhav Hiremath
---
drivers/mmc/host/sdhci-pxav3.c | 46 +-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index aecae04..c2b2b78 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -48,6 +48,10 @@
#define SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
#define SDCFG_GEN_PAD_CLK_CNT_SHIFT 24
+#define SD_FIFO_PARAM 0x104
+#define INTERNAL_CLK_GATE_CTRLBIT(8)
+#define INTERNAL_CLK_GATE_ON BIT(9)
+
#define SD_SPI_MODE0x108
#define SD_CE_ATA_10x10C
@@ -57,6 +61,9 @@
#define SD_RX_CFG_REG 0x114
+#define TX_CFG_REG 0x118
+#define TX_INTERNAL_SEL_BUS_CLK BIT(30)
+
/* IO Power control */
#define IO_PWR_AKEY_ASFAR 0xbaba
#define IO_PWR_AKEY_ASSAR 0xeb10
@@ -68,6 +75,9 @@ struct sdhci_pxa_data {
u8 sdclk_delay_shift;
u8 sdclk_sel_mask;
u8 sdclk_sel_shift;
+
+ /* set this if platform needs separate clock configuration */
+ bool set_pltfrm_clk;
/*
* We have few more differences, add them along with their
* respective feature support
@@ -90,6 +100,7 @@ static struct sdhci_pxa_data pxav3_data_v1 = {
.sdclk_delay_shift = 9,
.sdclk_sel_mask = 0x1,
.sdclk_sel_shift= 8,
+ .set_pltfrm_clk = false,
};
static struct sdhci_pxa_data pxav3_data_v2 = {
@@ -99,6 +110,7 @@ static struct sdhci_pxa_data pxav3_data_v2 = {
/* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
.sdclk_sel_mask = 0x3,
.sdclk_sel_shift= 2,/* SDCLK_SEL1 */
+ .set_pltfrm_clk = true,
};
/*
@@ -375,8 +387,40 @@ static void pxav3_voltage_switch(struct sdhci_host *host,
writel(val, pxa->io_pwr_reg);
}
+static void pxav3_set_tx_clock(struct sdhci_host *host)
+{
+ u32 val;
+
+ val = sdhci_readl(host, TX_CFG_REG);
+ val |= TX_INTERNAL_SEL_BUS_CLK;
+ sdhci_writel(host, val, TX_CFG_REG);
+}
+
+static void pxav3_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host->priv;
+
+ /* We still use common sdhci_set_clock() */
+ sdhci_set_clock(host, clock);
+
+ /* platform/controller specific clock configuration */
+ if (pxa->data->set_pltfrm_clk && clock != 0) {
+ u32 val;
+
+ val = sdhci_readw(host, SD_FIFO_PARAM);
+ /* Internal clock gate ON and CTRL = 0b11 */
+ val |= INTERNAL_CLK_GATE_CTRL | INTERNAL_CLK_GATE_ON;
+ sdhci_writew(host, val, SD_FIFO_PARAM);
+
+ /* TX internal clock selection */
+ pxav3_set_tx_clock(host);
+ }
+
+}
+
static const struct sdhci_ops pxav3_sdhci_ops = {
- .set_clock = sdhci_set_clock,
+ .set_clock = pxav3_set_clock,
.platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
--
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 7/7] mmc: sdhci: enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON for pxa1928
Card power is dependent on bus power, without that card wouldn't respond (No CARD_INT). So this patch enables the quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON. Signed-off-by: Vaibhav Hiremath --- drivers/mmc/host/sdhci-pltfm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 5788a8c..057190c 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -102,7 +102,8 @@ void sdhci_get_of_property(struct platform_device *pdev) host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; if (of_device_is_compatible(np, "marvell,pxav3-1928-sdhci")) - host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER; + host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER | + SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON; clk = of_get_property(np, "clock-frequency", &size); if (clk && size == sizeof(*clk) && *clk) -- 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 5/7] mmc: sdhci-pxav3: Fix HS200 mode support
From: Kevin Liu
IN case of MMC HS200 mode, current code does not enable
SD_CE_ATA_2.MMC_HS200 & SD_CE_ATA_2.MMC_CARD bit configurations.
So this patch updates the above bit fields correctly.
Signed-off-by: Tim Wang
Signed-off-by: Kevin Liu
Signed-off-by: Vaibhav Hiremath
---
Note: Unfortunately I do not have access to any other datasheets
which uses sdhci-pxav3 driver, so quite not sure whether this would
break any existing platform, probably NOT, as I do not see any
references for this change.
If anyone can confirm that would be really great.
drivers/mmc/host/sdhci-pxav3.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d933f75..6978810 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,8 @@
#define SD_CE_ATA_10x10C
#define SD_CE_ATA_20x10E
+#define SD_CE_ATA2_HS200_EN BIT(10)
+#define SD_CE_ATA2_MMC_MODE BIT(12)
#define SDCE_MISC_INT BIT(2)
#define SDCE_MISC_INT_EN BIT(1)
@@ -330,6 +332,17 @@ static int pxav3_select_pinstate(struct sdhci_host *host,
unsigned int uhs)
return pinctrl_select_state(pxa->pinctrl, pinctrl);
}
+static int pxav3_select_hs200(struct sdhci_host *host)
+{
+ u16 reg = 0;
+
+ reg = sdhci_readw(host, SD_CE_ATA_2);
+ reg |= SD_CE_ATA2_HS200_EN | SD_CE_ATA2_MMC_MODE;
+ sdhci_writew(host, reg, SD_CE_ATA_2);
+
+ return 0;
+}
+
static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -361,6 +374,10 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
*host, unsigned int uhs)
case MMC_TIMING_UHS_DDR50:
ctrl_2 |= SDHCI_CTRL_UHS_DDR50 | SDHCI_CTRL_VDD_180;
break;
+ case MMC_TIMING_MMC_HS200:
+ ctrl_2 |= SDHCI_CTRL_UHS_SDR104 | SDHCI_CTRL_VDD_180;
+ pxav3_select_hs200(host);
+ break;
}
/*
--
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 6/7] mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields
IN case of Marvell 1928 family of devices, the SD_BUS_POWER and
SD_BUS_VLT bits are used internally to gate the clocks, so
we have to set these fields.
Pasting Spec words here,
The and fields should be configured
to correct values. These actually do not do the voltage selection
or switch power to the SD card. However these fields are used
internally to gate the clock. So if these fields are set
incorrectly, SD module will not function.
And during my development, I have seen that SD card wouldn't function
without right configuration into these fields.
So this patch adds new quirk (SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER),
which make sure that ->set_power() sets these fields.
Signed-off-by: Vaibhav Hiremath
---
drivers/mmc/host/sdhci-pltfm.c | 3 +++
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index a207f5a..5788a8c 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -101,6 +101,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
of_device_is_compatible(np, "fsl,mpc8536-esdhc"))
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
+ if (of_device_is_compatible(np, "marvell,pxav3-1928-sdhci"))
+ host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER;
+
clk = of_get_property(np, "clock-frequency", &size);
if (clk && size == sizeof(*clk) && *clk)
pltfm_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2d58b31..418f381 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1265,7 +1265,8 @@ static void sdhci_set_power(struct sdhci_host *host,
unsigned char mode,
else
sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
- return;
+ if (!(host->quirks2 | SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER))
+ return;
}
if (mode != MMC_POWER_OFF) {
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 9b0e2a8..8802a0c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -409,6 +409,8 @@ struct sdhci_host {
#define SDHCI_QUIRK2_SUPPORT_SINGLE(1<<13)
/* Controller broken with using ACMD23 */
#define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14)
+/* Voltage capabilities of Controller must be set */
+#define SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER (1<<15)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock
Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.
So this patch creates two states,
- Default (slow/normal) pin state
- And fast pin state for higher freq bus speed.
And selection of pin state is done based on timing mode.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci-pxav3.c | 45 +-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "sdhci.h"
#include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default;
+ struct pinctrl_state *pins_fast;
};
static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host
*host, u8 power_mode)
pxa->power_mode = power_mode;
}
+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host->priv;
+ struct pinctrl_state *pinctrl;
+
+ if (IS_ERR(pxa->pinctrl) ||
+ IS_ERR(pxa->pins_default) ||
+ IS_ERR(pxa->pins_fast))
+ return -EINVAL;
+
+ switch (uhs) {
+ case MMC_TIMING_UHS_SDR50:
+ case MMC_TIMING_UHS_SDR104:
+ case MMC_TIMING_MMC_HS200:
+ case MMC_TIMING_MMC_HS400:
+ pinctrl = pxa->pins_fast;
+ break;
+ default:
+ /* back to default state for other legacy timing */
+ pinctrl = pxa->pins_default;
+ break;
+ }
+
+ return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+ pxav3_select_pinstate(host, uhs);
}
static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host,
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-
}
static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}
+ pxa->pinctrl = devm_pinctrl_get(dev);
+ if (!IS_ERR(pxa->pinctrl)) {
+ pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl,
"default");
+ if (IS_ERR(pxa->pins_default))
+ dev_err(dev, "could not get default pinstate\n");
+ pxa->pins_fast = pinctrl_lookup_state(pxa->pinctrl, "fast");
+ if (IS_ERR(pxa->pins_fast))
+ dev_info(dev, "could not get fast pinstate\n");
+ }
+
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev, PXAV3_RPM_DELAY_MS);
--
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/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support
With support for pxa1928 family of devices , this patch updates the binding document with compatible property of "marvell,pxav3-1928-sdhci". Signed-off-by: Vaibhav Hiremath --- Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt index 3d1b449..29edcf5 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt @@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers. Required properties: - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or - "marvell,armada-380-sdhci". + "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci". - reg: * for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for the SDHCI registers. -- 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/7] mmc: sdhci-pxav3: Enable pxa1928 device support
SDHCI controller present in PXA1928 has few differences as far as
register map is concerned.
For example,
PXAxxxPXA1928
=====
SDCLK_DELAY field 0x10A 0x114
SDCLK_DELAY mask0x1F 0x3FF
SDCLK_DELAY shift9 8
SDCLK_SEL shift 8 2 (SEL1)
So in order to support multi-platform, use sdhci_pxa_regdata structure
as a variant data according to platform.
Note that, there are some more differences, which would be added
as and when respective feature gets added to the driver.
Signed-off-by: Vaibhav Hiremath
---
drivers/mmc/host/sdhci-pxav3.c | 62 ++
1 file changed, 51 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 6d4bad4..aecae04 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -42,9 +42,6 @@
#define PXAV3_RPM_DELAY_MS 50
#define SD_CLOCK_BURST_SIZE_SETUP 0x10A
-#define SDCLK_SEL 0x100
-#define SDCLK_DELAY_SHIFT 9
-#define SDCLK_DELAY_MASK 0x1f
#define SD_CFG_FIFO_PARAM 0x100
#define SDCFG_GEN_PAD_CLK_ON BIT(6)
@@ -58,11 +55,25 @@
#define SDCE_MISC_INT BIT(2)
#define SDCE_MISC_INT_EN BIT(1)
+#define SD_RX_CFG_REG 0x114
+
/* IO Power control */
#define IO_PWR_AKEY_ASFAR 0xbaba
#define IO_PWR_AKEY_ASSAR 0xeb10
#define IO_PWR_MMC1_PAD_1V8BIT(2)
+struct sdhci_pxa_data {
+ u32 sdclk_delay_reg;
+ u32 sdclk_delay_mask;
+ u8 sdclk_delay_shift;
+ u8 sdclk_sel_mask;
+ u8 sdclk_sel_shift;
+ /*
+* We have few more differences, add them along with their
+* respective feature support
+*/
+};
+
struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
@@ -70,6 +81,24 @@ struct sdhci_pxa {
void __iomem *sdio3_conf_reg;
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
+ struct sdhci_pxa_data *data;
+};
+
+static struct sdhci_pxa_data pxav3_data_v1 = {
+ .sdclk_delay_reg= SD_CLOCK_BURST_SIZE_SETUP,
+ .sdclk_delay_mask = 0x1F,
+ .sdclk_delay_shift = 9,
+ .sdclk_sel_mask = 0x1,
+ .sdclk_sel_shift= 8,
+};
+
+static struct sdhci_pxa_data pxav3_data_v2 = {
+ .sdclk_delay_reg= SD_RX_CFG_REG,
+ .sdclk_delay_mask = 0x3FF,
+ .sdclk_delay_shift = 8,
+ /* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
+ .sdclk_sel_mask = 0x3,
+ .sdclk_sel_shift= 2,/* SDCLK_SEL1 */
};
/*
@@ -183,6 +212,8 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host->priv;
sdhci_reset(host, mask);
@@ -193,12 +224,14 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
*/
if (pdata && 0 != pdata->clk_delay_cycles) {
u16 tmp;
-
- tmp = readw(host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
- tmp |= (pdata->clk_delay_cycles & SDCLK_DELAY_MASK)
- << SDCLK_DELAY_SHIFT;
- tmp |= SDCLK_SEL;
- writew(tmp, host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
+ struct sdhci_pxa_data *data = pxa->data;
+
+ tmp = readw(host->ioaddr + data->sdclk_delay_reg);
+ tmp |= (pdata->clk_delay_cycles &
data->sdclk_delay_mask)
+ << data->sdclk_delay_shift;
+ tmp &= ~(data->sdclk_sel_mask << data->sdclk_sel_shift);
+ tmp |= 1 << data->sdclk_sel_shift;
+ writew(tmp, host->ioaddr + data->sdclk_delay_reg);
}
}
}
@@ -363,10 +396,16 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
#ifdef CONFIG_OF
static const struct of_device_id sdhci_pxav3_of_match[] = {
{
- .compatible = "mrvl,pxav3-mmc",
+ .compatible = "mrvl,pxav3-mmc",
+ .data = (void *)&pxav3_data_v1,
+ },
+ {
+ .compatible = "marvell,armada-380-sdhci",
+ .data = (void *)&pxav3_data_v1,
},
{
- .compatible = "marvell,armada-380-sdhci",
+ .compatible = "marvell,pxav3-1928-sdhci",
+ .data = (void *)&pxav3
Re: [Xen-devel] [PATCH] xen-blkback: free requests on disconnection
On 07/09/15 07:07, Bob Liu wrote: > Hi Julien, Hi Bob, > On 09/04/2015 09:51 PM, Julien Grall wrote: >> Hi Roger, >> >> On 04/09/15 11:08, Roger Pau Monne wrote: >>> Request allocation has been moved to connect_ring, which is called every >>> time blkback connects to the frontend (this can happen multiple times during >>> a blkback instance life cycle). On the other hand, request freeing has not >>> been moved, so it's only called when destroying the backend instance. Due to >>> this mismatch, blkback can allocate the request pool multiple times, without >>> freeing it. >>> >>> In order to fix it, move the freeing of requests to xen_blkif_disconnect to >>> restore the symmetry between request allocation and freeing. >>> >>> Reported-by: Julien Grall >>> Signed-off-by: Roger Pau Monné >>> Cc: Julien Grall >>> Cc: Konrad Rzeszutek Wilk >>> Cc: Boris Ostrovsky >>> Cc: David Vrabel >>> Cc: xen-de...@lists.xenproject.org >> >> The patch is fixing my problem when using UEFI in the guest. Thank you! >> > > Could you please explain the problem you met a bit more? > So that I can know back port this patch if met similar issue. This is related to commit 86839c56dee28c315a4c19b7bfee450ccd84cd25 "xen/block: add multi-page ring support" (Roger, it may be worth to indicate the offending commit in you commit message). When starting a guest using UEFI. After the domain is destroyed I get the following warning from blkback: [ cut here ] WARNING: CPU: 2 PID: 95 at /home/julien/works/linux/drivers/block/xen-blkback/xenbus.c:274 xen_blkif_deferred_free+0x1f4/0x1f8() Modules linked in: CPU: 2 PID: 95 Comm: kworker/2:1 Tainted: GW 4.2.0 #85 Hardware name: APM X-Gene Mustang board (DT) Workqueue: events xen_blkif_deferred_free Call trace: [] dump_backtrace+0x0/0x124 [] show_stack+0x10/0x1c [] dump_stack+0x78/0x98 [] warn_slowpath_common+0x9c/0xd4 [] warn_slowpath_null+0x14/0x20 [] xen_blkif_deferred_free+0x1f0/0x1f8 [] process_one_work+0x160/0x3b4 [] worker_thread+0x140/0x494 [] kthread+0xd8/0xf0 ---[ end trace 6f859b7883c88cdd ]--- This is because the allocation of the requests are done during the connection but the free is done when the domain is destroyed. Therefore if the domain is re-initializing the connection (because UEFI or PV Grub is used), the request won't be free and kept until the end. So I think this should be backported in Linux 4.2 where the patch has been introduced. Regards, -- Julien Grall -- 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] usb: phy: qcom: Switch to new extcon framework API
[un]register_interest and reading cable state by
name have been deprecated. Switch to new API.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-qcom-8x16-usb.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c
b/drivers/usb/phy/phy-qcom-8x16-usb.c
index 5d357a94599e..579587d97217 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -71,7 +71,7 @@ struct phy_8x16 {
struct reset_control*phy_reset;
- struct extcon_specific_cable_nb vbus_cable;
+ struct extcon_dev *vbus_edev;
struct notifier_block vbus_notify;
struct gpio_desc*switch_gpio;
@@ -234,7 +234,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
- state = extcon_get_cable_state(qphy->vbus_cable.edev, "USB");
+ state = extcon_get_cable_state_(qphy->vbus_edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -314,7 +314,6 @@ static int phy_8x16_reboot_notify(struct notifier_block
*this,
static int phy_8x16_probe(struct platform_device *pdev)
{
- struct extcon_dev *edev;
struct phy_8x16 *qphy;
struct resource *res;
struct usb_phy *phy;
@@ -349,9 +348,9 @@ static int phy_8x16_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
- edev = extcon_get_edev_by_phandle(phy->dev, 0);
- if (IS_ERR(edev))
- return PTR_ERR(edev);
+ qphy->vbus_edev = extcon_get_edev_by_phandle(phy->dev, 0);
+ if (IS_ERR(qphy->vbus_edev))
+ return PTR_ERR(qphy->vbus_edev);
ret = clk_set_rate(qphy->core_clk, INT_MAX);
if (ret < 0)
@@ -370,8 +369,8 @@ static int phy_8x16_probe(struct platform_device *pdev)
goto off_clks;
qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
- ret = extcon_register_interest(&qphy->vbus_cable, edev->name,
- "USB", &qphy->vbus_notify);
+ ret = extcon_register_notifier(qphy->vbus_edev, EXTCON_USB,
+ &qphy->vbus_notify);
if (ret < 0)
goto off_power;
@@ -385,7 +384,8 @@ static int phy_8x16_probe(struct platform_device *pdev)
return 0;
off_extcon:
- extcon_unregister_interest(&qphy->vbus_cable);
+ extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
+ &qphy->vbus_notify);
off_power:
phy_8x16_regulators_disable(qphy);
off_clks:
@@ -400,7 +400,8 @@ static int phy_8x16_remove(struct platform_device *pdev)
struct phy_8x16 *qphy = platform_get_drvdata(pdev);
unregister_reboot_notifier(&qphy->reboot_notify);
- extcon_unregister_interest(&qphy->vbus_cable);
+ extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
+ &qphy->vbus_notify);
/*
* Ensure that D+/D- lines are routed to uB connector, so
--
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 v2] QEMU fw_cfg DMA interface documentation
On 09/07/15 13:08, Gerd Hoffmann wrote: > Hi, > >> It's just simplicity. If you want to read a few times from the same >> field (like in ACPI tables, read the data size and then the data), you >> need a way to enable and disable the selector and manage the current >> offset for that entry. This is already provided with the "old" >> interface. > > Could be handled with a 'select' control bit. Only when set select > entry and reset offset to zero. > > Also: would it make sense to allow an *array* of FWCfgDmaAccess structs? > With a 'more' bit in control we could indicate that there are more > entries. I'm not sure firmware would actually use that though ... Seems far-fetched. Thanks Laszlo > cheers, > Gerd > > -- 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 8/9] KVM: VMX: introduce set_clear_2nd_exec_ctrl()
On 21/08/2015 06:50, Xiao Guangrong wrote:
>
> +static void set_clear_2nd_exec_ctrl(u32 ctrls, bool set)
> +{
> + u32 exec_ctrl = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
> +
> + if (set)
> + exec_ctrl |= ctrls;
> + else
> + exec_ctrl &= ~ctrls;
> +
> + vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_ctrl);
> +}
The second argument is always true. Do you have any plans for it?
Should we instead add functions like vmcs_or32 and vmcs_clear32?
Paolo
--
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 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses
On Mon, Sep 07, 2015 at 12:38:08PM +0200, Javier Martinez Canillas wrote: > Hello Sjoerd, > > On 09/07/2015 12:24 PM, Sjoerd Simons wrote: > > On Mon, 2015-09-07 at 11:26 +0200, Javier Martinez Canillas wrote: > >> Hello Sjoerd, > >> > >> On 09/06/2015 10:16 PM, Sjoerd Simons wrote: > >>> Enable Rockchip I2C, SPI, PWM, thermal drivers. > >>> > >>> Builtin are: > >>> * I2C as it often controls the pmic. > >> > >> Having I2C as a module will cause more probe deferrals due missing > >> regulators and slow down the boot but it should not cause issues. > >> Or am I missing something? > >> > >> In fact, I think even the PMIC could be built as a module. > > > > It could in principle. However as a lot of other drivers do need the > > regulators provided by the pmic, they'll be deferred until that driver > > is loaded. So e.g. with the i2c/pmic drivers as a module you cannot > > boot to an NFS rootfs without using an initramfs. > > > > Right, not needing an initramfs is certainly a good reason. If you could > add something like that in the commit message of patches 1/4 and 2/4 that > would be great. I don't know. multi_v7_defconfig is primarily useful as a means to quickly get a configuration that has most drivers enabled that most ARM SoCs need. As such it's more of a convenience for build testing rather than using it for booting a device. I don't think the focus should be on optimizing for boot speed. Rather if you do want to optimize for a device going through the trouble of setting up an initial ramdisk isn't all that complicated. Even more so because if you build drivers into the kernel and those drivers happen to require firmware then people will be required to setup initial ramdisks anyway. Building too many drivers into the kernel has in the past often lead to problems where all of a sudden the kernel became too big to fit into any reasonably sized region of memory and cause all sorts of weird failures in boot farms. Building everything as modules has the advantage that the size of the zImage itself doesn't vary much, hence has less of a chance to break boot farms. There are quite a few drivers in multi_v7_defconfig that I suspect could be built as loadable modules to decrease the size of the images that are currently generated. I understand that not everybody likes the additional ramdisk but, in my opinion, that's what SoC-specific default configurations are good for. We can use those to provide a base for developers where the focus is ease of testability. Thierry signature.asc Description: PGP signature
Re: [PATCH 6/9] KVM: VMX: simplify invpcid handling in vmx_cpuid_update()
On 21/08/2015 06:50, Xiao Guangrong wrote:
> + if (vmx_invpcid_supported() && (!best ||
Please start the "(" subexpression on a new line.
Paolo
> + !(best->ebx & bit(X86_FEATURE_INVPCID)) ||
> + !guest_cpuid_has_pcid(vcpu))) {
--
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: Kernel 4.1.6 Panic due to slab corruption
Hi, If you have the vmlinux image for the kernel you were running at the time, the crash occured, could you post the output of addr2line -f -e path/to/vmlinux 8115bd4d to see if it also fails in get_freepointer. Regards, Nikolay On 09/07/2015 01:37 PM, Holger Hoffstätte wrote: > On Mon, 07 Sep 2015 11:41:17 +0300, Nikolay Borisov wrote: > >> Hello, >> >> On one of our servers I've observed the a kernel pannic >> happening with the following backtrace: >> >> [654405.527070] BUG: unable to handle kernel paging request at >> 00028001 >> [654405.527076] IP: [] kmem_cache_alloc_node+0x99/0x1e0 >> [654405.527085] PGD 14bef58067 PUD 2ab358067 PMD 0 > > Interesting! I can't offer much help but had a similar panic just the other > day > for no apparent reason while running a bunch of compiles. First time I've seen > this with 4.1.6: > > Sep 5 20:42:02 ragnarok kernel: BUG: unable to handle kernel paging request > at 8800e789b740 > Sep 5 20:42:02 ragnarok kernel: IP: [] > kmem_cache_alloc+0x6d/0x160 > Sep 5 20:42:02 ragnarok kernel: PGD 1aa2067 PUD 61f7fd067 PMD 0 > Sep 5 20:42:02 ragnarok kernel: Oops: [#1] SMP > Sep 5 20:42:02 ragnarok kernel: Modules linked in: auth_rpcgss oid_registry > nfsv4 nfs lockd grace fscache sunrpc autofs4 sch_fq_codel > snd_hda_codec_realtek x86_pkg_temp_thermal coretemp snd_hda_codec_generic > crc32_pclmul crc32c_intel aesni_intel radeon aes_x86_64 glue_helper > snd_hda_codec_hdmi lrw gf128mul ablk_helper cryptd i2c_algo_bit snd_usb_audio > uvcvideo snd_hda_intel drm_kms_helper snd_hda_controller snd_hwdep > videobuf2_vmalloc snd_usbmidi_lib videobuf2_memops snd_hda_codec > videobuf2_core snd_rawmidi i2c_i801 ttm snd_hda_core v4l2_common > snd_seq_device videodev snd_pcm usbhid drm snd_timer r8169 snd i2c_core mii > soundcore parport_pc parport > Sep 5 20:42:02 ragnarok kernel: CPU: 0 PID: 32755 Comm: sh Not tainted 4.1.6 > #1 > Sep 5 20:42:02 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. > P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 > Sep 5 20:42:02 ragnarok kernel: task: 880569712e20 ti: 8804e4d9 > task.ti: 8804e4d9 > Sep 5 20:42:02 ragnarok kernel: RIP: 0010:[] > [] kmem_cache_alloc+0x6d/0x160 > Sep 5 20:42:02 ragnarok kernel: RSP: 0018:8804e4d93d88 EFLAGS: 00010282 > Sep 5 20:42:02 ragnarok kernel: RAX: RBX: 8805e7eacce0 > RCX: 0001f7e8 > Sep 5 20:42:02 ragnarok kernel: RDX: 0001f7e7 RSI: 00d0 > RDI: 00018c70 > Sep 5 20:42:02 ragnarok kernel: RBP: 8804e4d93dc8 R08: 88061f418c70 > R09: > Sep 5 20:42:02 ragnarok kernel: R10: 81748318 R11: ea00139bb500 > R12: 00d0 > Sep 5 20:42:02 ragnarok kernel: R13: 880606890600 R14: 8100d039 > R15: 8800e789b740 > Sep 5 20:42:02 ragnarok kernel: FS: 7f9c1d2f2700() > GS:88061f40() knlGS: > Sep 5 20:42:02 ragnarok kernel: CS: 0010 DS: ES: CR0: > 80050033 > Sep 5 20:42:02 ragnarok kernel: CR2: 8800e789b740 CR3: 0005f68ce000 > CR4: 000406f0 > Sep 5 20:42:02 ragnarok kernel: Stack: > Sep 5 20:42:02 ragnarok kernel: 88061f7e6c00 > 0002 8805e7eacce0 > Sep 5 20:42:02 ragnarok kernel: 880569712e20 01200011 > 8805e7eacce0 880569712e20 > Sep 5 20:42:02 ragnarok kernel: 8804e4d93de8 8100d039 > 7f9c1d2f29d0 > Sep 5 20:42:02 ragnarok kernel: Call Trace: > Sep 5 20:42:02 ragnarok kernel: [] > arch_dup_task_struct+0x69/0x170 > Sep 5 20:42:02 ragnarok kernel: [] > copy_process.part.8+0x14f/0x1760 > Sep 5 20:42:02 ragnarok kernel: [] ? > handle_mm_fault+0xd0f/0x13a0 > Sep 5 20:42:02 ragnarok kernel: [] ? > get_empty_filp+0xd4/0x1c0 > Sep 5 20:42:02 ragnarok kernel: [] ? > recalc_sigpending+0x1f/0x60 > Sep 5 20:42:02 ragnarok kernel: [] do_fork+0xd7/0x370 > Sep 5 20:42:02 ragnarok kernel: [] ? sigprocmask+0x57/0x90 > Sep 5 20:42:02 ragnarok kernel: [] SyS_clone+0x16/0x20 > Sep 5 20:42:02 ragnarok kernel: [] > system_call_fastpath+0x12/0x6a > Sep 5 20:42:02 ragnarok kernel: Code: 65 4c 03 05 ee e3 ea 7e 49 83 78 10 00 > 4d 8b 38 0f 84 b0 00 00 00 4d 85 ff 0f 84 a7 00 00 00 49 63 45 20 48 8d 4a 01 > 49 8b 7d 00 <49> 8b 1c 07 4c 89 f8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b9 49 63 > Sep 5 20:42:02 ragnarok kernel: RIP [] > kmem_cache_alloc+0x6d/0x160 > Sep 5 20:42:02 ragnarok kernel: RSP > Sep 5 20:42:02 ragnarok kernel: CR2: 8800e789b740 > Sep 5 20:42:02 ragnarok kernel: ---[ end trace e4478715791f5752 ]--- > Sep 5 20:42:02 ragnarok kernel: BUG: unable to handle kernel paging request > at 8800e789b740 > Sep 5 20:42:02 ragnarok kernel: IP: [] > kmem_cache_alloc+0x6d/0x160 > Sep 5 20:42:02 ragnarok kernel: PGD 1aa2067 PUD 61f7fd067 PMD 0 > Sep 5 20:42:02 ragnarok kernel: Oops: [#2] SMP > Sep 5 20:42:02 ragnarok k
[PATCH-v2 2/3] mmc: sdhci-pxav3: Use BIT macro for bit field definitions
Instead of using shift operation use BIT macro for bit field
definitions.
Signed-off-by: Vaibhav Hiremath
---
drivers/mmc/host/sdhci-pxav3.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 7a07177..a8a8c94 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -47,7 +47,7 @@
#define SDCLK_DELAY_MASK 0x1f
#define SD_CFG_FIFO_PARAM 0x100
-#define SDCFG_GEN_PAD_CLK_ON (1<<6)
+#define SDCFG_GEN_PAD_CLK_ON BIT(6)
#define SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
#define SDCFG_GEN_PAD_CLK_CNT_SHIFT 24
@@ -55,8 +55,8 @@
#define SD_CE_ATA_10x10C
#define SD_CE_ATA_20x10E
-#define SDCE_MISC_INT (1<<2)
-#define SDCE_MISC_INT_EN (1<<1)
+#define SDCE_MISC_INT BIT(2)
+#define SDCE_MISC_INT_EN BIT(1)
struct sdhci_pxa {
struct clk *clk_core;
--
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 0/3] mmc: sdhci-pxav3: Fix tabbing issue
Trivial patch-series, which fixes the tabbing issue in the driver, uses the BIT macro for bit fields and prints notice on -EPROBE_DEFER in sdhci_add_host() function on regulator unavailability. V1 => V2 - Fixed all comments from Joe, mostly alignment changes - Separated BIT macro usage patch into new one. - changed error to kernel notice for EPROBE_DEFER in sdhci_add_host() Note: This patch-series should get merged before another series - [PATCH-v2 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller Vaibhav Hiremath (3): mmc: sdhci-pxav3: Fix tabbing issue mmc: sdhci-pxav3: Use BIT macro for bit field definitions mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn drivers/mmc/host/sdhci-pxav3.c | 46 +- drivers/mmc/host/sdhci.c | 5 - 2 files changed, 27 insertions(+), 24 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 3/3] mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn
This patch adds kernel notice/message to sdhci_host_add() fn on
-EPROBE_DEFER.
Signed-off-by: Vaibhav Hiremath
---
drivers/mmc/host/sdhci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1dbe932..37a5cd5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3130,8 +3130,11 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->caps |= MMC_CAP_NEEDS_POLL;
/* If there are external regulators, get them */
- if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+ if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER) {
+ pr_notice("%s: regulator supply unavailable, deferring
probe.\n",
+ mmc_hostname(mmc));
return -EPROBE_DEFER;
+ }
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
if (!IS_ERR(mmc->supply.vqmmc)) {
--
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/3] mmc: sdhci-pxav3: Fix tabbing issue
There were some coding style issues where spaces have been used instead
of tabs, for example, in macro definitions, alignment of function
declarations/definitions, etc...
This patch fixes all such occurrences in the code.
Signed-off-by: Vaibhav Hiremath
---
drivers/mmc/host/sdhci-pxav3.c | 46 +-
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 946d37f..7a07177 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -39,24 +39,24 @@
#include "sdhci.h"
#include "sdhci-pltfm.h"
-#define PXAV3_RPM_DELAY_MS 50
+#define PXAV3_RPM_DELAY_MS 50
-#define SD_CLOCK_BURST_SIZE_SETUP 0x10A
-#define SDCLK_SEL 0x100
-#define SDCLK_DELAY_SHIFT 9
-#define SDCLK_DELAY_MASK 0x1f
+#define SD_CLOCK_BURST_SIZE_SETUP 0x10A
+#define SDCLK_SEL 0x100
+#define SDCLK_DELAY_SHIFT 9
+#define SDCLK_DELAY_MASK 0x1f
-#define SD_CFG_FIFO_PARAM 0x100
-#define SDCFG_GEN_PAD_CLK_ON (1<<6)
-#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
-#define SDCFG_GEN_PAD_CLK_CNT_SHIFT24
+#define SD_CFG_FIFO_PARAM 0x100
+#define SDCFG_GEN_PAD_CLK_ON (1<<6)
+#define SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
+#define SDCFG_GEN_PAD_CLK_CNT_SHIFT 24
-#define SD_SPI_MODE 0x108
-#define SD_CE_ATA_1 0x10C
+#define SD_SPI_MODE0x108
+#define SD_CE_ATA_10x10C
-#define SD_CE_ATA_2 0x10E
-#define SDCE_MISC_INT (1<<2)
-#define SDCE_MISC_INT_EN (1<<1)
+#define SD_CE_ATA_20x10E
+#define SDCE_MISC_INT (1<<2)
+#define SDCE_MISC_INT_EN (1<<1)
struct sdhci_pxa {
struct clk *clk_core;
@@ -284,7 +284,7 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
*host, unsigned int uhs)
* FE-2946959
*/
if (pxa->sdio3_conf_reg) {
- u8 reg_val = readb(pxa->sdio3_conf_reg);
+ u8 reg_val = readb(pxa->sdio3_conf_reg);
if (uhs == MMC_TIMING_UHS_SDR50 ||
uhs == MMC_TIMING_UHS_DDR50) {
@@ -304,20 +304,20 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
*host, unsigned int uhs)
}
static const struct sdhci_ops pxav3_sdhci_ops = {
- .set_clock = sdhci_set_clock,
- .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
- .get_max_clock = sdhci_pltfm_clk_get_max_clock,
- .set_bus_width = sdhci_set_bus_width,
- .reset = pxav3_reset,
- .set_uhs_signaling = pxav3_set_uhs_signaling,
+ .set_clock = sdhci_set_clock,
+ .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .reset = pxav3_reset,
+ .set_uhs_signaling = pxav3_set_uhs_signaling,
};
static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
- .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
+ .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
| SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC
| SDHCI_QUIRK_32BIT_ADMA_SIZE
| SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
- .ops = &pxav3_sdhci_ops,
+ .ops= &pxav3_sdhci_ops,
};
#ifdef CONFIG_OF
--
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: [Xen-devel] [PATCH] xen-blkback: free requests on disconnection
On 09/07/2015 07:10 PM, Julien Grall wrote: > On 07/09/15 07:07, Bob Liu wrote: >> Hi Julien, > > Hi Bob, > >> On 09/04/2015 09:51 PM, Julien Grall wrote: >>> Hi Roger, >>> >>> On 04/09/15 11:08, Roger Pau Monne wrote: Request allocation has been moved to connect_ring, which is called every time blkback connects to the frontend (this can happen multiple times during a blkback instance life cycle). On the other hand, request freeing has not been moved, so it's only called when destroying the backend instance. Due to this mismatch, blkback can allocate the request pool multiple times, without freeing it. In order to fix it, move the freeing of requests to xen_blkif_disconnect to restore the symmetry between request allocation and freeing. Reported-by: Julien Grall Signed-off-by: Roger Pau Monné Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Cc: David Vrabel Cc: xen-de...@lists.xenproject.org >>> >>> The patch is fixing my problem when using UEFI in the guest. Thank you! >>> >> >> Could you please explain the problem you met a bit more? >> So that I can know back port this patch if met similar issue. > > This is related to commit 86839c56dee28c315a4c19b7bfee450ccd84cd25 > "xen/block: add multi-page ring support" (Roger, it may be worth to > indicate the offending commit in you commit message). > > When starting a guest using UEFI. After the domain is destroyed I get > the following warning from blkback: > > > [ cut here ] > WARNING: CPU: 2 PID: 95 at > /home/julien/works/linux/drivers/block/xen-blkback/xenbus.c:274 > xen_blkif_deferred_free+0x1f4/0x1f8() > Modules linked in: > CPU: 2 PID: 95 Comm: kworker/2:1 Tainted: GW 4.2.0 #85 > Hardware name: APM X-Gene Mustang board (DT) > Workqueue: events xen_blkif_deferred_free > Call trace: > [] dump_backtrace+0x0/0x124 > [] show_stack+0x10/0x1c > [] dump_stack+0x78/0x98 > [] warn_slowpath_common+0x9c/0xd4 > [] warn_slowpath_null+0x14/0x20 > [] xen_blkif_deferred_free+0x1f0/0x1f8 > [] process_one_work+0x160/0x3b4 > [] worker_thread+0x140/0x494 > [] kthread+0xd8/0xf0 > ---[ end trace 6f859b7883c88cdd ]--- > > This is because the allocation of the requests are done during the > connection but the free is done when the domain is destroyed. Therefore > if the domain is re-initializing the connection (because UEFI or PV Grub > is used), the request won't be free and kept until the end. > Thank you! Roger, I think it's better to have this information in your commit message too. -- Regards, -Bob -- 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 V8 0/7] Freq/CPU%/CORE_BUSY% support
On Thu, Sep 03, 2015 at 08:30:56AM -0400, kan.li...@intel.com wrote: > From: Kan Liang > > This patch set supports per-sample freq/CPU%/CORE_BUSY% print in perf > report -D and --stdio. > For printing these information, the perf.data file must have been obtained > by group read and using special events cycles, ref-cycles, msr/tsc/, > msr/aperf/ or msr/mperf/. > > - Freq (MHz): The frequency during the sample interval. Needs cycles >ref-cycles event. > - CPU%: CPU utilization during the sample interval. Needs ref-cycles and >msr/tsc/ events. > - CORE_BUSY%: actual percent performance (APERF/MPERF%) during the >sample interval. Needs msr/aperf/ and msr/mperf/ events. > > Here is an example: other than my latest 2 comments, I'm ok with the patchset jirka -- 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] spi: mediatek: fix spi cs polarity error
Mediatek spi HW can't set cs inactive(keep cs high) directly.
Instead, it supplies pause mode to do it indirectly. If driver
unsets SPI_CMD_PAUSE_MODE in CMD_REG, it also needs to reset
internal state machine to let cs inactive at once.
Signed-off-by: Leilk Liu
---
drivers/spi/spi-mt65xx.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 401e2e0..ba0fc10 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -173,22 +173,6 @@ static void mtk_spi_config(struct mtk_spi *mdata,
writel(mdata->pad_sel, mdata->base + SPI_PAD_SEL_REG);
}
-static int mtk_spi_prepare_hardware(struct spi_master *master)
-{
- struct spi_transfer *trans;
- struct mtk_spi *mdata = spi_master_get_devdata(master);
- struct spi_message *msg = master->cur_msg;
-
- trans = list_first_entry(&msg->transfers, struct spi_transfer,
-transfer_list);
- if (!trans->cs_change) {
- mdata->state = MTK_SPI_IDLE;
- mtk_spi_reset(mdata);
- }
-
- return 0;
-}
-
static int mtk_spi_prepare_message(struct spi_master *master,
struct spi_message *msg)
{
@@ -228,11 +212,15 @@ static void mtk_spi_set_cs(struct spi_device *spi, bool
enable)
struct mtk_spi *mdata = spi_master_get_devdata(spi->master);
reg_val = readl(mdata->base + SPI_CMD_REG);
- if (!enable)
+ if (!enable) {
reg_val |= SPI_CMD_PAUSE_EN;
- else
+ writel(reg_val, mdata->base + SPI_CMD_REG);
+ } else {
reg_val &= ~SPI_CMD_PAUSE_EN;
- writel(reg_val, mdata->base + SPI_CMD_REG);
+ writel(reg_val, mdata->base + SPI_CMD_REG);
+ mdata->state = MTK_SPI_IDLE;
+ mtk_spi_reset(mdata);
+ }
}
static void mtk_spi_prepare_transfer(struct spi_master *master,
@@ -509,7 +497,6 @@ static int mtk_spi_probe(struct platform_device *pdev)
master->mode_bits = SPI_CPOL | SPI_CPHA;
master->set_cs = mtk_spi_set_cs;
- master->prepare_transfer_hardware = mtk_spi_prepare_hardware;
master->prepare_message = mtk_spi_prepare_message;
master->transfer_one = mtk_spi_transfer_one;
master->can_dma = mtk_spi_can_dma;
--
1.8.1.1.dirty
--
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/
Multiple potential races on vma->vm_flags
On Sun, Sep 06, 2015 at 03:21:05PM -0400, Sasha Levin wrote: > == > ThreadSanitizer: data-race in munlock_vma_pages_range > > Write of size 8 by thread T378 (K2633, CPU3): > [] munlock_vma_pages_range+0x59/0x3e0 mm/mlock.c:425 > [] mlock_fixup+0x1c9/0x280 mm/mlock.c:549 > [] do_mlock+0x14c/0x180 mm/mlock.c:589 > [< inlined>] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651 > [] SyS_munlock+0x74/0xb0 mm/mlock.c:643 > [] entry_SYSCALL_64_fastpath+0x12/0x71 > arch/x86/entry/entry_64.S:186 ... > Previous read of size 8 by thread T398 (K2623, CPU2): > [] try_to_unmap_one+0x78/0x4f0 mm/rmap.c:1208 > [< inlined>] rmap_walk+0x147/0x450 rmap_walk_file mm/rmap.c:1540 > [] rmap_walk+0x147/0x450 mm/rmap.c:1559 > [] try_to_munlock+0xa2/0xc0 mm/rmap.c:1423 > [] __munlock_isolated_page+0x30/0x60 mm/mlock.c:129 > [] __munlock_pagevec+0x236/0x3f0 mm/mlock.c:331 > [] munlock_vma_pages_range+0x380/0x3e0 mm/mlock.c:476 > [] mlock_fixup+0x1c9/0x280 mm/mlock.c:549 > [] do_mlock+0x14c/0x180 mm/mlock.c:589 > [< inlined>] SyS_munlock+0x74/0xb0 SYSC_munlock mm/mlock.c:651 > [] SyS_munlock+0x74/0xb0 mm/mlock.c:643 > [] entry_SYSCALL_64_fastpath+0x12/0x71 > arch/x86/entry/entry_64.S:186 Okay, the detected race is mlock/munlock vs. rmap. On rmap side we check vma->vm_flags in few places without taking vma->vm_mm->mmap_sem. The vma cannot be freed since we hold i_mmap_rwsem or anon_vma_lock, but nothing prevent vma->vm_flags from changing under us. In this particular case, speculative check in beginning of try_to_unmap_one() is fine, since we re-check it under mmap_sem later in the function. False-negative is fine too here, since we will mlock the page in __mm_populate() on mlock side after mlock_fixup(). BUT. We *must* have all speculative vm_flags accesses wrapped READ_ONCE() to avoid all compiler trickery, like duplication vm_flags access with inconsistent results. I looked only on VM_LOCKED checks, but there are few other flags checked in rmap. All of them must be handled carefully. At least READ_ONCE() is required. Other solution would be to introduce per-vma spinlock to protect vma->vm_flags and probably other vma fields and offload this duty from mmap_sem. But that's much bigger project. -- Kirill A. Shutemov -- 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] ARM: fix bug which lowmem size is limited to 760MB
On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote: > If 768MB targets were common place then it could be worth changing the > default vmalloc size to accommodate this memory size and testing all the > other targets to make sure no regressions are introduced. But given it > is easy to change the default via the kernel cmdline, and that you lose > only 8 MB otherwise, I don't think it is worth the trouble and/or the > risk. Agreed. Given how much more common 1GB hardware configurations are compared to 768MB configuration, we could however think about adding a VMSPLIT_3G_OPT option that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire 1GB of lowmem without going all the way to VMSPLIT_2G. That option would also let us use the entire 768MB on the machines that Yongtaek Lee is interested in. Arnd -- 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 0/7] gpio: omap: fixes and improvements
+Cc: Austin, Philipp On 08/26/2015 10:53 AM, Linus Walleij wrote: On Tue, Aug 18, 2015 at 1:10 PM, Grygorii Strashko wrote: This patch series contains set of trivial fixes and improvements, and also patches which fixes wrong APIs usage in atomic context as for -RT as for non-RT kernel. The final goal of this series is to make TI OMAP GPIO driver compatible with -RT kernel as much as possible. Patch 1-4: trivial fixes and improvements Patch 5: fixes wrong CLK clk_prepare/unprepare APIs usage in atomic contexet I've applied patches 1-5 with Santosh's ACK and Tony's Tested-by. Patch 6(rfc): required to be compatible with -RT kernel, because PM runtime can't be used in atimic context on -RT. Patch 7(rfc): This patch converts TI OMAP GPIO driver to use generic irq handler instead of chained IRQ handler. This way OMAP GPIO driver will be compatible with RT kernel where it will be forced thread IRQ handler while in non-RT kernel it still will be executed in HW IRQ context. Waiting for more feedback here. Yours, Linus Walleij I've got some feedback here. Patches were tested on to of TI -RT tree ti-rt-linux-4.1.y. Forwarded Message Subject: Re: [PATCH 0/7] gpio: omap: fixes and improvements Date: Fri, 4 Sep 2015 21:42:03 + From: Austin Schuh To: grygorii.stras...@ti.com CC: Philipp Schrader Hi Grygorii, We are running the entire patchset on top of a7a6541db840cc4514a26fc12cc1bc94d1b9e873 from the git:// git.ti.com/ti-linux-kernel/ti-linux-kernel.git tree. I've pushed the system pretty hard overnight and haven't seen any instability (with lockdep enabled. We used to get splats pretty fast). I wasn't on lkml when you sent the patchset out, so I'm not sure how to best reply to the original thread with this info. Tested-by: Austin Schuh Austin Forwarded Message -- regards, -grygorii -- 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: perf: fuzzer PEBS record without PEBS event! crash
On Mon, Sep 7, 2015 at 2:44 AM, Vince Weaver wrote: > On Sun, 6 Sep 2015, Stephane Eranian wrote: > >> > [ 1800.285152] [ cut here ] >> > [ 1800.290757] WARNING: CPU: 0 PID: 0 at >> > arch/x86/kernel/cpu/perf_event_intel_ds.c:1210 >> > intel_pmu_drain_pebs_nhm+0x305/0x320() >> > [ 1800.303301] PEBS record without PEBS event! status=2 pebs_enabled=1 >> > active_mask=2 >> > [ 1800.311916] Modules linked in: binfmt_misc intel_rapl iosf_mbi >> > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm >> > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi hmac >> > drbg ansi_cprng i915 aesni_intel aes_x86_64 snd_hda_codec_realtek >> > snd_hda_codec_generic lrw snd_hda_intel snd_hda_codec iTCO_wdt gf128mul >> > drm_kms_helper snd_hda_core ppdev iTCO_vendor_support evdev glue_helper >> > ablk_helper cryptd parport_pc snd_hwdep snd_pcm snd_timer psmouse tpm_tis >> > tpm drm i2c_algo_bit sg parport snd pcspkr video serio_raw processor >> > soundcore mei_me lpc_ich mfd_core mei i2c_i801 wmi button battery sr_mod >> > sd_mod cdrom ehci_pci ehci_hcd xhci_pci xhci_hcd ahci libahci libata >> > e1000e ptp usbcore crc32c_intel scsi_mod pps_core usb_common fan thermal >> > [ 1800.390813] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW >> > 4.2.0+ #173 >> > [ 1800.399488] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS >> > 01/26/2014 >> > [ 1800.408243] 81a0d828 88011ea03aa8 8169da0c >> > 88011ea03af0 >> > [ 1800.417089] 88011ea03ae0 8106e812 0001 >> > 88011900 >> > [ 1800.426024] 88011ea0c120 88011900ffc0 88011900 >> > 88011ea03b40 >> > [ 1800.434946] Call Trace: >> > [ 1800.438453][] dump_stack+0x44/0x55 >> > [ 1800.445504] [] warn_slowpath_common+0x82/0xc0 >> > [ 1800.452832] [] warn_slowpath_fmt+0x4c/0x50 >> > [ 1800.459879] [] intel_pmu_drain_pebs_nhm+0x305/0x320 >> > [ 1800.467725] [] ? __lock_acquire.isra.31+0x349/0xfc0 >> > [ 1800.475613] [] intel_pmu_drain_pebs_buffer+0x18/0x20 >> >> >> What would help here is if you could get the source line number. You can do >> that >> with gdb: >> gdb vmlinux >> (gdb) info line *0x8102ec38 > > (gdb) info line *0x8102ec38 > Line 567 of "arch/x86/kernel/cpu/perf_event_intel_ds.c" >starts at address 0x8102ec38 >and ends at 0x8102ec40 . > > Line 567 isn't that helpful, it's just the last line of > intel_pmu_drain_pebs_buffer() but that's possibly because I have done a > git pull since the time I built the kernel so the source tree doesn't > match up. > Do it again with the matching source tree. Addresses change all the time. > Vince -- 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 00/13] USB: OTG/DRD Core functionality
On 06/09/15 10:06, Peter Chen wrote: > On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote: >> Hi, >> >> This series centralizes OTG/Dual-role functionality in the kernel. >> As of now I've got Dual-role functionality working pretty reliably on >> dra7-evm and am437x-gp-evm. >> >> DWC3 controller and platform related patches will be sent separately. >> >> Series is based on Greg's usb-next tree. >> >> Changelog: >> - >> v4: >> - Added DT support for tying otg-controller to host and gadget >> controllers. For DT we no longer have the constraint that >> OTG controller needs to be parent of host and gadget. They can be >> tied together using the "otg-controller" property. >> - Relax the requirement for DT case that otg controller must register before >> host/gadget. We maintain a wait list of host/gadget devices >> waiting on the otg controller. >> - Use a single struct usb_otg for otg data. >> - Don't override host/gadget start/stop APIs. Let the controller >> drivers do what they want as they know best. Helper API is provided >> for controller start/stop that controller driver can use. >> - Introduce struct usb_otg_config to pass the otg capabilities, >> otg ops and otg timer timeouts during otg controller registration. >> - rebased on Greg's usb.git/usb-next > > Roger, thanks for your hard work. Since it is complicated, and can't > know its correctness and scalable well just reading code. I will run > it for chipidea driver, wait some time please. No problem and thanks for the tests. cheers, -roger > > Peter >> >> v3: >> - all otg related definations now in otg.h >> - single kernel config USB_OTG to enable OTG core and FSM. >> - resolved symbol dependency issues. >> - use dev_vdbg instead of VDBG() in usb-otg-fsm.c >> - rebased on v4.2-rc1 >> >> v2: >> - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable >> the host controller >> - added dual-role-device (DRD) state machine which is a much simpler >> mode of operation when compared to OTG. Here we don't support fancy >> OTG features like HNP, SRP, on the fly role-swap. The mode of operation >> is determined based on ID pin (cable type) and the role doesn't change >> till the cable type changes. >> >> Why?: >> >> >> Most of the OTG drivers have been dealing with the OTG state machine >> themselves and there is a scope for code re-use. This has been >> partly addressed by the usb/common/usb-otg-fsm.c but it still >> leaves the instantiation of the state machine and OTG timers >> to the controller drivers. We re-use usb-otg-fsm.c but >> go one step further by instantiating the state machine and timers >> thus making it easier for drivers to implement OTG functionality. >> >> Newer OTG cores support standard host interface (e.g. xHCI) so >> host and gadget functionality are no longer closely knit like older >> cores. There needs to be a way to co-ordinate the operation of the >> host and gadget in OTG mode. i.e. to stop and start them from a >> central location. This central location should be the USB OTG core. >> >> Host and gadget controllers might be sharing resources and can't >> be always running. One has to be stopped for the other to run. >> This can't be done as of now and can be done from the OTG core. >> >> What?: >> - >> >> The OTG core instantiates the OTG/DRD Finite State Machine >> per OTG controller and manages starting/stopping the >> host and gadget controllers based on the bus state. >> >> It provides APIs for the following >> >> - Registering an OTG capable controller >> struct otg_fsm *usb_otg_register(struct device *dev, >> struct usb_otg_config *config); >> >> int usb_otg_unregister(struct device *dev); >> >> - Registering Host controllers to OTG core (used by hcd-core) >> int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum, >> unsigned long irqflags, struct otg_hcd_ops *ops); >> int usb_otg_unregister_hcd(struct usb_hcd *hcd); >> >> >> - Registering Gadget controllers to OTG core (used by udc-core) >> int usb_otg_register_gadget(struct usb_gadget *gadget, >> struct otg_gadget_ops *ops); >> int usb_otg_unregister_gadget(struct usb_gadget *gadget); >> >> >> - Providing inputs to and kicking the OTG state machine >> void usb_otg_sync_inputs(struct otg_fsm *fsm); >> int usb_otg_kick_fsm(struct device *hcd_gcd_device); >> >> - Getting controller device structure from OTG state machine instance >> struct device *usb_otg_fsm_to_dev(struct otg_fsm *fsm); >> >> 'struct otg_fsm' is the interface to the OTG state machine. >> It contains inputs to the fsm, status of the fsm and operations >> for the OTG controller driver. >> >> - Helper APIs for starting/stopping host/gadget controllers >> int usb_otg_start_host(struct otg_fsm *fsm, int on); >> int usb_otg_start_gadget(struct otg_fsm *fsm, int on); >> >> Usage model: >> --- >> >> - The OTG core needs to know what host and g
Re: [PATCH 2/6] perf, tools, stat: Abstract stat metrics printing
On Fri, Sep 04, 2015 at 03:45:13PM -0700, Andi Kleen wrote: SNIP > @@ -695,11 +743,7 @@ static void print_counter_aggr(struct perf_evsel > *counter, char *prefix) > } > > uval = avg * counter->scale; > - > - if (nsec_counter(counter)) > - nsec_printout(-1, 0, counter, uval); > - else > - abs_printout(-1, 0, counter, uval); > + printout(-1, 0, counter, uval); > > print_noise(counter, avg); > > @@ -752,15 +796,9 @@ static void print_counter(struct perf_evsel *counter, > char *prefix) > } > > uval = val * counter->scale; > - > - if (nsec_counter(counter)) > - nsec_printout(cpu, 0, counter, uval); > - else > - abs_printout(cpu, 0, counter, uval); > - > + printout(cpu, 0, counter, uval); > if (!csv_output) > print_noise(counter, 1.0); > - print_running(run, ena); why is this one removed? jirka -- 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 5/7] staging: board: Add support for devices with complex dependencies
On 4 September 2015 at 17:03, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Fri, 4 Sep 2015, Ulf Hansson wrote:
>> On 3 September 2015 at 15:35, Geert Uytterhoeven
>> wrote:
>> > On Thu, Sep 3, 2015 at 2:53 PM, Ulf Hansson wrote:
>> >> On 17 June 2015 at 10:38, Geert Uytterhoeven
>> >> wrote:
>> >>> Add support for easy registering of one ore more platform devices that
>> >>> may:
>> >>> - need clocks that are described in DT,
>> >>> - be part of a PM Domain.
>> >
>> >>> diff --git a/drivers/staging/board/board.c
>> >>> b/drivers/staging/board/board.c
>> >>> index 8712f566b31196e0..29d456e29f38feac 100644
>> >>> --- a/drivers/staging/board/board.c
>> >>> +++ b/drivers/staging/board/board.c
>> >
>> >>> +int __init board_staging_register_device(const struct board_staging_dev
>> >>> *dev)
>> >>> +{
>> >>> + struct platform_device *pdev = dev->pdev;
>> >>> + unsigned int i;
>> >>> + int error;
>> >>> +
>> >>> + pr_debug("Trying to register device %s\n", pdev->name);
>> >>> + if (board_staging_dt_node_available(pdev->resource,
>> >>> + pdev->num_resources)) {
>> >>> + pr_warn("Skipping %s, already in DT\n", pdev->name);
>> >>> + return -EEXIST;
>> >>> + }
>> >>> +
>> >>> + board_staging_gic_fixup_resources(pdev->resource,
>> >>> pdev->num_resources);
>> >>> +
>> >>> + for (i = 0; i < dev->nclocks; i++)
>> >>> + board_staging_register_clock(&dev->clocks[i]);
>> >>> +
>> >>> + error = platform_device_register(pdev);
>> >>> + if (error) {
>> >>> + pr_err("Failed to register device %s (%d)\n", pdev->name,
>> >>> + error);
>> >>> + return error;
>> >>> + }
>> >>> +
>> >>> + if (dev->domain)
>> >>> + __pm_genpd_name_add_device(dev->domain, &pdev->dev,
>> >>> NULL);
>> >>
>> >> Urgh, this managed to slip through my filters.
>> >>
>> >> It seems like we almost managed to remove all users of the
>> >> "..._name_add..." APIs for genpd. If hasn't been for $subject patch.
>> >> :-)
>> >>
>> >> Now, I realize this is already too late here, but let's try to fix
>> >> this before it turns into a bigger issue.
>> >>
>> >> Geert, do you think it's possible to convert into using the non-named
>> >> bases APIs?
>> >
>> > That will be difficult. This code is meant to use drivers that are not yet
>> > DT-aware on DT-based systems. Hence it uses platform devices with named PM
>> > domains, while the PM domains are described in DT.
>> > I don't think there's another way to look up a PM domain by name, is there?
>>
>> As a matter of fact there are, especially for those genpds that has
>> been created through DT as in this case. The API to use is
>> of_genpd_get_from_provider() to find the struct generic_pm_domain.
>
> Thanks!
>
>> Yes, I do realize that you need to manage the parsing of the domain
>> name to make sure it's the one you want, but I would rather keep that
>> "hack" in this driver than in the generic API.
>
> OK. It turned out not to be that complex, cfr. the patch below.
> For now this supports PM domains with "#power-domain-cells = <0>" only,
> but of course it can be extended if the need arises.
>
> I've also tried:
>
> np = of_find_compatible_node(NULL, NULL, "renesas,sysc-rmobile");
> np = of_find_node_by_name(np, "a4lc");
>
> (the second step is needed because of the domain hierarchy in DT), but that
> would require adding the compatible string to struct board_staging_dev,
> and doesn't work if you have multiple identical power providers.
>
> I hope you like it?
>
> From 5fb11904845eb929a5b3382a9d5153c151cde1cf Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven
> Date: Fri, 4 Sep 2015 16:52:33 +0200
> Subject: [PATCH/RFC] staging: board: Migrate away from
> __pm_genpd_name_add_device()
>
> The named genpd APIs are deprecated. Hence convert the board staging
> code from using genpd names to DT node paths.
>
> For now this supports PM domains with "#power-domain-cells = <0>" only.
>
> Signed-off-by: Geert Uytterhoeven
Geert, thanks for posting this patch!
I wonder whether we could get this sent for the 4.3 rc[n], since that
would enable us to remove some of the named based API for genpd
through Rafael's linux-pm tree during this release cycle.
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/staging/board/armadillo800eva.c | 2 +-
> drivers/staging/board/board.c | 36
> -
> 2 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/board/armadillo800eva.c
> b/drivers/staging/board/armadillo800eva.c
> index 0165591a52443c46..912c96b0536def7c 100644
> --- a/drivers/staging/board/armadillo800eva.c
> +++ b/drivers/staging/board/armadillo800eva.c
> @@ -91,7 +91,7 @@ static const struct board_staging_dev
> armadillo800eva_devices[] __initconst = {
> .pdev = &lcdc0_dev
[PATCH v4] usb: chipidea: Use extcon framework for VBUS and ID detect
On recent Qualcomm platforms VBUS and ID lines are not routed to
USB PHY LINK controller. Use extcon framework to receive connect
and disconnect ID and VBUS notification.
Signed-off-by: Ivan T. Ivanov
---
Changes sice v3 [1]:
* Migrate to new extcon framework API
* Address comments from Peter Chen.
Tested DRD role with "qcom,ci-hdrc" and "qcom,usb-8x16-phy" on DB410c
[1] https://lkml.org/lkml/2015/6/2/333
.../devicetree/bindings/usb/ci-hdrc-usb2.txt | 6 +
drivers/usb/chipidea/Kconfig | 1 +
drivers/usb/chipidea/core.c| 125 +
drivers/usb/chipidea/otg.c | 39 ++-
include/linux/usb/chipidea.h | 23
5 files changed, 193 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index d71ef07bca5d..aea7d0af5fd6 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -45,6 +45,11 @@ Optional properties:
(4 bytes), This register represents the maximum length of a the burst
in 32-bit words while moving data from the USB bus to system memory,
changing this value takes effect only the SBUSCFG.AHBBRST is 0.
+- extcon: phandles to external connector devices. First phandle should point to
+ external connector, which provide "USB" cable events, the second should point
+ to external connector device, which provide "USB-HOST" cable events. If one
+ of the external connector devices is not required, empty <0> phandle should
+ be specified.
Example:
@@ -61,4 +66,5 @@ Example:
ahb-burst-config = <0x0>;
tx-burst-size-dword = <0x10>; /* 64 bytes */
rx-burst-size-dword = <0x10>;
+ extcon = <0>, <&usb_id>;
};
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 5ce3f1d6a6ed..5619b8ca3bf3 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -1,6 +1,7 @@
config USB_CHIPIDEA
tristate "ChipIdea Highspeed Dual Role Controller"
depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD &&
!USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
+ select EXTCON
help
Say Y here if your system has a dual role high speed USB
controller based on ChipIdea silicon IP. Currently, only the
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3feebf7f31f0..573c2876b263 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -602,9 +603,45 @@ static irqreturn_t ci_irq(int irq, void *data)
return ret;
}
+static int ci_vbus_notifier(struct notifier_block *nb, unsigned long event,
+ void *ptr)
+{
+ struct ci_hdrc_cable *vbus = container_of(nb, struct ci_hdrc_cable, nb);
+ struct ci_hdrc *ci = vbus->ci;
+
+ if (event)
+ vbus->state = true;
+ else
+ vbus->state = false;
+
+ vbus->changed = true;
+
+ ci_irq(ci->irq, ci);
+ return NOTIFY_DONE;
+}
+
+static int ci_id_notifier(struct notifier_block *nb, unsigned long event,
+ void *ptr)
+{
+ struct ci_hdrc_cable *id = container_of(nb, struct ci_hdrc_cable, nb);
+ struct ci_hdrc *ci = id->ci;
+
+ if (event)
+ id->state = false;
+ else
+ id->state = true;
+
+ id->changed = true;
+
+ ci_irq(ci->irq, ci);
+ return NOTIFY_DONE;
+}
+
static int ci_get_platdata(struct device *dev,
struct ci_hdrc_platform_data *platdata)
{
+ struct extcon_dev *ext_vbus, *ext_id;
+ struct ci_hdrc_cable *cable;
int ret;
if (!platdata->phy_mode)
@@ -695,9 +732,91 @@ static int ci_get_platdata(struct device *dev,
platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
}
+ ext_id = ERR_PTR(-ENODEV);
+ ext_vbus = ERR_PTR(-ENODEV);
+ if (of_property_read_bool(dev->of_node, "extcon")) {
+ /* Each one of them is not mandatory */
+ ext_vbus = extcon_get_edev_by_phandle(dev, 0);
+ if (IS_ERR(ext_vbus) && PTR_ERR(ext_vbus) != -ENODEV)
+ return PTR_ERR(ext_vbus);
+
+ ext_id = extcon_get_edev_by_phandle(dev, 1);
+ if (IS_ERR(ext_id) && PTR_ERR(ext_id) != -ENODEV)
+ return PTR_ERR(ext_id);
+ }
+
+ cable = &platdata->vbus_extcon;
+ cable->nb.notifier_call = ci_vbus_notifier;
+ cable->edev = ext_vbus;
+
+ if (!IS_ERR(ext_vbus)) {
+ ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
+ if (ret)
+ cable->state = true;
+ else
+
Re: [PATCH v3] usb: chipidea: Use extcon framework for VBUS and ID detect
On Fri, 2015-06-05 at 17:26 +0800, Peter Chen wrote:
> On Fri, Jun 05, 2015 at 10:37:07AM +0300, Ivan T. Ivanov wrote:
>
> > > > +
> > > > +static int ci_id_notifier(struct notifier_block *nb, unsigned long
> > > > event,
> > > > + void *ptr)
> > > > +{
> > > > + struct ci_hdrc_cable *id = container_of(nb, struct
> > > > ci_hdrc_cable, nb);
> > > > + struct ci_hdrc *ci = id->ci;
> > > > +
> > > > + if (event)
> > > > + id->state = false;
> > > > + else
> > > > + id->state = true;
> > > > +
> > > > + id->changed = true;
> > > > +
>
> How to know the id value must be changed?
> How about using id->changed = (event != id->state) ? true : false?
> of cos, it needs to move before if {}.
This is handled already by extcon framework.
>
> The same change may need to add to vbus notifier.
>
> > > > + ci_irq(ci->irq, ci);
> > > > + return NOTIFY_DONE;
> > > > +}
> > > > +
> > > > static int ci_get_platdata(struct device *dev,
> > > > struct ci_hdrc_platform_data *platdata)
> > > > {
> > > > + struct extcon_dev *ext_vbus, *ext_id;
> > > > + struct ci_hdrc_cable *cable;
> > > > + int ret;
> > > > +
> > > > if (!platdata->phy_mode)
> > > > platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
> > > >
> > > > @@ -591,9 +630,89 @@ static int ci_get_platdata(struct device *dev,
> > > > if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
> > > > platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
> > > >
> > > > + ext_id = ERR_PTR(-ENODEV);
> > > > + ext_vbus = ERR_PTR(-ENODEV);
> > > > + if (of_property_read_bool(dev->of_node, "extcon")) {
> > > > + /* Each one of them is not mandatory */
> > > > + ext_vbus = extcon_get_edev_by_phandle(dev, 0);
> > > > + if (IS_ERR(ext_vbus) && PTR_ERR(ext_vbus) != -ENODEV)
> > > > + return PTR_ERR(ext_vbus);
> > > > +
> > > > + ext_id = extcon_get_edev_by_phandle(dev, 1);
> > > > + if (IS_ERR(ext_id) && PTR_ERR(ext_id) != -ENODEV)
> > > > + return PTR_ERR(ext_id);
> > > > + }
> > > > +
> > > > + cable = &platdata->vbus_extcon;
> > > > + cable->nb.notifier_call = ci_vbus_notifier;
> > > > + cable->edev = ext_vbus;
> > > > +
> > > > + if (!IS_ERR(ext_vbus)) {
> > > > + ret = extcon_get_cable_state(cable->edev, "USB");
>
> I have not read extcon framework too much, but seems you should only
> can get cable state after register it (through ci_extcon_register)?
> ci_get_platdata is called before ci core probe.
No that is not a problem, you can always read cable state if you have
reference to extcon device.
Will fix remaining comments in next version.
Regards,
Ivan
--
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 0/2] drm/dsi: DSI for devices with different control bus
Thierry,
On 08/21/2015 11:39 AM, Archit Taneja wrote:
On 08/20/2015 05:18 PM, Thierry Reding wrote:
On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
Hi Thierry, Lucas,
On 08/19/2015 08:32 PM, Thierry Reding wrote:
On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
Hi Thierry, Archit,
[...]
Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:
i2c@... {
...
dsi-device@... {
...
dsi-bus = <&dsi>;
...
};
...
};
dsi@... {
...
};
Inversing the relationship would become something like this:
i2c@... {
...
};
dsi@... {
...
peripheral@... {
...
i2c-bus = <&i2c>;
...
};
...
};
Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).
So how about we create two devices in the device tree and fuse
them at
the driver level:
i2c@... {
...
i2cdsi: dsi-device@... {
...
};
...
};
dsi@... {
...
peripheral@... {
...
control = <&i2cdsi>;
...
};
...
};
This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.
I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.
Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.
I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.
Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?
The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.
If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)
The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two logical devices to DT (one for each bus interface), you don't
have
anything to glue together with an OF graph.
I see that the having dummy device is the least desirable solution.
But
if there is only one control bus to the device I think it should be
one
device sitting beneath the control bus.
You can then use of-graph to model the data path between the DSI
encoder
and device.
But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to
Thanks for the review.
I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.
There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:
i2c_adap@.. {
adv7533@.. {
port {
adv_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
};
};
dsi_host@.. {
...
...
port {
dsi_out: endpoint {
remote-endpoint = <&adv_in>;
}
};
};
It's the i2c driver's job to parse the graph and retrieve the
phandle to the dsi host. Using this, it can proceed with
registering itself to this host using the new dsi funcs. This
patch does the same for the adv7533 i2c driver:
http://www.spinics.net/lists/dri-devel/msg86840.html
hook up with a control endpoint. And then you'll need more quirks
to describe what kind of DSI device this is.
Could you explain what you meant by this? I.e. describing
Re: Kernel 4.1.6 Panic due to slab corruption
On Mon, 07 Sep 2015 14:30:49 +0300, Nikolay Borisov wrote: > If you have the vmlinux image for the kernel you were running at the > time, the crash occured, could you post the output of addr2line -f -e > path/to/vmlinux 8115bd4d to see if it also fails in > get_freepointer. Had to rebuild to get an uncompressed vmlinux, but here it is: holger>addr2line -f -e vmlinux 8115bd4d kmem_cache_alloc ??:? Not sure how much we can learn from this. :} -h -- 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] drm/mgag200: fix memory leak
If drm_fb_helper_alloc_fbi() fails then we were directly returning
without freeing sysram. Also if drm_fb_helper_alloc_fbi() succeeds but
mgag200_framebuffer_init() fails then we were not releasing sysram and
we were not releasing fbi helper also.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 87de15e..5fe476a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -189,14 +189,16 @@ static int mgag200fb_create(struct drm_fb_helper *helper,
return -ENOMEM;
info = drm_fb_helper_alloc_fbi(helper);
- if (IS_ERR(info))
- return PTR_ERR(info);
+ if (IS_ERR(info)) {
+ ret = PTR_ERR(info);
+ goto err_alloc_fbi;
+ }
info->par = mfbdev;
ret = mgag200_framebuffer_init(dev, &mfbdev->mfb, &mode_cmd, gobj);
if (ret)
- return ret;
+ goto err_framebuffer_init;
mfbdev->sysram = sysram;
mfbdev->size = size;
@@ -226,6 +228,13 @@ static int mgag200fb_create(struct drm_fb_helper *helper,
DRM_DEBUG_KMS("allocated %dx%d\n",
fb->width, fb->height);
return 0;
+
+err_framebuffer_init:
+ drm_fb_helper_release_fbi(helper);
+
+err_alloc_fbi:
+ vfree(sysram);
+ return ret;
}
static int mga_fbdev_destroy(struct drm_device *dev,
--
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: Kernel 4.1.6 Panic due to slab corruption
On Mon, 07 Sep 2015 11:49:12 +, Holger Hoffstätte wrote: > On Mon, 07 Sep 2015 14:30:49 +0300, Nikolay Borisov wrote: > >> If you have the vmlinux image for the kernel you were running at the >> time, the crash occured, could you post the output of addr2line -f -e >> path/to/vmlinux 8115bd4d to see if it also fails in >> get_freepointer. > > Had to rebuild to get an uncompressed vmlinux, but here it is: > > holger>addr2line -f -e vmlinux 8115bd4d > kmem_cache_alloc > ??:? > > Not sure how much we can learn from this. :} Also for what it's worth the related splatter is all in the same place: holger>zgrep 8115bd4d /var/log/kern.log.0.gz Sep 5 20:42:02 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:03 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:03 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:03 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:10 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:10 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:10 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:10 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:10 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:10 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 CPU is a 4 core HT i7 (aka 8 vcores), and so I have 8 splats. thanks, Holger -- 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 1/3] mmc: sdhci-pxav3: Fix tabbing issue
On Mon, 7 Sep 2015 17:01:09 +0530
Vaibhav Hiremath wrote:
> There were some coding style issues where spaces have been used instead
> of tabs, for example, in macro definitions, alignment of function
> declarations/definitions, etc...
>
> This patch fixes all such occurrences in the code.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/mmc/host/sdhci-pxav3.c | 46
> +-
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index 946d37f..7a07177 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -39,24 +39,24 @@
> #include "sdhci.h"
> #include "sdhci-pltfm.h"
>
> -#define PXAV3_RPM_DELAY_MS 50
> +#define PXAV3_RPM_DELAY_MS 50
>
> -#define SD_CLOCK_BURST_SIZE_SETUP0x10A
> -#define SDCLK_SEL0x100
> -#define SDCLK_DELAY_SHIFT9
> -#define SDCLK_DELAY_MASK 0x1f
> +#define SD_CLOCK_BURST_SIZE_SETUP0x10A
> +#define SDCLK_SEL0x100
> +#define SDCLK_DELAY_SHIFT 9
> +#define SDCLK_DELAY_MASK0x1f
>
> -#define SD_CFG_FIFO_PARAM 0x100
> -#define SDCFG_GEN_PAD_CLK_ON (1<<6)
> -#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
> -#define SDCFG_GEN_PAD_CLK_CNT_SHIFT 24
> +#define SD_CFG_FIFO_PARAM0x100
> +#define SDCFG_GEN_PAD_CLK_ON(1<<6)
> +#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
> +#define SDCFG_GEN_PAD_CLK_CNT_SHIFT 24
>
> -#define SD_SPI_MODE 0x108
> -#define SD_CE_ATA_1 0x10C
> +#define SD_SPI_MODE 0x108
> +#define SD_CE_ATA_1 0x10C
>
> -#define SD_CE_ATA_2 0x10E
> -#define SDCE_MISC_INT(1<<2)
> -#define SDCE_MISC_INT_EN (1<<1)
> +#define SD_CE_ATA_2 0x10E
> +#define SDCE_MISC_INT (1<<2)
> +#define SDCE_MISC_INT_EN(1<<1)
>
> struct sdhci_pxa {
> struct clk *clk_core;
> @@ -284,7 +284,7 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
> *host, unsigned int uhs)
>* FE-2946959
>*/
> if (pxa->sdio3_conf_reg) {
> - u8 reg_val = readb(pxa->sdio3_conf_reg);
> + u8 reg_val = readb(pxa->sdio3_conf_reg);
>
> if (uhs == MMC_TIMING_UHS_SDR50 ||
> uhs == MMC_TIMING_UHS_DDR50) {
> @@ -304,20 +304,20 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
> *host, unsigned int uhs)
> }
>
> static const struct sdhci_ops pxav3_sdhci_ops = {
> - .set_clock = sdhci_set_clock,
> - .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> - .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> - .set_bus_width = sdhci_set_bus_width,
> - .reset = pxav3_reset,
> - .set_uhs_signaling = pxav3_set_uhs_signaling,
> + .set_clock = sdhci_set_clock,
> + .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> + .set_bus_width = sdhci_set_bus_width,
> + .reset = pxav3_reset,
> + .set_uhs_signaling = pxav3_set_uhs_signaling,
IMHO, this is not an improvement, previous style is fine and I saw
such style in kernel here and there
> };
>
> static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
> - .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
> + .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
> | SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC
> | SDHCI_QUIRK_32BIT_ADMA_SIZE
> | SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> - .ops = &pxav3_sdhci_ops,
> + .ops= &pxav3_sdhci_ops,
ditto
> };
>
> #ifdef CONFIG_OF
--
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 5/7] staging: board: Add support for devices with complex dependencies
Hi Ulf,
On Mon, Sep 7, 2015 at 1:45 PM, Ulf Hansson wrote:
> On 4 September 2015 at 17:03, Geert Uytterhoeven wrote:
>> On Fri, 4 Sep 2015, Ulf Hansson wrote:
>>> On 3 September 2015 at 15:35, Geert Uytterhoeven
>>> wrote:
>>> > On Thu, Sep 3, 2015 at 2:53 PM, Ulf Hansson
>>> > wrote:
>>> >> On 17 June 2015 at 10:38, Geert Uytterhoeven
>>> >> wrote:
>>> >>> Add support for easy registering of one ore more platform devices that
>>> >>> may:
>>> >>> - need clocks that are described in DT,
>>> >>> - be part of a PM Domain.
>>> >
>>> >>> diff --git a/drivers/staging/board/board.c
>>> >>> b/drivers/staging/board/board.c
>>> >>> index 8712f566b31196e0..29d456e29f38feac 100644
>>> >>> --- a/drivers/staging/board/board.c
>>> >>> +++ b/drivers/staging/board/board.c
>>> >
>>> >>> +int __init board_staging_register_device(const struct
>>> >>> board_staging_dev *dev)
>>> >>> +{
>>> >>> + struct platform_device *pdev = dev->pdev;
>>> >>> + unsigned int i;
>>> >>> + int error;
>>> >>> +
>>> >>> + pr_debug("Trying to register device %s\n", pdev->name);
>>> >>> + if (board_staging_dt_node_available(pdev->resource,
>>> >>> + pdev->num_resources)) {
>>> >>> + pr_warn("Skipping %s, already in DT\n", pdev->name);
>>> >>> + return -EEXIST;
>>> >>> + }
>>> >>> +
>>> >>> + board_staging_gic_fixup_resources(pdev->resource,
>>> >>> pdev->num_resources);
>>> >>> +
>>> >>> + for (i = 0; i < dev->nclocks; i++)
>>> >>> + board_staging_register_clock(&dev->clocks[i]);
>>> >>> +
>>> >>> + error = platform_device_register(pdev);
>>> >>> + if (error) {
>>> >>> + pr_err("Failed to register device %s (%d)\n",
>>> >>> pdev->name,
>>> >>> + error);
>>> >>> + return error;
>>> >>> + }
>>> >>> +
>>> >>> + if (dev->domain)
>>> >>> + __pm_genpd_name_add_device(dev->domain, &pdev->dev,
>>> >>> NULL);
>>> >>
>>> >> Urgh, this managed to slip through my filters.
>>> >>
>>> >> It seems like we almost managed to remove all users of the
>>> >> "..._name_add..." APIs for genpd. If hasn't been for $subject patch.
>>> >> :-)
>>> >>
>>> >> Now, I realize this is already too late here, but let's try to fix
>>> >> this before it turns into a bigger issue.
>>> >>
>>> >> Geert, do you think it's possible to convert into using the non-named
>>> >> bases APIs?
>>> >
>>> > That will be difficult. This code is meant to use drivers that are not yet
>>> > DT-aware on DT-based systems. Hence it uses platform devices with named PM
>>> > domains, while the PM domains are described in DT.
>>> > I don't think there's another way to look up a PM domain by name, is
>>> > there?
>>>
>>> As a matter of fact there are, especially for those genpds that has
>>> been created through DT as in this case. The API to use is
>>> of_genpd_get_from_provider() to find the struct generic_pm_domain.
>>
>> Thanks!
>>
>>> Yes, I do realize that you need to manage the parsing of the domain
>>> name to make sure it's the one you want, but I would rather keep that
>>> "hack" in this driver than in the generic API.
>>
>> OK. It turned out not to be that complex, cfr. the patch below.
>> For now this supports PM domains with "#power-domain-cells = <0>" only,
>> but of course it can be extended if the need arises.
>>
>> I've also tried:
>>
>> np = of_find_compatible_node(NULL, NULL, "renesas,sysc-rmobile");
>> np = of_find_node_by_name(np, "a4lc");
>>
>> (the second step is needed because of the domain hierarchy in DT), but that
>> would require adding the compatible string to struct board_staging_dev,
>> and doesn't work if you have multiple identical power providers.
>>
>> I hope you like it?
>>
>> From 5fb11904845eb929a5b3382a9d5153c151cde1cf Mon Sep 17 00:00:00 2001
>> From: Geert Uytterhoeven
>> Date: Fri, 4 Sep 2015 16:52:33 +0200
>> Subject: [PATCH/RFC] staging: board: Migrate away from
>> __pm_genpd_name_add_device()
>>
>> The named genpd APIs are deprecated. Hence convert the board staging
>> code from using genpd names to DT node paths.
>>
>> For now this supports PM domains with "#power-domain-cells = <0>" only.
>>
>> Signed-off-by: Geert Uytterhoeven
>
> Geert, thanks for posting this patch!
>
> I wonder whether we could get this sent for the 4.3 rc[n], since that
> would enable us to remove some of the named based API for genpd
> through Rafael's linux-pm tree during this release cycle.
>
> Reviewed-by: Ulf Hansson
Thanks!
If GregKH provides his ack, Rafael can take it with your named genpd API
removal series? Shall I resend with an official request?
> Kind regards
> Uffe
>
>> ---
>> drivers/staging/board/armadillo800eva.c | 2 +-
>> drivers/staging/board/board.c | 36
>> -
>> 2 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/board/armadillo800eva.c
>> b/d
[PATCH] tty: fix data race on tty_buffer.commit
Race on buffer data happens when newly committed data is
picked up by an old flush work in the following scenario:
__tty_buffer_request_room does a plain write of tail->commit,
no barriers were executed before that.
At this point flush_to_ldisc reads this new value of commit,
and reads buffer data, no barriers in between.
The committed buffer data is not necessary visible to flush_to_ldisc.
Similar bug happens when tty_schedule_flip commits data.
Update commit with smp_store_release and read commit with
smp_load_acquire, as it is commit that signals data readiness.
This is orthogonal to the existing synchronization on tty_buffer.next,
which is required to not dismiss a buffer with unconsumed data.
The data race was found with KernelThreadSanitizer (KTSAN).
Signed-off-by: Dmitry Vyukov
---
drivers/tty/tty_buffer.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 5a3fa89..0e39d96 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -290,7 +290,10 @@ static int __tty_buffer_request_room(struct tty_port
*port, size_t size,
if (n != NULL) {
n->flags = flags;
buf->tail = n;
- b->commit = b->used;
+ /* paired w/ acquire in flush_to_ldisc(); ensures
+* flush_to_ldisc() sees buffer data.
+*/
+ smp_store_release(&b->commit, b->used);
/* paired w/ acquire in flush_to_ldisc(); ensures the
* latest commit value can be read before the head is
* advanced to the next buffer
@@ -393,7 +396,10 @@ void tty_schedule_flip(struct tty_port *port)
{
struct tty_bufhead *buf = &port->buf;
- buf->tail->commit = buf->tail->used;
+ /* paired w/ acquire in flush_to_ldisc(); ensures
+* flush_to_ldisc() sees buffer data.
+*/
+ smp_store_release(&b->commit, buf->tail->used);
schedule_work(&buf->work);
}
EXPORT_SYMBOL(tty_schedule_flip);
@@ -491,7 +497,10 @@ static void flush_to_ldisc(struct work_struct *work)
* is advancing to the next buffer
*/
next = smp_load_acquire(&head->next);
- count = head->commit - head->read;
+ /* paired w/ release in __tty_buffer_request_room() or in
+* tty_buffer_flush(); ensures we see the committed buffer data
+*/
+ count = smp_load_acquire(&head->commit) - head->read;
if (!count) {
if (next == NULL) {
check_other_closed(tty);
--
2.5.0.457.gab17608
--
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 2/6] perf, tools, stat: Abstract stat metrics printing
On Fri, Sep 04, 2015 at 03:45:13PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> Abstract the printing of shadow metrics. Instead of every
> metric calling fprintf directly and taking care of indentation,
> use two call backs: one to print metrics and another to
> start a new line.
>
> This will allow adding metrics to CSV mode and also
> using them for other purposes.
>
> The computation of padding is now done in the central
> callback, instead of every metric doing it manually.
> This makes it easier to add new metrics.
>
> v2: Refactor functions, printout now does more. Move
> shadow printing. Improve fallback callbacks. Don't
> use void * callback data.
> v3: Remove unnecessary hunk. Add typedef for new_line
> Signed-off-by: Andi Kleen
before this patch:
[jolsa@krava perf]$ ./perf stat -e cycles -I 1000 -x, yes > /dev/null
28.002841829,2907511555,,cycles,1000612137,100.00
29.002944242,2893835898,,cycles,1000615661,100.00
30.003043253,2910405767,,cycles,1000618513,100.00
31.003140585,2909645607,,cycles,1000621442,100.00
32.003244286,2910397988,,cycles,1000624150,100.00
33.003347139,2908927486,,cycles,1000626890,100.00
^C33.581210913,1677490047,,cycles,988203059,100.00
33.581315820,157136,,cycles,959970233,100.00
yes: Interrupt
after this patch:
[jolsa@krava perf]$ ./perf stat -e cycles -I 1000 -x, yes > /dev/null
1.000101739,307467,,cycles # Ghz
,1000247731,100.00
2.000223351,3019361712,,cycles # Ghz
,45890,100.00
3.000327235,3012966500,,cycles # Ghz
,999805678,100.00
4.000430983,3009829158,,cycles # Ghz
,999871044,100.00
I think the reason is that this patch does too much and needs
to be separated to smaller changes, like:
- introduce the print_metrics interface for perf_stat__print_shadow_stats
- introduce printout function
- introduce support for printing metrics in csv in interval mode
- and enable it
or any other way you find feasible *easy to review*.. I cannot ack it at this
state
jirka
> ---
> tools/perf/builtin-stat.c | 100 ++--
> tools/perf/util/stat-shadow.c | 212
> +++---
> tools/perf/util/stat.h| 15 ++-
> 3 files changed, 197 insertions(+), 130 deletions(-)
>
SNIP
> @@ -544,12 +581,32 @@ static void abs_printout(int id, int nr, struct
> perf_evsel *evsel, double avg)
>
> if (evsel->cgrp)
> fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
> +}
>
> - if (csv_output || stat_config.interval)
> - return;
now you printout metrics for interval/csv
> +static void printout(int id, int nr, struct perf_evsel *counter, double uval)
> +{
> + struct outstate os = { .fh = stat_config.output };
> + struct perf_stat_output_ctx out;
> + print_metric_t pm = print_metric_std;
> + void (*nl)(void *);
> +
> + if (stat_config.aggr_mode == AGGR_NONE)
> + nl = new_line_no_aggr_std;
> + else
> + nl = new_line_std;
>
> - perf_stat__print_shadow_stats(output, evsel, avg, cpu,
> - stat_config.aggr_mode);
> + if (nsec_counter(counter))
> + nsec_printout(id, nr, counter, uval);
> + else
> + abs_printout(id, nr, counter, uval);
> +
> + out.print_metric = pm;
> + out.new_line = nl;
> + out.ctx = &os;
> + perf_stat__print_shadow_stats(counter, uval,
> + stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
> + cpu_map__id_to_cpu(id),
> + &out);
> }
>
> static void print_aggr(char *prefix)
> @@ -605,12 +662,7 @@ static void print_aggr(char *prefix)
> continue;
> }
> uval = val * counter->scale;
> -
> - if (nsec_counter(counter))
> - nsec_printout(id, nr, counter, uval);
> - else
> - abs_printout(id, nr, counter, uval);
> -
> + printout(id, nr, counter, uval);
> if (!csv_output)
> print_noise(counter, 1.0);
>
> @@ -641,11 +693,7 @@ static void print_aggr_thread(struct perf_evsel
> *counter, char *prefix)
> fprintf(output, "%s", prefix);
>
> uval = val * counter->scale;
> -
> - if (nsec_counter(counter))
> - nsec_printout(thread, 0, counter, uval);
> - else
> - abs_printout(thread, 0, counter, uval);
> + printout(thread, 0, counter, uval);
>
> if (!csv_output)
> print_noise(counter, 1.0);
> @@ -695,11 +743,7 @@ static void print_counter_aggr(struct perf_evsel
> *counter, char *prefix)
> }
>
>
Re: [PATCHv5 1/7] mm: drop page->slab_page
On Sun, Sep 06, 2015 at 10:00:57PM -0700, Alexander Duyck wrote:
> On 09/03/2015 05:35 AM, Kirill A. Shutemov wrote:
> >Since 8456a648cf44 ("slab: use struct page for slab management") nobody
> >uses slab_page field in struct page.
> >
> >Let's drop it.
> >
> >Signed-off-by: Kirill A. Shutemov
> >Acked-by: Christoph Lameter
> >Acked-by: David Rientjes
> >Acked-by: Vlastimil Babka
> >Cc: Joonsoo Kim
> >Cc: Andi Kleen
> >---
> > include/linux/mm_types.h | 1 -
> > mm/slab.c| 17 +++--
> > 2 files changed, 3 insertions(+), 15 deletions(-)
> >
> >diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> >index 0038ac7466fd..58620ac7f15c 100644
> >--- a/include/linux/mm_types.h
> >+++ b/include/linux/mm_types.h
> >@@ -140,7 +140,6 @@ struct page {
> > #endif
> > };
> >-struct slab *slab_page; /* slab fields */
> > struct rcu_head rcu_head; /* Used by SLAB
> > * when destroying via RCU
> > */
> >diff --git a/mm/slab.c b/mm/slab.c
> >index 200e22412a16..649044f26e5d 100644
> >--- a/mm/slab.c
> >+++ b/mm/slab.c
> >@@ -1888,21 +1888,10 @@ static void slab_destroy(struct kmem_cache *cachep,
> >struct page *page)
> > freelist = page->freelist;
> > slab_destroy_debugcheck(cachep, page);
> >-if (unlikely(cachep->flags & SLAB_DESTROY_BY_RCU)) {
> >-struct rcu_head *head;
> >-
> >-/*
> >- * RCU free overloads the RCU head over the LRU.
> >- * slab_page has been overloeaded over the LRU,
> >- * however it is not used from now on so that
> >- * we can use it safely.
> >- */
> >-head = (void *)&page->rcu_head;
> >-call_rcu(head, kmem_rcu_free);
> >-
> >-} else {
> >+if (unlikely(cachep->flags & SLAB_DESTROY_BY_RCU))
> >+call_rcu(&page->rcu_head, kmem_rcu_free);
> >+else
> > kmem_freepages(cachep, page);
> >-}
> > /*
> > * From now on, we don't use freelist
>
> This second piece looks like it belongs in patch 2, not patch 1 based on the
> descriptions.
You're right.
Although I don't think I would re-spin the patchset just for this change.
If any other change would be required, I'll fix this too.
--
Kirill A. Shutemov
--
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] fbdev changes for 4.3
Hi Linus, Please pull fbdev changes for 4.3. Not much this time. The following changes since commit 2c6625cd545bdd66acff14f3394865d43920a5c7: Linux 4.2-rc7 (2015-08-16 16:34:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-4.3 for you to fetch changes up to 57817e619a215588739f3f644986c78b586b541b: video: fbdev: atmel_lcdfb: remove useless include (2015-09-02 14:24:51 +0300) fbdev changes for 4.3 * Minor fixes and cleanups Alexandre Belloni (1): video: fbdev: atmel_lcdfb: remove useless include Alexey Klimov (1): fbdev: udlfb: remove unneeded initialization in few places Dan Carpenter (1): fbdev: fix snprintf() limit in show_bl_curve() Geert Uytterhoeven (1): fbdev: Allow compile test of GPIO consumers if !GPIOLIB Julia Lawall (1): fbdev: ssd1307fb: fix error return code Krzysztof Kozlowski (3): video: fbdev: Drop owner assignment from i2c_driver video: fbdev: Drop owner assignment from platform_driver video: fbdev: s3c-fb: Constify platform_device_id Marcin Chojnacki (1): fbdev: remove unnecessary memset in vfb Nicolai Stange (1): framebuffer: disable vgacon on microblaze arch Tomi Valkeinen (2): fbdev: fix cea_modes array size video: fbdev: atmel: fix warning for const return value Vaishali Thakkar (1): video: fbdev: pxa168fb: Use devm_clk_get drivers/video/console/Kconfig | 2 +- drivers/video/fbdev/Kconfig | 2 +- drivers/video/fbdev/atmel_lcdfb.c | 3 +-- drivers/video/fbdev/core/fbmon.c| 4 ++-- drivers/video/fbdev/core/fbsysfs.c | 2 +- drivers/video/fbdev/core/modedb.c | 2 +- drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 1 - drivers/video/fbdev/pxa168fb.c | 14 -- drivers/video/fbdev/s3c-fb.c| 2 +- drivers/video/fbdev/ssd1307fb.c | 6 +++--- drivers/video/fbdev/udlfb.c | 10 -- drivers/video/fbdev/vfb.c | 17 - include/linux/fb.h | 2 +- 13 files changed, 28 insertions(+), 39 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/5] staging: most: remove driver owner
On Fri, Sep 04, 2015 at 04:22:04PM +0530, Sudip Mukherjee wrote:
> The platform driver core will set the owner value, we do not need to do
> it in the module.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/staging/most/hdm-dim2/dim2_hdm.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/most/hdm-dim2/dim2_hdm.c
> b/drivers/staging/most/hdm-dim2/dim2_hdm.c
> index 5b0a588..4481a0b 100644
> --- a/drivers/staging/most/hdm-dim2/dim2_hdm.c
> +++ b/drivers/staging/most/hdm-dim2/dim2_hdm.c
> @@ -923,7 +923,6 @@ static struct platform_driver dim2_driver = {
> .id_table = dim2_id,
> .driver = {
> .name = "hdm_dim2",
> - .owner = THIS_MODULE,
I cannot accept this.
This change is not significant for current kernel, but we still have customers
using kernels <= 3.10, where auto assignment of .owner does not exist.
> },
> };
>
> --
> 1.9.1
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-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/
Re: [PATCH 2/3] perf tests: Add arch tests
On Sat, Sep 05, 2015 at 08:02:21PM +0100, Matt Fleming wrote:
SNIP
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index 8cf0601d1662..a1b2265eaf55 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -14,10 +14,17 @@
> #include "parse-options.h"
> #include "symbol.h"
>
> -static struct test {
> - const char *desc;
> - int (*func)(void);
> -} tests[] = {
> +#if defined(__x86_64__) || defined(__i386__)
> +#include "arch-tests.h"
> +#else
> +static struct test arch_tests[] = {
> + {
> + .func = NULL,
> + },
> +};
> +#endif
this could be defined as __weak array so we dont need to have #if above
jirka
--
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 v4 05/22] gpio: Probe GPIO drivers on demand
When looking up a gpiochip through its firmware node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu Vizoso --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/gpio/gpiolib-of.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index fa6e3c8823d6..9a439dab7a87 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -95,6 +96,8 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np, return ERR_PTR(ret); } + of_device_probe(gg_data.gpiospec.np); + gpiochip_find(&gg_data, of_gpiochip_find_and_xlate); of_node_put(gg_data.gpiospec.np); -- 2.4.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/
[PATCH v4 03/22] of/platform: Point to struct device from device node
When adding a platform device, set the device node's device member to
point to it.
This speeds lookups considerably and is safe because we only create one
platform device for any given device node.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/of/platform.c | 13 +
include/linux/of.h| 1 +
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 1001efaedcb8..baf04d7249bd 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -32,11 +32,6 @@ const struct of_device_id of_default_bus_match_table[] = {
{} /* Empty terminated list */
};
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
/**
* of_find_device_by_node - Find the platform_device associated with a node
* @np: Pointer to device tree node
@@ -45,10 +40,10 @@ static int of_dev_node_match(struct device *dev, void *data)
*/
struct platform_device *of_find_device_by_node(struct device_node *np)
{
- struct device *dev;
+ if (np->device && np->device->bus == &platform_bus_type)
+ return to_platform_device(np->device);
- dev = bus_find_device(&platform_bus_type, NULL, np, of_dev_node_match);
- return dev ? to_platform_device(dev) : NULL;
+ return NULL;
}
EXPORT_SYMBOL(of_find_device_by_node);
@@ -192,6 +187,8 @@ static struct platform_device
*of_platform_device_create_pdata(
goto err_clear_flag;
}
+ np->device = &dev->dev;
+
return dev;
err_clear_flag:
diff --git a/include/linux/of.h b/include/linux/of.h
index 2194b8ca41f9..eb091be0f8ee 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -52,6 +52,7 @@ struct device_node {
phandle phandle;
const char *full_name;
struct fwnode_handle fwnode;
+ struct device *device;
struct property *properties;
struct property *deadprops;/* removed properties */
--
2.4.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/
[PATCH] leds:lp55xx: Correct Kconfig dependency for f/w user helper
The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with user helper, but it
sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Since the
wrong option was enabled, the system got a regression -- it suffers
from the unexpected long delays for non-present firmware files.
This patch corrects the Kconfig dependency to the right one,
CONFIG_FW_LOADER_USER_HELPER. This doesn't change the fallback
behavior but only enables UMH when needed.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661
Fixes: b67893206fc0 ('leds:lp55xx: fix firmware loading error')
Cc: # v4.2+
Signed-off-by: Takashi Iwai
---
drivers/leds/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 70f4255ff291..2ba52bc2e174 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -229,7 +229,7 @@ config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
select FW_LOADER
- select FW_LOADER_USER_HELPER_FALLBACK
+ select FW_LOADER_USER_HELPER
help
This option supports common operations for LP5521/5523/55231/5562/8501
devices.
--
2.5.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 v4 16/22] pinctrl: Probe pinctrl devices on demand
When looking up a pin controller through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/pinctrl/devicetree.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index fe04e748dfe4..f5340b8e1dbe 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#include
@@ -110,6 +111,8 @@ static int dt_to_map_one_config(struct pinctrl *p, const
char *statename,
struct pinctrl_map *map;
unsigned num_maps;
+ of_device_probe(np_config);
+
/* Find the pin controller containing np_config */
np_pctldev = of_node_get(np_config);
for (;;) {
--
2.4.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/
[PATCH v4 21/22] driver core: Start processing deferred probes earlier
Some initcalls in the late level assume that some devices will have
already probed without explicitly checking for that.
After the recent move to defer most device probes when they are
registered, pressure increased in the late initcall level.
By starting the processing of the deferred queue in device_initcall_sync
we increase the chances that the initcalls mentioned before will find
the devices they depend on to have already probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4:
- Start processing deferred probes in device_initcall_sync
Changes in v3: None
Changes in v2: None
drivers/base/dd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 0654fb771a53..b6a22cff78cf 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -176,7 +176,7 @@ static void driver_deferred_probe_trigger(void)
*
* We don't want to get in the way when the bulk of drivers are getting probed.
* Instead, this initcall makes sure that deferred probing is delayed until
- * late_initcall time.
+ * device_initcall_sync time.
*/
static int deferred_probe_initcall(void)
{
@@ -190,7 +190,7 @@ static int deferred_probe_initcall(void)
flush_workqueue(deferred_wq);
return 0;
}
-late_initcall(deferred_probe_initcall);
+device_initcall_sync(deferred_probe_initcall);
static void driver_bound(struct device *dev)
{
--
2.4.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/
[PATCH v4 17/22] phy: core: Probe phy providers on demand
When looking up a phy provider through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/phy/phy-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index fc48fac003a6..94e90031d7f3 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -363,6 +364,8 @@ static struct phy *_of_phy_get(struct device_node *np, int
index)
if (ret)
return ERR_PTR(-ENODEV);
+ of_device_probe(args.np);
+
mutex_lock(&phy_provider_mutex);
phy_provider = of_phy_provider_lookup(args.np);
if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
--
2.4.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/
[PATCH v4 09/22] drm: Probe panels on demand
When looking up a panel through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/drm_panel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e037b7..ad79a7b9c74d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -80,6 +81,8 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
{
struct drm_panel *panel;
+ of_device_probe(np);
+
mutex_lock(&panel_lock);
list_for_each_entry(panel, &panel_list, list) {
--
2.4.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/
[PATCH v4 13/22] backlight: Probe backlight devices on demand
When looking up a backlight device through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/video/backlight/backlight.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index bddc8b17a4d8..9bcdc16eacdf 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_PMAC_BACKLIGHT
#include
@@ -559,6 +560,8 @@ struct backlight_device *of_find_backlight_by_node(struct
device_node *node)
{
struct device *dev;
+ of_device_probe(node);
+
dev = class_find_device(backlight_class, NULL, node, of_parent_match);
return dev ? to_backlight_device(dev) : NULL;
--
2.4.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/
[PATCH] tty: fix data race in tty_buffer_flush
tty_buffer_flush frees not acquired buffers.
As the result, for example, read of b->size in tty_buffer_free
can return garbage value which will lead to a huge buffer
hanging in the freelist. This is just the benignest
manifestation of freeing of a not acquired object.
If the object is passed to kfree, heap can be corrupted.
Acquire visibility over the buffer before freeing it.
The data race was found with KernelThreadSanitizer (KTSAN).
Signed-off-by: Dmitry Vyukov
---
drivers/tty/tty_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 5a3fa89..7dab1b3 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -242,7 +242,7 @@ void tty_buffer_flush(struct tty_struct *tty, struct
tty_ldisc *ld)
atomic_inc(&buf->priority);
mutex_lock(&buf->lock);
- while ((next = buf->head->next) != NULL) {
+ while ((next = smp_load_acquire(&buf->head->next)) != NULL) {
tty_buffer_free(port, buf->head);
buf->head = next;
}
--
2.5.0.457.gab17608
--
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] btrfs: memset cur_trans->delayed_refs to zero
On Sun, Sep 06, 2015 at 12:25:27PM +, Alexandru Moise wrote: > Use memset() to null out the btrfs_delayed_ref_root of > btrfs_transaction instead of setting all the members to 0 by hand. > > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com> > --- > fs/btrfs/transaction.c | 10 +- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c > index 8f259b3..faccc1b 100644 > --- a/fs/btrfs/transaction.c > +++ b/fs/btrfs/transaction.c > @@ -224,15 +224,7 @@ loop: > cur_trans->start_time = get_seconds(); > cur_trans->dirty_bg_run = 0; > > - cur_trans->delayed_refs.href_root = RB_ROOT; > - cur_trans->delayed_refs.dirty_extent_root = RB_ROOT; > - atomic_set(&cur_trans->delayed_refs.num_entries, 0); Please keep these. Even if it means duplicated setting to 0, it's using the correct constructor, should it ever change (RB_ROOT) or does some extra work (atomic_set). -- 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 v4 06/22] gpio: Probe pinctrl devices on demand
When looking up a pin controller through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu Vizoso --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/gpio/gpiolib-of.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index 9a439dab7a87..05da9a56608d 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -359,6 +359,8 @@ static int of_gpiochip_add_pin_range(struct gpio_chip *chip) if (ret) break; + of_device_probe(pinspec.np); + pctldev = of_pinctrl_get(pinspec.np); if (!pctldev) return -EPROBE_DEFER; -- 2.4.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/
[PATCH v4 08/22] regulator: core: Probe regulators on demand
When looking up a regulator through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/regulator/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f4aa6cae76d5..615133f45c76 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1340,6 +1341,7 @@ static struct regulator_dev *regulator_dev_lookup(struct
device *dev,
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
+ of_device_probe(node);
mutex_lock(®ulator_list_mutex);
list_for_each_entry(r, ®ulator_list, list)
if (r->dev.parent &&
--
2.4.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/
[PATCH v4 22/22] of/platform: Defer probes of registered devices
Instead of trying to match and probe platform and AMBA devices right
after each is registered, delay their probes until device_initcall_sync.
This means that devices will start probing once all built-in drivers
have registered, and after all platform and AMBA devices from the DT
have been registered already.
This allows us to prevent deferred probes by probing dependencies on
demand.
Signed-off-by: Tomeu Vizoso
---
Changes in v4:
- Also defer probes of AMBA devices registered from the DT as they can
also request resources.
Changes in v3: None
Changes in v2: None
drivers/of/platform.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index f089d95ac961..a9397ce838ea 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -164,7 +164,8 @@ static struct platform_device
*of_platform_device_create_pdata(
struct device_node *np,
const char *bus_id,
void *platform_data,
- struct device *parent)
+ struct device *parent,
+ bool probe_late)
{
struct platform_device *dev;
@@ -178,6 +179,7 @@ static struct platform_device
*of_platform_device_create_pdata(
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
+ dev->dev.probe_late = probe_late;
of_dma_configure(&dev->dev, dev->dev.of_node);
of_msi_configure(&dev->dev, dev->dev.of_node);
@@ -209,7 +211,8 @@ struct platform_device *of_platform_device_create(struct
device_node *np,
const char *bus_id,
struct device *parent)
{
- return of_platform_device_create_pdata(np, bus_id, NULL, parent);
+ return of_platform_device_create_pdata(np, bus_id, NULL, parent,
+ false);
}
EXPORT_SYMBOL(of_platform_device_create);
@@ -240,6 +243,7 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
dev->dev.of_node = of_node_get(node);
dev->dev.parent = parent ? : &platform_bus;
dev->dev.platform_data = platform_data;
+ dev->dev.probe_late = true;
if (bus_id)
dev_set_name(&dev->dev, "%s", bus_id);
else
@@ -358,7 +362,8 @@ static int of_platform_bus_create(struct device_node *bus,
return 0;
}
- dev = of_platform_device_create_pdata(bus, bus_id, platform_data,
parent);
+ dev = of_platform_device_create_pdata(bus, bus_id, platform_data,
+ parent, true);
if (!dev || !of_match_node(matches, bus))
return 0;
--
2.4.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/
[PATCH v4 04/22] of: add function to allow probing a device from a OF node
Walks the OF tree up and finds the closest ancestor that has a struct
device associated with it, probing it if isn't bound to a driver yet.
The above should ensure that the dependency represented by the passed OF
node is available, because probing a device should cause its descendants
to be probed as well (when they get registered).
Subsystems can use this when looking up resources for drivers, to reduce
the chances of deferred probes because of the probing order of devices.
Signed-off-by: Tomeu Vizoso
---
Changes in v4:
- Rename of_platform_probe to of_device_probe
- Use device_node.device instead of device_node.platform_dev
Changes in v3:
- Set and use device_node.platform_dev instead of reversing the logic to
find the platform device that encloses a device node.
- Drop the fwnode API to probe firmware nodes and add OF-only API for
now. I think this same scheme could be used for machines with ACPI,
but I haven't been able to find one that had to defer its probes because
of the device probe order.
Changes in v2: None
drivers/of/device.c | 58 +++
drivers/of/platform.c | 2 ++
include/linux/of_device.h | 3 +++
3 files changed, 63 insertions(+)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8b91ea241b10..c32ac7b6fbe2 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -286,3 +286,61 @@ int of_device_uevent_modalias(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
+
+/**
+ * of_device_probe() - Probe device associated with OF node
+ * @np: node to probe
+ *
+ * Probe the device associated with the passed device node.
+ */
+void of_device_probe(struct device_node *np)
+{
+ struct device_node *target;
+ struct device *dev = NULL;
+
+ if (!of_root || !of_node_check_flag(of_root, OF_POPULATED_BUS))
+ return;
+
+ if (!np)
+ return;
+
+ of_node_get(np);
+
+ /* Find the closest ancestor that has a device associated */
+ for (target = np;
+!of_node_is_root(target);
+target = of_get_next_parent(target))
+ if (target->device) {
+ dev = target->device;
+ break;
+ }
+
+ of_node_put(target);
+
+ if (!dev) {
+ pr_warn("Couldn't find a device for node '%s'\n",
+ of_node_full_name(np));
+ return;
+ }
+
+ /*
+* Device is bound or is being probed right now. If we have bad luck
+* and the dependency isn't ready when it's needed, deferred probe
+* will save us.
+*/
+ if (dev->driver)
+ return;
+
+ /*
+* Probing a device should cause its descendants to be probed as
+* well, which includes the passed device node.
+*/
+ if (device_attach(dev) != 1)
+ /*
+* This cannot be a warning for now because clock nodes have a
+* compatible string but the clock framework doesn't follow
+* the device/driver model yet.
+*/
+ dev_dbg(dev, "Probe failed for %s\n", of_node_full_name(np));
+}
+EXPORT_SYMBOL_GPL(of_device_probe);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index baf04d7249bd..f089d95ac961 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -269,6 +269,8 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
goto err_free;
}
+ node->device = &dev->dev;
+
return dev;
err_free:
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index cc7dd687a89d..da8d489e73ad 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -40,6 +40,7 @@ extern ssize_t of_device_get_modalias(struct device *dev,
extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int of_device_uevent_modalias(struct device *dev, struct
kobj_uevent_env *env);
+extern void of_device_probe(struct device_node *np);
static inline void of_device_node_put(struct device *dev)
{
@@ -84,6 +85,8 @@ static inline int of_device_uevent_modalias(struct device
*dev,
return -ENODEV;
}
+static inline void of_device_probe(struct device_node *np) { }
+
static inline void of_device_node_put(struct device *dev) { }
static inline const struct of_device_id *__of_match_device(
--
2.4.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/
[PATCH v4 20/22] driver core: Allow deferring probes until late init
Add a field to struct device that instructs the device-driver core to
defer the probe of this device until the late_initcall level.
By letting all built-in drivers to register before starting to probe, we
can avoid any deferred probes by probing dependencies on demand.
Signed-off-by: Tomeu Vizoso
---
Changes in v4:
- Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in
machines with initcalls that depend on devices probing at a given time.
Changes in v3: None
Changes in v2: None
drivers/base/Kconfig | 18 ++
drivers/base/dd.c | 7 +++
include/linux/device.h | 2 ++
3 files changed, 27 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec99c7d..44b5d33b1f49 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -324,4 +324,22 @@ config CMA_ALIGNMENT
endif
+config DELAY_DEVICE_PROBES
+ bool "Allow delaying the probe of some devices"
+ default y
+ help
+ Devices can be matched to a driver and probed from the moment they
+ are registered, but early during boot their probes are likely to be
+ deferred because some dependency isn't available yet because most
+ drivers haven't been registered yet.
+
+ Enabling this option allows the device registration code to delay the
+ probing of a specific device until device_initcall_sync, when all
+ built-in drivers have been registered already.
+
+ In some platforms there may be implicit assumptions about when some
+ devices are probed, so enabling this option could cause problems
there.
+
+ If unsure, say Y here.
+
endmenu
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index faf60bfc46b3..0654fb771a53 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -417,6 +417,13 @@ int driver_probe_device(struct device_driver *drv, struct
device *dev)
if (!device_is_registered(dev))
return -ENODEV;
+#if IS_ENABLED(CONFIG_DELAY_DEVICE_PROBES)
+ if (!driver_deferred_probe_enable && dev->probe_late) {
+ driver_deferred_probe_add(dev);
+ return 0;
+ }
+#endif
+
pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
drv->bus->name, __func__, dev_name(dev), drv->name);
diff --git a/include/linux/device.h b/include/linux/device.h
index d8be07bc9c3f..fe5c50ffd7d3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -748,6 +748,7 @@ struct device_dma_parameters {
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
+ * @probe_late:If set, device will be probed in the late initcall
level.
*
* At the lowest level, every device in a Linux system is represented by an
* instance of struct device. The device structure contains the information
@@ -832,6 +833,7 @@ struct device {
booloffline_disabled:1;
booloffline:1;
+ boolprobe_late:1;
};
static inline struct device *kobj_to_dev(struct kobject *kobj)
--
2.4.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/
[PATCH v4 19/22] power-supply: Probe power supplies on demand
When looking up a power supply through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/power/power_supply_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/power/power_supply_core.c
b/drivers/power/power_supply_core.c
index 456987c88baa..80bc89f4ae89 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "power_supply.h"
/* exported for the APM Power driver, APM emulation */
@@ -206,6 +207,8 @@ static int power_supply_find_supply_from_node(struct
device_node *supply_node)
{
int error;
+ of_device_probe(supply_node);
+
/*
* class_for_each_device() either returns its own errors or values
* returned by __power_supply_find_supply_from_node().
--
2.4.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 2/3] perf tests: Add arch tests
On Sat, Sep 05, 2015 at 08:02:21PM +0100, Matt Fleming wrote:
SNIP
> };
>
> +static struct test *tests[] = {
> + generic_tests,
> + arch_tests,
> +};
> +
> static bool perf_test__matches(struct test *test, int curr, int argc, const
> char *argv[])
> {
> int i;
> @@ -237,7 +229,11 @@ static int run_test(struct test *test)
> return err;
> }
>
> -#define for_each_test(t) for (t = &tests[0]; t->func; t++)
> +static unsigned int ___j;/* This is obviously not thread-safe */
> +
> +#define for_each_test(t) \
> + for (___j = 0; ___j < ARRAY_SIZE(tests); ___j++)\
> + for (t = &tests[___j][0]; t->func; t++)
why not have j on stack and pas it into for_each_test
for_each_test(j, t)
...
jirka
--
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 v4 15/22] clk: Probe clk providers on demand
When looking up a clock through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/clk/clk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 43e2c3ad6c31..e5fe02a11c36 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3004,6 +3005,8 @@ struct clk *__of_clk_get_from_provider(struct
of_phandle_args *clkspec,
if (!clkspec)
return ERR_PTR(-EINVAL);
+ of_device_probe(clkspec->np);
+
/* Check if we have such a provider in our array */
mutex_lock(&of_clk_mutex);
list_for_each_entry(provider, &of_clk_providers, link) {
--
2.4.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/
[PATCH v4 18/22] dma: of: Probe DMA controllers on demand
When looking up a DMA controller through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu Vizoso --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/dma/of-dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c index 1e1f2986eba8..e899832f7df3 100644 --- a/drivers/dma/of-dma.c +++ b/drivers/dma/of-dma.c @@ -16,6 +16,7 @@ #include #include #include +#include #include static LIST_HEAD(of_dma_list); @@ -263,6 +264,8 @@ struct dma_chan *of_dma_request_slave_channel(struct device_node *np, if (of_dma_match_channel(np, name, i, &dma_spec)) continue; + of_device_probe(dma_spec.np); + mutex_lock(&of_dma_lock); ofdma = of_dma_find_controller(&dma_spec); -- 2.4.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/
[PATCH v4 02/22] ARM: amba: Move reading of periphid to pre_probe()
Reading the periphid when the Primecell device is registered means that
the apb pclk must be available by then or the device won't be registered
at all.
By moving this code to pre_probe (to be called by the device-driver core
before the device is matched to a driver) we remove any order
requirements.
Signed-off-by: Tomeu Vizoso
---
Changes in v4:
- Added bus.pre_probe callback so the probes of Primecell devices can be
deferred if their device IDs cannot be yet read because of the clock
driver not having probed when they are registered. Maybe this goes
overboard and the matching information should be in the DT if there is
one.
Changes in v3: None
Changes in v2: None
drivers/amba/bus.c | 78 ++
1 file changed, 38 insertions(+), 40 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index f0099360039e..1cbe43b4acd3 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -24,6 +24,8 @@
#define to_amba_driver(d) container_of(d, struct amba_driver, drv)
+static int amba_pre_probe(struct device *dev);
+
static const struct amba_id *
amba_lookup(const struct amba_id *table, struct amba_device *dev)
{
@@ -193,6 +195,7 @@ struct bus_type amba_bustype = {
.name = "amba",
.dev_attrs = amba_dev_attrs,
.match = amba_match,
+ .pre_probe = amba_pre_probe,
.uevent = amba_uevent,
.pm = &amba_pm,
};
@@ -336,44 +339,26 @@ static void amba_device_release(struct device *dev)
kfree(d);
}
-/**
- * amba_device_add - add a previously allocated AMBA device structure
- * @dev: AMBA device allocated by amba_device_alloc
- * @parent: resource parent for this devices resources
- *
- * Claim the resource, and read the device cell ID if not already
- * initialized. Register the AMBA device with the Linux device
- * manager.
- */
-int amba_device_add(struct amba_device *dev, struct resource *parent)
+static int amba_pre_probe(struct device *dev)
{
+ struct amba_device *d = to_amba_device(dev);
u32 size;
void __iomem *tmp;
int i, ret;
- WARN_ON(dev->irq[0] == (unsigned int)-1);
- WARN_ON(dev->irq[1] == (unsigned int)-1);
-
- ret = request_resource(parent, &dev->res);
- if (ret)
- goto err_out;
-
- /* Hard-coded primecell ID instead of plug-n-play */
- if (dev->periphid != 0)
- goto skip_probe;
+ if (d->periphid != 0)
+ return 0;
/*
* Dynamically calculate the size of the resource
* and use this for iomap
*/
- size = resource_size(&dev->res);
- tmp = ioremap(dev->res.start, size);
- if (!tmp) {
- ret = -ENOMEM;
- goto err_release;
- }
+ size = resource_size(&d->res);
+ tmp = ioremap(d->res.start, size);
+ if (!tmp)
+ return -ENOMEM;
- ret = amba_get_enable_pclk(dev);
+ ret = amba_get_enable_pclk(d);
if (ret == 0) {
u32 pid, cid;
@@ -388,37 +373,50 @@ int amba_device_add(struct amba_device *dev, struct
resource *parent)
cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
(i * 8);
- amba_put_disable_pclk(dev);
+ amba_put_disable_pclk(d);
if (cid == AMBA_CID || cid == CORESIGHT_CID)
- dev->periphid = pid;
+ d->periphid = pid;
- if (!dev->periphid)
+ if (!d->periphid)
ret = -ENODEV;
}
iounmap(tmp);
+ return ret;
+}
+
+/**
+ * amba_device_add - add a previously allocated AMBA device structure
+ * @dev: AMBA device allocated by amba_device_alloc
+ * @parent: resource parent for this devices resources
+ *
+ * Claim the resource, and register the AMBA device with the Linux device
+ * manager.
+ */
+int amba_device_add(struct amba_device *dev, struct resource *parent)
+{
+ int ret;
+
+ WARN_ON(dev->irq[0] == (unsigned int)-1);
+ WARN_ON(dev->irq[1] == (unsigned int)-1);
+
+ ret = request_resource(parent, &dev->res);
if (ret)
- goto err_release;
+ return ret;
- skip_probe:
ret = device_add(&dev->dev);
if (ret)
- goto err_release;
+ return ret;
if (dev->irq[0])
ret = device_create_file(&dev->dev, &dev_attr_irq0);
if (ret == 0 && dev->irq[1])
ret = device_create_file(&dev->dev, &dev_attr_irq1);
- if (ret == 0)
- return ret;
-
- device_unregister(&dev->dev);
+ if (ret)
+ device_unregister(&dev->dev);
- err_release:
- release_resource(&dev->res);
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(amba_dev
[PATCH?] fput: don't abuse task_work_add() too much
On 09/05, Al Viro wrote:
>
> On Sat, Aug 29, 2015 at 02:49:21PM +0200, Oleg Nesterov wrote:
>
> > Let's look keyctl_session_to_parent(). It does task_work_cancel()
> > but only because we can not trust user-space. Otherwise we could
> > remove it and just do task_work_add(), but this needs fifo.
> >
> > Fifo just looks more sane to me.
>
> Not if it costs us.
OK, Eric reports this trivial lockless loop takes 275ms. Apparently the
list of fput() works is huge. Now, how much does it cost to _create_
this huge list using task_work_add() which does cmpxchg() ? I guess a bit
more. This is what should be fixed if we think this hurts performance-wise.
And again, ignoring the latency problem due to the lack of cond_resched,
I am wondering if these 275ms are actually noticable compared to the time
the next loop needs to call all these fput's.
> As far as files closing is concerned, the order
> really doesn't matter. Ditto for final mntput() uses of that stuff.
Sure, fput/mntput do not care about the ordering. And more, they do
not even really need task_work_add(). We can just remove it from fput()
and everything will work fine. Correctness-wise, I mean.
And yes, unfortunately we do not have in-kernel users which already
rely on fifo.
But task_work_add() is the generic API, loosing the ordering makes
it less useful or at least less convenient.
Just for (yes sure, artificial) example. Suppose we want to implement
sys_change_process_flags(int pid, uint set, uint clr). Only current
can change its ->flags, so we can use task_work_add() to do this. But
obviously only if it is fifo.
fput() differs because it does not care which process actually does
__fput(). And thus imo we should not count this user if we need to
decide do we need fifo or not.
> IMO the obvious solution is to lose the reordering...
Oh, I disagree. But I guess I can't convince you/Eric/Linus, so I have
to shut up.
Damn. But I can't relax ;) Al, Linus, could you comment the patch below?
Not for inclusion, lacks the changelog/testing, fput() can be simplified.
But as you can see it is simple. With this patch task_work_add(fput)
will be called only once by (say) do_exit() path. ->fput_list does not
need any serialization / atomic ops / etc. Probably we also need to move
cond_resched() from task_work_run() to fput() after this patch.
Again, it is not that I think this actually makes sense, but since you
dislike these 275ms...
What do you think?
Oleg.
---
diff --git a/fs/file_table.c b/fs/file_table.c
index 294174d..36af701 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -241,7 +241,13 @@ static void delayed_fput(struct work_struct *unused)
static void fput(struct callback_head *work)
{
- __fput(container_of(work, struct file, f_u.fu_rcuhead));
+ struct task_struct *task = current;
+ do {
+ struct file *file = task->fput_list;
+ task->fput_list = file->f_u.fu_next;
+ __fput(file);
+
+ } while (task->fput_list);
}
/*
@@ -267,9 +273,19 @@ void fput(struct file *file)
struct task_struct *task = current;
if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
+ if (task->fput_list) {
+ /* task_work_add() below was already called */
+ file->f_u.fu_next = task->fput_list;
+ task->fput_list = file;
+ return;
+ }
+
init_task_work(&file->f_u.fu_rcuhead, fput);
- if (!task_work_add(task, &file->f_u.fu_rcuhead, true))
+ if (!task_work_add(task, &file->f_u.fu_rcuhead, true)) {
+ file->f_u.fu_next = NULL;
+ task->fput_list = file;
return;
+ }
/*
* After this task has run exit_task_work(),
* task_work_add() will fail. Fall through to delayed
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 0774487..73fe16c 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -830,6 +830,7 @@ struct file {
union {
struct llist_node fu_llist;
struct rcu_head fu_rcuhead;
+ struct file *fu_next;
} f_u;
struct path f_path;
struct inode*f_inode; /* cached value */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f192cfe..6f704ff 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1477,6 +1477,7 @@ struct task_struct {
struct fs_struct *fs;
/* open file information */
struct files_struct *files;
+ struct file *fput_list;
/* namespaces */
struct nsproxy *nsproxy;
/* signal handlers */
diff --git a/kernel/fork.c b/k
[PATCH v4 14/22] usb: phy: Probe phy devices on demand
When looking up a phy through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu Vizoso --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/usb/phy/phy.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c index 98f75d2842b7..fb0b650bb494 100644 --- a/drivers/usb/phy/phy.c +++ b/drivers/usb/phy/phy.c @@ -15,6 +15,7 @@ #include #include #include +#include #include @@ -196,6 +197,8 @@ struct usb_phy *devm_usb_get_phy_by_node(struct device *dev, goto err0; } + of_device_probe(node); + spin_lock_irqsave(&phy_lock, flags); phy = __of_usb_find_phy(node); -- 2.4.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/
[PATCH v4 01/22] driver core: Add pre_probe callback to bus_type
Some buses (eg. AMBA) need access to some HW resources (it may need a
clock to be enabled so a device ID can be read) before a device can be
matched to a driver.
The pre_probe callback allows the device-driver core to request the bus
to perform this initialization and can defer the probe if any of the
resources needed are missing.
This gives us more flexibility when setting the order in which devices
are probed because the resources needed to get the matching information
don't need to be available by the time that the bus devices are
registered.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/base/dd.c | 24
include/linux/device.h | 4
2 files changed, 28 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..faf60bfc46b3 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -544,6 +544,17 @@ static int __device_attach(struct device *dev, bool
allow_async)
int ret = 0;
device_lock(dev);
+
+ if (dev->bus && dev->bus->pre_probe) {
+ ret = dev->bus->pre_probe(dev);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ driver_deferred_probe_add(dev);
+ ret = 0;
+ goto out_unlock;
+ }
+ }
+
if (dev->driver) {
if (klist_node_attached(&dev->p->knode_driver)) {
ret = 1;
@@ -619,6 +630,7 @@ void device_initial_probe(struct device *dev)
static int __driver_attach(struct device *dev, void *data)
{
struct device_driver *drv = data;
+ int ret;
/*
* Lock device and try to bind to it. We drop the error
@@ -636,8 +648,20 @@ static int __driver_attach(struct device *dev, void *data)
if (dev->parent)/* Needed for USB */
device_lock(dev->parent);
device_lock(dev);
+
+ if (dev->bus && dev->bus->pre_probe) {
+ ret = dev->bus->pre_probe(dev);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ driver_deferred_probe_add(dev);
+ goto out;
+ }
+ }
+
if (!dev->driver)
driver_probe_device(drv, dev);
+
+out:
device_unlock(dev);
if (dev->parent)
device_unlock(dev->parent);
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..d8be07bc9c3f 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -74,6 +74,9 @@ extern void bus_remove_file(struct bus_type *, struct
bus_attribute *);
* given device can be handled by the given driver.
* @uevent:Called when a device is added, removed, or a few other things
* that generate uevents to add the environment variables.
+ * @pre_probe: Called when a new device or driver is added to this bus, to
+ * perform any initializations that are needed so the device can
+ * be matched to a driver.
* @probe: Called when a new device or driver add to this bus, and callback
* the specific driver's probe to initial the matched device.
* @remove:Called when a device removed from this bus.
@@ -113,6 +116,7 @@ struct bus_type {
int (*match)(struct device *dev, struct device_driver *drv);
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
+ int (*pre_probe)(struct device *dev);
int (*probe)(struct device *dev);
int (*remove)(struct device *dev);
void (*shutdown)(struct device *dev);
--
2.4.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 2/3] perf tests: Add arch tests
On Sat, Sep 05, 2015 at 08:02:21PM +0100, Matt Fleming wrote:
SNIP
>
> +static struct test *tests[] = {
> + generic_tests,
> + arch_tests,
> +};
> +
> static bool perf_test__matches(struct test *test, int curr, int argc, const
> char *argv[])
> {
> int i;
> @@ -237,7 +229,11 @@ static int run_test(struct test *test)
> return err;
> }
>
> -#define for_each_test(t) for (t = &tests[0]; t->func; t++)
> +static unsigned int ___j;/* This is obviously not thread-safe */
> +
> +#define for_each_test(t) \
> + for (___j = 0; ___j < ARRAY_SIZE(tests); ___j++)\
> + for (t = &tests[___j][0]; t->func; t++)
>
could you also split the change on adding support for arch_tests
and another actually moving affected tests?
jirka
--
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 v4 12/22] pwm: Probe PWM chip devices on demand
When looking up a PWM chip through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/pwm/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 3f9df3ea3350..794a923df0d8 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
@@ -516,6 +517,8 @@ static struct pwm_chip *of_node_to_pwmchip(struct
device_node *np)
{
struct pwm_chip *chip;
+ of_device_probe(np);
+
mutex_lock(&pwm_lock);
list_for_each_entry(chip, &pwm_chips, list)
--
2.4.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 v3 02/18] of/platform: add of_platform_probe
On 11 August 2015 at 11:37, Tomeu Vizoso wrote: > On 7 August 2015 at 14:19, Mark Brown wrote: >> On Thu, Aug 06, 2015 at 04:11:39PM +0200, Tomeu Vizoso wrote: >> >>> Walks the OF tree up and finds the closest ancestor that has a platform >>> device associated with it, probing it if isn't bound to a driver yet. >> >>> The above should ensure that the dependency represented by the passed OF >>> node is available, because probing a platform device should cause its >>> descendants to be probed as well. >> >> This sounds like it's going to break in the case where we have MFDs that >> represent their functions in DT (not a pattern I'm a fan of but it's a >> thing people do). We'll walk back to the platform device for the MFD >> function, try to probe it and then give up. Perhaps that's good enough >> anyway but it's not clear to me why we don't just try every parent we >> find? > > Agreed. In the attempt at probing dependencies before a device is > probed, I considered that a device's parent is also a dependency and > that worked well. From what I saw, few devices will defer their probe > if their parent hasn't been probed yet, assuming that it will have > probed already. But with simple-mfd and simple-bus that shouldn't be > relied upon as things will break if their parents defer their probe. > With async probing enabled this failure scenario becomes more > probable. Actually I'm not sure how we could probe the ascendants on demand, as currently the parent's device lock is taken when probing so trying to probe a sibling from within a probe callback will cause a deadlock. AFAICS this is only needed for USB interface devices and this behaviour could be limited to them, but I don't like much assuming that no USB device will ever have a dependency on a sibling (though that probably won't happen ever). Regards, Tomeu >> I'm also not a fan of the fact that the interface here is explicitly >> saying that we want to probe a platform device, that's an implementation >> detail that callers shouldn't need to know about. From the point of >> view of the callers what they're trying to do is kick any dependencies >> into being instantiated, the fact that we currently try to accomplish it >> with platform devices isn't something they care about. > > Agreed. > > Thanks, > > Tomeu -- 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 v4 11/22] i2c: core: Probe i2c adapters and devices on demand
When looking up an i2c adapter or device through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu Vizoso --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/i2c/i2c-core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 5f89f1e3c2f2..02da3acbbd35 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -1413,6 +1413,8 @@ struct i2c_client *of_find_i2c_device_by_node(struct device_node *node) struct device *dev; struct i2c_client *client; + of_device_probe(node); + dev = bus_find_device(&i2c_bus_type, NULL, node, of_dev_node_match); if (!dev) return NULL; @@ -1431,6 +1433,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node) struct device *dev; struct i2c_adapter *adapter; + of_device_probe(node); + dev = bus_find_device(&i2c_bus_type, NULL, node, of_dev_node_match); if (!dev) return NULL; -- 2.4.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/
[PATCH v4 10/22] drm/tegra: Probe dpaux devices on demand
When looking up a dpaux device through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/tegra/dpaux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 224a7dc8e4ed..96a2eec7e020 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -439,6 +440,8 @@ struct tegra_dpaux *tegra_dpaux_find_by_of_node(struct
device_node *np)
{
struct tegra_dpaux *dpaux;
+ of_device_probe(np);
+
mutex_lock(&dpaux_lock);
list_for_each_entry(dpaux, &dpaux_list, list)
--
2.4.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/
[PATCH v4 0/22] On-demand device probing
Hello, I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels and linking order. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by probing devices as they are referenced by other devices. This basically reuses the information that is already implicit in the probe() implementations, saving us from refactoring existing drivers or adding information to DTBs. During review of v1 of this series Linus Walleij suggested that it should be the device driver core to make sure that dependencies are ready before probing a device. I gave this idea a try [2] but Mark Brown pointed out to the logic duplication between the resource acquisition and dependency discovery code paths (though I think it's fairly minor). To address that code duplication I experimented with Arnd's devm_probe [3] concept of having drivers declare their dependencies instead of acquiring them during probe, and while it worked [4], I don't think we end up winning anything when compared to just probing devices on-demand from resource getters. One remaining objection is to the "sprinkling" of calls to of_device_probe() in the resource getters of each subsystem, but I think it's the right thing to do given that the storage of resources is currently subsystem-specific. We could avoid the above by moving resource storage into the core, but I don't think there's a compelling case for that. I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and OMAP SoCs, and these patches were enough to eliminate all the deferred probes (except one in PandaBoard because omap_dma_system doesn't have a firmware node as of yet). Have submitted a branch [5] with only these patches on top of thursday's linux-next to kernelci.org and I don't see any issues that could be caused by them. For some reason it currently has more passes than the version of -next it's based on! With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Regards, Tomeu [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html [1] https://lkml.org/lkml/2014/5/12/452 [2] https://lkml.org/lkml/2015/6/17/305 [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 [4] https://lkml.org/lkml/2015/7/21/441a [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6 [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/ [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/ Changes in v4: - Added bus.pre_probe callback so the probes of Primecell devices can be deferred if their device IDs cannot be yet read because of the clock driver not having probed when they are registered. Maybe this goes overboard and the matching information should be in the DT if there is one. - Rename of_platform_probe to of_device_probe - Use device_node.device instead of device_node.platform_dev - Take a reference to the regulator's device to prevent dangling pointers - Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in machines with initcalls that depend on devices probing at a given time. - Start processing deferred probes in device_initcall_sync - Also defer probes of AMBA devices registered from the DT as they can also request resources. Changes in v3: - Set and use device_node.platform_dev instead of reversing the logic to find the platform device that encloses a device node. - Drop the fwnode API to probe firmware nodes and add OF-only API for now. I think this same scheme could be used for machines with ACPI, but I haven't been able to find one that had to defer its probes because of the device probe order. - Avoid unlocking the regulator device's mutex if we don't have a device Changes in v2: - Acquire regulator device lock before returning from regulator_dev_lookup() Tomeu Vizoso (22): driver core: Add pre_probe callback to bus_type ARM: amba: Move reading of periphid to pre_probe() of/platform: Point to struct device from device node of: add function to allow probing a device from a OF node gpio: Probe GPIO drivers on demand gpio: Probe pinctrl devices on demand regulator: core: Reduce critical area in _regulator_get regulator: core: Probe regulators on demand drm: Probe panels on demand drm/tegra: Probe dpaux devices on demand i2c: core: Probe i2c adapters and devices on demand pwm: Probe PWM chip devices on demand backlight: Probe backlight devices on demand usb: phy: Probe phy devices on demand clk: Probe clk providers on demand pinctrl: Probe pinctrl devices on demand phy: core: Probe phy providers on demand dma: of: Pro
[PATCH v4 07/22] regulator: core: Reduce critical area in _regulator_get
By moving the locking of regulator_list_mutex into regulator_dev_lookup,
where it is iterated over. The reference count of the regulator's device
is increased in case it's unregistered while in use.
In _regulator_get() the regulator_list_mutex mutex was held for most of
the function, but that is only strictly needed to protect the list
lookups.
This change would be useful if for example regulator devices could be
registered on demand when a driver requests them. regulator_register()
could end up being called from within _regulator_get while the lock on
regulator_list_mutex is being held, causing a deadlock.
This sequence illustrates the situation described above:
tegra_hdmi_probe
_regulator_get
regulator_dev_lookup
of_device_probe
reg_fixed_voltage_probe
regulator_register
Signed-off-by: Tomeu Vizoso
---
Changes in v4:
- Take a reference to the regulator's device to prevent dangling
pointers
Changes in v3:
- Avoid unlocking the regulator device's mutex if we don't have a device
Changes in v2:
- Acquire regulator device lock before returning from regulator_dev_lookup()
drivers/regulator/core.c | 56
1 file changed, 38 insertions(+), 18 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7150ff6ef46b..f4aa6cae76d5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1340,10 +1340,15 @@ static struct regulator_dev
*regulator_dev_lookup(struct device *dev,
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
+ mutex_lock(®ulator_list_mutex);
list_for_each_entry(r, ®ulator_list, list)
if (r->dev.parent &&
- node == r->dev.of_node)
+ node == r->dev.of_node &&
+ get_device(&r->dev)) {
+ mutex_unlock(®ulator_list_mutex);
return r;
+ }
+ mutex_unlock(®ulator_list_mutex);
*ret = -EPROBE_DEFER;
return NULL;
} else {
@@ -1361,9 +1366,13 @@ static struct regulator_dev *regulator_dev_lookup(struct
device *dev,
if (dev)
devname = dev_name(dev);
+ mutex_lock(®ulator_list_mutex);
list_for_each_entry(r, ®ulator_list, list)
- if (strcmp(rdev_get_name(r), supply) == 0)
+ if (strcmp(rdev_get_name(r), supply) == 0 &&
+ get_device(&r->dev)) {
+ mutex_unlock(®ulator_list_mutex);
return r;
+ }
list_for_each_entry(map, ®ulator_map_list, list) {
/* If the mapping has a device set up it must match */
@@ -1371,9 +1380,13 @@ static struct regulator_dev *regulator_dev_lookup(struct
device *dev,
(!devname || strcmp(map->dev_name, devname)))
continue;
- if (strcmp(map->supply, supply) == 0)
+ if (strcmp(map->supply, supply) == 0 &&
+ get_device(&map->regulator->dev)) {
+ mutex_unlock(®ulator_list_mutex);
return map->regulator;
+ }
}
+ mutex_unlock(®ulator_list_mutex);
return NULL;
@@ -1405,6 +1418,7 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
if (!r) {
if (have_full_constraints()) {
r = dummy_regulator_rdev;
+ get_device(&r->dev);
} else {
dev_err(dev, "Failed to resolve %s-supply for %s\n",
rdev->supply_name, rdev->desc->name);
@@ -1414,12 +1428,16 @@ static int regulator_resolve_supply(struct
regulator_dev *rdev)
/* Recursively resolve the supply of the supply */
ret = regulator_resolve_supply(r);
- if (ret < 0)
+ if (ret < 0) {
+ put_device(&r->dev);
return ret;
+ }
ret = set_supply(rdev, r);
- if (ret < 0)
+ if (ret < 0) {
+ put_device(&r->dev);
return ret;
+ }
/* Cascade always-on state to supply */
if (_regulator_is_enabled(rdev) && rdev->supply) {
@@ -1455,8 +1473,6 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
else
ret = -EPROBE_DEFER;
- mutex_lock(®ulator_list_mutex);
-
rdev = regulator_dev_lookup(dev, id, &ret);
if (rdev)
goto found;
@@ -1468,7 +1484,7 @@ static struct regulator *_regulator_get(struct device
*dev, cons
Re: [PATCH] tty: fix data races on tty_buffer.commit
Split this into 2 separate fixes (mailed separately).
Also dropped some READ/WRITE_ONCE. We would like to commit them as
well for the following reasons:
https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE
What do you think about using READ/WRITE_ONCE for all concurrent
accesses to non-constant shared state in tty code?
After discovering some low-hanging data races we will proceed to
suppressing functions with "benign" data races, otherwise it becomes
unmanageable:
https://github.com/google/ktsan/blob/tsan/mm/ktsan/supp.c
Thank you
On Fri, Sep 4, 2015 at 10:13 PM, Dmitry Vyukov wrote:
> On Fri, Sep 4, 2015 at 9:49 PM, Peter Hurley wrote:
>> On 09/04/2015 03:37 PM, Dmitry Vyukov wrote:
>>> On Fri, Sep 4, 2015 at 9:34 PM, Peter Hurley
>>> wrote:
Hi Dmitry,
On 09/04/2015 03:09 PM, Dmitry Vyukov wrote:
> Race on buffer data happens in the following scenario:
> __tty_buffer_request_room does a plain write of tail->commit,
> no barriers were executed before that.
> At this point flush_to_ldisc reads this new value of commit,
> and reads buffer data, no barriers in between.
> The committed buffer data is not necessary visible to flush_to_ldisc.
Please submit one patch for each "fix", because it is not possible
to review what you believe you're fixing.
See below for an example.
> Similar bug happens when tty_schedule_flip commits data.
>
> Another race happens in tty_buffer_flush. It uses plain reads
> to read tty_buffer.next, as the result it can free a buffer
> which has pending writes in __tty_buffer_request_room thread.
> For example, tty_buffer_flush calls tty_buffer_free which
> reads b->size, the size may not be visible to this thread.
> As the result a large buffer can hang in the freelist.
>
> Update commit with smp_store_release and read commit with
> smp_load_acquire, as it is commit that signals data readiness.
> This is orthogonal to the existing synchronization on tty_buffer.next,
> which is required to not dismiss a buffer with unconsumed data.
>
> The data race was found with KernelThreadSanitizer (KTSAN).
>
> Signed-off-by: Dmitry Vyukov
> ---
> drivers/tty/tty_buffer.c | 38 --
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> index 4cf263d..4fae5d1 100644
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -89,7 +89,7 @@ void tty_buffer_unlock_exclusive(struct tty_port *port)
> struct tty_bufhead *buf = &port->buf;
> int restart;
>
> - restart = buf->head->commit != buf->head->read;
> + restart = READ_ONCE(buf->head->commit) != buf->head->read;
>
> atomic_dec(&buf->priority);
> mutex_unlock(&buf->lock);
> @@ -242,11 +242,14 @@ void tty_buffer_flush(struct tty_struct *tty,
> struct tty_ldisc *ld)
> atomic_inc(&buf->priority);
>
> mutex_lock(&buf->lock);
> - while ((next = buf->head->next) != NULL) {
> + /* paired with smp_store_release in __tty_buffer_request_room();
> + * ensures there are no outstanding writes to buf->head when we
> free it
> + */
> + while ((next = smp_load_acquire(&buf->head->next)) != NULL) {
> tty_buffer_free(port, buf->head);
> buf->head = next;
> }
> - buf->head->read = buf->head->commit;
> + buf->head->read = READ_ONCE(buf->head->commit);
>
> if (ld && ld->ops->flush_buffer)
> ld->ops->flush_buffer(tty);
> @@ -290,13 +293,15 @@ static int __tty_buffer_request_room(struct
> tty_port *port, size_t size,
> if (n != NULL) {
> n->flags = flags;
> buf->tail = n;
> - b->commit = b->used;
> - /* paired w/ barrier in flush_to_ldisc(); ensures
> the
> - * latest commit value can be read before the head
> is
> - * advanced to the next buffer
> + /* paired with smp_load_acquire in flush_to_ldisc();
> + * ensures flush_to_ldisc() sees buffer data.
>*/
> - smp_wmb();
> - b->next = n;
> + smp_store_release(&b->commit, b->used);
> + /* paired with smp_load_acquire in flush_to_ldisc();
> + * ensures the latest commit value can be read
> before
> + * the head is advanced to the next buffer
> + */
> + smp_store_release(&b->next, n);
> } else if (change)
>
Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT
On 06/09/15 06:56, Jiang Liu wrote: > On 2015/9/6 12:23, Yang Yingliang wrote: >> Use irq_settings_set_move_pcntxt() helper irqs status with >> _IRQ_MOVE_PCNTXT. So that it can do set affinity when calling >> irq_set_affinity_locked(). > Hi Yingliang, > We could only set _IRQ_MOVE_PCNTCT flag to enable migrating > IRQ in process context if your hardware platform supports atomically > change IRQ configuration. Not sure whether that's true for GICv3. > If GICv3 doesn't support atomically change irq configuration, this > change may cause trouble. I think it boils down to what exactly "process context" means here. If this means "we do not need to mask the interrupt" while moving it, then it should be fine (the GIC architecture guarantees that a pending interrupt will be migrated). Is there any other requirement for this flag? Thanks, M. -- Jazz is not dead. It just smells funny... -- 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 0/5] KVM: optimize userspace exits with a new ioctl
On 02/09/2015 12:31, Christian Borntraeger wrote: > As far as I can see this should also work for s390 (when we implement > REQ_EXIT handling) > > To double check my understanding: these improvements come with a changed > userspace that does not use KVM_SET_SIGNAL_MASK and therefore this > conditional is false > if (vcpu->sigset_active) > sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved); > Correct? > > That also means we improve exits that go to userspace but lightweight exits > that stay inside the kernel are not affected. Yes, both observations are correct. Paolo -- 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] Documentation: add Device tree bindings for hwmon/nct7802
On Sun, Sep 06, 2015 at 10:59:49PM +0100, Constantine Shulyupin wrote:
> Changed in v2:
> - Removed nct7802,reg-init
> - Added registers initialization by names
>
> Introduced in v1:
> - nct7802,reg-init
>
> Signed-off-by: Constantine Shulyupin
> ---
> ---
> .../devicetree/bindings/hwmon/nct7802.txt | 24
> ++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt
> b/Documentation/devicetree/bindings/hwmon/nct7802.txt
> new file mode 100644
> index 000..56214bf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
> @@ -0,0 +1,24 @@
> +Nuvoton NCT7802Y Hardware Monitoring IC
> +
> +Required node properties:
> +
> + - "compatible": must be "nuvoton,nct7802"
> + - "reg": I2C bus address of the device
> +
> +Optional properties:
> +
> +One byte registers:
> + - nct7802,Start
> + - nct7802,Mode
> + - nct7802,EnPECI
> + - nct7802,EnFan
> + - nct7802,EnV
The binding doesn't describe what these actually represent, what type
they are, etc.
Also, "nct7802" is not a vendor prefix, and the camelcase naming is
unusual.
Why do you think you need these? Why must raw valeus be used rather than
giving the kernel the information it needs to derive these for itself?
Mark.
> +
> +Example nct7802 node:
> +
> +nct7802 {
> + compatible = "nuvoton,nct7802";
> + reg = <0x2a>;
> + nct7802,Start = <0x01>;
> + nct7802,Mode = <0x7E>; // RTD1_MD = 2
> +};
> --
> 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 1/3] perf tests: Introduce iterator function for tests
On Sat, Sep 05, 2015 at 08:02:20PM +0100, Matt Fleming wrote: > From: Matt Fleming > > In preparation for introducing more arrays of tests, e.g. "arch tests" > (architecture-specific tests), abstract the code to iterate over the > list of tests into a helper function. > > This way, code that uses a 'struct test' doesn't need to worry about > how the tests are grouped together and changes to the list of tests > doesn't require changes to the code using it. > > Cc: Peter Zijlstra > Cc: Jiri Olsa > Cc: Arnaldo Carvalho de Melo > Signed-off-by: Matt Fleming Acked-by: Jiri Olsa thanks, jirka -- 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] staging: gdm72xx: fix memory leak
We were successfully requesting the firmware but on error it was not
being released.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/gdm72xx/usb_boot.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/gdm72xx/usb_boot.c
b/drivers/staging/gdm72xx/usb_boot.c
index 3ccc447..50fbec3 100644
--- a/drivers/staging/gdm72xx/usb_boot.c
+++ b/drivers/staging/gdm72xx/usb_boot.c
@@ -159,8 +159,10 @@ int usb_boot(struct usb_device *usbdev, u16 pid)
}
tx_buf = kmalloc(DOWNLOAD_SIZE, GFP_KERNEL);
- if (tx_buf == NULL)
+ if (tx_buf == NULL) {
+ release_firmware(firm);
return -ENOMEM;
+ }
if (firm->size < sizeof(hdr)) {
dev_err(&usbdev->dev, "Cannot read the image info.\n");
@@ -285,8 +287,10 @@ static int em_download_image(struct usb_device *usbdev,
const char *img_name,
}
buf = kmalloc(DOWNLOAD_CHUCK + pad_size, GFP_KERNEL);
- if (buf == NULL)
+ if (buf == NULL) {
+ release_firmware(firm);
return -ENOMEM;
+ }
strcpy(buf+pad_size, type_string);
ret = gdm_wibro_send(usbdev, buf, strlen(type_string)+pad_size);
--
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 2/2] staging: gdm72xx: NULL comparison style
checkpatch complains if NULL comparison is done as if (var == NULL)
Signed-off-by: Sudip Mukherjee
---
drivers/staging/gdm72xx/gdm_qos.c | 2 +-
drivers/staging/gdm72xx/gdm_sdio.c | 20 ++--
drivers/staging/gdm72xx/gdm_usb.c | 16
drivers/staging/gdm72xx/gdm_wimax.c | 4 ++--
drivers/staging/gdm72xx/sdio_boot.c | 4 ++--
drivers/staging/gdm72xx/usb_boot.c | 4 ++--
6 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/gdm72xx/gdm_qos.c
b/drivers/staging/gdm72xx/gdm_qos.c
index 96bf2bf..72c0f7ef 100644
--- a/drivers/staging/gdm72xx/gdm_qos.c
+++ b/drivers/staging/gdm72xx/gdm_qos.c
@@ -190,7 +190,7 @@ static int get_qos_index(struct nic *nic, u8 *iph, u8
*tcpudph)
int ip_ver, i;
struct qos_cb_s *qcb = &nic->qos;
- if (iph == NULL || tcpudph == NULL)
+ if (!iph || !tcpudph)
return -1;
ip_ver = (iph[0]>>4)&0xf;
diff --git a/drivers/staging/gdm72xx/gdm_sdio.c
b/drivers/staging/gdm72xx/gdm_sdio.c
index a5fd079..b0521da 100644
--- a/drivers/staging/gdm72xx/gdm_sdio.c
+++ b/drivers/staging/gdm72xx/gdm_sdio.c
@@ -173,12 +173,12 @@ static int init_sdio(struct sdiowm_dev *sdev)
spin_lock_init(&tx->lock);
tx->sdu_buf = kmalloc(SDU_TX_BUF_SIZE, GFP_KERNEL);
- if (tx->sdu_buf == NULL)
+ if (!tx->sdu_buf)
goto fail;
for (i = 0; i < MAX_NR_SDU_BUF; i++) {
t = alloc_tx_struct(tx);
- if (t == NULL) {
+ if (!t) {
ret = -ENOMEM;
goto fail;
}
@@ -192,7 +192,7 @@ static int init_sdio(struct sdiowm_dev *sdev)
for (i = 0; i < MAX_NR_RX_BUF; i++) {
r = alloc_rx_struct(rx);
- if (r == NULL) {
+ if (!r) {
ret = -ENOMEM;
goto fail;
}
@@ -200,7 +200,7 @@ static int init_sdio(struct sdiowm_dev *sdev)
}
rx->rx_buf = kmalloc(RX_BUF_SIZE, GFP_KERNEL);
- if (rx->rx_buf == NULL)
+ if (!rx->rx_buf)
goto fail;
return 0;
@@ -359,7 +359,7 @@ static void do_tx(struct work_struct *work)
is_sdu = 1;
}
- if (!is_sdu && t == NULL) {
+ if (!is_sdu && !t) {
spin_unlock_irqrestore(&tx->lock, flags);
return;
}
@@ -393,7 +393,7 @@ static int gdm_sdio_send(void *priv_dev, void *data, int
len,
cmd_evt = (pkt[0] << 8) | pkt[1];
if (cmd_evt == WIMAX_TX_SDU) {
t = get_tx_struct(tx, &no_spc);
- if (t == NULL) {
+ if (!t) {
/* This case must not happen. */
spin_unlock_irqrestore(&tx->lock, flags);
return -ENOSPC;
@@ -407,7 +407,7 @@ static int gdm_sdio_send(void *priv_dev, void *data, int
len,
t->cb_data = cb_data;
} else {
t = alloc_tx_struct(tx);
- if (t == NULL) {
+ if (!t) {
spin_unlock_irqrestore(&tx->lock, flags);
return -ENOMEM;
}
@@ -581,7 +581,7 @@ static int gdm_sdio_receive(void *priv_dev,
spin_lock_irqsave(&rx->lock, flags);
r = get_rx_struct(rx);
- if (r == NULL) {
+ if (!r) {
spin_unlock_irqrestore(&rx->lock, flags);
return -ENOMEM;
}
@@ -615,12 +615,12 @@ static int sdio_wimax_probe(struct sdio_func *func,
return ret;
phy_dev = kzalloc(sizeof(*phy_dev), GFP_KERNEL);
- if (phy_dev == NULL) {
+ if (!phy_dev) {
ret = -ENOMEM;
goto out;
}
sdev = kzalloc(sizeof(*sdev), GFP_KERNEL);
- if (sdev == NULL) {
+ if (!sdev) {
ret = -ENOMEM;
goto out;
}
diff --git a/drivers/staging/gdm72xx/gdm_usb.c
b/drivers/staging/gdm72xx/gdm_usb.c
index eac2f34..16e497d 100644
--- a/drivers/staging/gdm72xx/gdm_usb.c
+++ b/drivers/staging/gdm72xx/gdm_usb.c
@@ -139,7 +139,7 @@ static struct usb_rx *get_rx_struct(struct rx_cxt *rx)
if (list_empty(&rx->free_list)) {
r = alloc_rx_struct(rx);
- if (r == NULL)
+ if (!r)
return NULL;
list_add(&r->list, &rx->free_list);
@@ -224,7 +224,7 @@ static int init_usb(struct usbwm_dev *udev)
spin_lock_irqsave(&tx->lock, flags);
for (i = 0; i < MAX_NR_SDU_BUF; i++) {
t = alloc_tx_struct(tx);
- if (t == NULL) {
+ if (!t) {
spin_unlock_irqrestore(&tx->lock, flags);
ret = -ENOMEM;
goto fail;
@@ -234,7 +234,7 @@ static int init_usb(struct usbwm_dev *udev)
spin_unlock_irqrestore(&tx->lock, flags);
r =
[PATCH v3 0/2] ring_buffer: Make the benchmark slightly more safe
These two patches fix potential races in the ring buffer benchmark. The first two versions were reviewed as part of the patchset that tried to convert some kthreads into the kthread worker API, see http://thread.gmane.org/gmane.linux.kernel.api/13224/focus=13821 Changes in v3: + fixed several comments (suggested by Steven) + removed duplicate memory barrier (suggested by Steven) Changes in v2: + keep the extra initialization; fix a race instead + move the setting of the current state (suggested by Steven) Petr Mladek (2): ring_buffer: Do no not complete benchmark reader too early ring_buffer: Fix more races when terminating the producer in the benchmark kernel/trace/ring_buffer_benchmark.c | 77 1 file changed, 44 insertions(+), 33 deletions(-) -- 1.8.5.6 -- 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 1/2] ring_buffer: Do no not complete benchmark reader too early
It seems that complete(&read_done) might be called too early
in some situations.
1st scenario:
-
CPU0CPU1
ring_buffer_producer_thread()
wake_up_process(consumer);
wait_for_completion(&read_start);
ring_buffer_consumer_thread()
complete(&read_start);
ring_buffer_producer()
# producing data in
# the do-while cycle
ring_buffer_consumer();
# reading data
# got error
# set kill_test = 1;
set_current_state(
TASK_INTERRUPTIBLE);
if (reader_finish) # false
schedule();
# producer still in the middle of
# do-while cycle
if (consumer && !(cnt % wakeup_interval))
wake_up_process(consumer);
# spurious wakeup
while (!reader_finish &&
!kill_test)
# leaving because
# kill_test == 1
reader_finish = 0;
complete(&read_done);
1st BANG: We might access uninitialized "read_done" if this is the
the first round.
# producer finally leaving
# the do-while cycle because kill_test == 1;
if (consumer) {
reader_finish = 1;
wake_up_process(consumer);
wait_for_completion(&read_done);
2nd BANG: This will never complete because consumer already did
the completion.
2nd scenario:
-
CPU0CPU1
ring_buffer_producer_thread()
wake_up_process(consumer);
wait_for_completion(&read_start);
ring_buffer_consumer_thread()
complete(&read_start);
ring_buffer_producer()
# CPU3 removes the module <--- difference from
# and stops producer <--- the 1st scenario
if (kthread_should_stop())
kill_test = 1;
ring_buffer_consumer();
while (!reader_finish &&
!kill_test)
# kill_test == 1 => we never go
# into the top level while()
reader_finish = 0;
complete(&read_done);
# producer still in the middle of
# do-while cycle
if (consumer && !(cnt % wakeup_interval))
wake_up_process(consumer);
# spurious wakeup
while (!reader_finish &&
!kill_test)
# leaving because kill_test == 1
reader_finish = 0;
complete(&read_done);
BANG: We are in the same "bang" situations as in the 1st scenario.
Root of the problem:
ring_buffer_consumer() must complete "read_done" only when "reader_finish"
variable is set. It must not be skipped due to other conditions.
Note that we still must keep the check for "reader_finish" in a loop
because there might be spurious wakeups as described in the
above scenarios.
Solution:
--
The top level cycle in ring_buffer_consumer() will finish only when
"reader_finish" is set. The data will be read in "while-do" cycle
so that they are not read after an error (kill_test == 1)
or a spurious wake up.
In addition, "reader_finish" is manipulated by the producer thread.
Therefore we add READ_ONCE() to make sure that the fresh value is
read in each cycle. Also we add the corresponding barrier
to synchronize the sleep check.
Next we set the state back to TASK_RUNNING for the situation where we
did not sleep.
Just from paranoid reasons, we initialize both completions statically.
This is safer, in case there are other races that we are unaware of.
As a side effect we could remove the memory barrier from
ring_buffer_producer_thread(). IMHO, this was the reason for
the barrier. ring_buffer_reset() uses spin locks that should
provide the needed memory barrier for using the buffer.
Signed-off-by: Petr Mladek
---
kernel/trace/ring_buffer_benchmark.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/ring_buffer_benchmark.c
b/kernel/trace/r
[PATCH v3 2/2] ring_buffer: Fix more races when terminating the producer in the benchmark
The commit b44754d8262d3aab8 ("ring_buffer: Allow to exit the ring
buffer benchmark immediately") added a hack into ring_buffer_producer()
that set @kill_test when kthread_should_stop() returned true. It improved
the situation a lot. It stopped the kthread in most cases because
the producer spent most of the time in the patched while cycle.
But there are still few possible races when kthread_should_stop()
is set outside of the cycle. Then we do not set @kill_test and
some other checks pass.
This patch adds a better fix. It renames @test_kill/TEST_KILL() into
a better descriptive @test_error/TEST_ERROR(). Also it introduces
break_test() function that checks for both @test_error and
kthread_should_stop().
The new function is used in the producer when the check for @test_error
is not enough. It is not used in the consumer because its state
is manipulated by the producer via the "reader_finish" variable.
Also we add a missing check into ring_buffer_producer_thread()
between setting TASK_INTERRUPTIBLE and calling schedule_timeout().
Otherwise, we might miss a wakeup from kthread_stop().
Signed-off-by: Petr Mladek
---
kernel/trace/ring_buffer_benchmark.c | 54 +++-
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/kernel/trace/ring_buffer_benchmark.c
b/kernel/trace/ring_buffer_benchmark.c
index 9ea7949366b3..9e00fd178226 100644
--- a/kernel/trace/ring_buffer_benchmark.c
+++ b/kernel/trace/ring_buffer_benchmark.c
@@ -60,12 +60,12 @@ MODULE_PARM_DESC(consumer_fifo, "fifo prio for consumer");
static int read_events;
-static int kill_test;
+static int test_error;
-#define KILL_TEST()\
+#define TEST_ERROR() \
do {\
- if (!kill_test) { \
- kill_test = 1; \
+ if (!test_error) { \
+ test_error = 1; \
WARN_ON(1); \
} \
} while (0)
@@ -75,6 +75,11 @@ enum event_status {
EVENT_DROPPED,
};
+static bool break_test(void)
+{
+ return test_error || kthread_should_stop();
+}
+
static enum event_status read_event(int cpu)
{
struct ring_buffer_event *event;
@@ -87,7 +92,7 @@ static enum event_status read_event(int cpu)
entry = ring_buffer_event_data(event);
if (*entry != cpu) {
- KILL_TEST();
+ TEST_ERROR();
return EVENT_DROPPED;
}
@@ -115,10 +120,10 @@ static enum event_status read_page(int cpu)
rpage = bpage;
/* The commit may have missed event flags set, clear them */
commit = local_read(&rpage->commit) & 0xf;
- for (i = 0; i < commit && !kill_test; i += inc) {
+ for (i = 0; i < commit && !test_error ; i += inc) {
if (i >= (PAGE_SIZE - offsetof(struct rb_page, data))) {
- KILL_TEST();
+ TEST_ERROR();
break;
}
@@ -128,7 +133,7 @@ static enum event_status read_page(int cpu)
case RINGBUF_TYPE_PADDING:
/* failed writes may be discarded events */
if (!event->time_delta)
- KILL_TEST();
+ TEST_ERROR();
inc = event->array[0] + 4;
break;
case RINGBUF_TYPE_TIME_EXTEND:
@@ -137,12 +142,12 @@ static enum event_status read_page(int cpu)
case 0:
entry = ring_buffer_event_data(event);
if (*entry != cpu) {
- KILL_TEST();
+ TEST_ERROR();
break;
}
read++;
if (!event->array[0]) {
- KILL_TEST();
+ TEST_ERROR();
break;
}
inc = event->array[0] + 4;
@@ -150,17 +155,17 @@ static enum event_status read_page(int cpu)
default:
entry = ring_buffer_event_data(event);
if (*entry != cpu) {
- KILL_TEST();
+ TEST_ERROR();
break;
}
read++;
inc = ((event->type_len + 1) * 4);
Re: [PATCH] mm/mmap.c: Remove useless statement "vma = NULL" in find_vma()
On 09/05, Chen Gang wrote:
>
> From b12fa5a9263cf4c044988e59f0071f4bcc132215 Mon Sep 17 00:00:00 2001
> From: Chen Gang
> Date: Sat, 5 Sep 2015 21:49:56 +0800
> Subject: [PATCH] mm/mmap.c: Remove useless statement "vma = NULL" in
> find_vma()
>
> Before the main looping, vma is already is NULL, so need not set it to
> NULL, again.
>
> Signed-off-by: Chen Gang
Reviewed-by: Oleg Nesterov
> ---
> mm/mmap.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index df6d5f0..4db7cf0 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2054,7 +2054,6 @@ struct vm_area_struct *find_vma(struct mm_struct *mm,
> unsigned long addr)
> return vma;
>
> rb_node = mm->mm_rb.rb_node;
> - vma = NULL;
>
> while (rb_node) {
> struct vm_area_struct *tmp;
> --
> 1.9.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 0/6] sched/fair: Compute capacity invariant load/utilization tracking
On Mon, Aug 31, 2015 at 11:24:49AM +0200, Peter Zijlstra wrote: > A quick run here gives: > > IVB-EP (2*20*2): As noted by someone; that should be 2*10*2, for a total of 40 cpus in this machine. > > perf stat --null --repeat 10 -- perf bench sched messaging -g 50 -l 5000 > > Before: After: > 5.484170711 ( +- 0.74% ) 5.590001145 ( +- 0.45% ) > > Which is an almost 2% slowdown :/ > > I've yet to look at what happens. OK, so it appears this is link order nonsense. When I compared profiles between the series, the one function that had significant change was skb_release_data(), which doesn't make much sense. If I do a 'make clean' in front of each build, I get a repeatable improvement with this patch set (although how much of that is due to the patches itself or just because of code movement is as yet undetermined). I'm of a mind to apply these patches; with two patches on top, which I'll post shortly. -- 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/
