[PATCH v3] iwlwifi: dvm: use alloc_ordered_workqueue()
Use alloc_ordered_workqueue() to allocate the workqueue instead of
create_singlethread_workqueue() since the latter is deprecated and is scheduled
for removal.
There are work items doing related operations that shouldn't be swapped when
queued in a certain order hence preserve the strict execution ordering of a
single threaded (ST) workqueue by switching to alloc_ordered_workqueue().
WQ_MEM_RECLAIM flag is not needed since the worker is not depended
during memory reclaim.
Signed-off-by: Eva Rachel Retuya
Acked-by: Tejun Heo
---
Changes in v3:
* revise commit message about WQ_MEM_RECLAIM
* add 'Acked-by:' from previous feedback
Changes in v2:
* switch from alloc_workqueue() to alloc_ordered_workqueue()
* remove unneeded flags: WQ_MEM_RECLAIM and WQ_HIGHPRI
* update commit message to reflect change
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
index f62c2d7..14396d8 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
@@ -1071,7 +1071,7 @@ static void iwl_bg_restart(struct work_struct *data)
static void iwl_setup_deferred_work(struct iwl_priv *priv)
{
- priv->workqueue = create_singlethread_workqueue(DRV_NAME);
+ priv->workqueue = alloc_ordered_workqueue(DRV_NAME, 0);
INIT_WORK(&priv->restart, iwl_bg_restart);
INIT_WORK(&priv->beacon_update, iwl_bg_beacon_update);
--
1.9.1
Re: [PATCH 4/5] pwm: pwm-tipwmss: Update documentation to use empty range property
On 03/17/2016 10:01 AM, Rob Herring wrote:
> On Mon, Mar 07, 2016 at 01:51:57PM -0600, Franklin S Cooper Jr wrote:
>> Since the PWMSS and its subdevices (eCAP and ePWM) use the same address
>> space then the range property should be empty. Update the documentation
>> to show the correct usage.
> Why does it matter? An empty ranges is generally not preferred.
Someone pointed out that ranges should probably be empty. I
double checked it with what is in the ePAPR doc and based on
the definition it should be set to empty. I also checked
against the am33xx.dtsi and saw that both USB and ethernet
uses an empty value for ranges.
Can you elaborate on why this isn't preferable?
>
>> Signed-off-by: Franklin S Cooper Jr
>> ---
>> Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt | 12
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
>> b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
>> index f7eae77..672fa71 100644
>> --- a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
>> @@ -7,11 +7,9 @@ Required properties:
>>Should set to 1.
>> - size-cells: specify number of u32 entries needed to specify child nodes
>> size
>> in reg property. Should set to 1.
>> -- ranges: describes the address mapping of a memory-mapped bus. Should set
>> to
>> - physical address map of child's base address, physical address within
>> - parent's address space and length of the address map. For am33xx,
>> - 3 set of child register maps present, ECAP register space, EQEP
>> - register space, EHRPWM register space.
>> +- ranges: describes the address mapping of a memory-mapped bus. Its value
>> + should be empty since no address translation is needed between the
>> + parent and the child.
>>
>> Also child nodes should also populated under PWMSS DT node.
>>
>> @@ -23,9 +21,7 @@ pwmss0: pwmss@4830 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> status = "disabled";
>> -ranges = <0x48300100 0x48300100 0x80 /* ECAP */
>> - 0x48300180 0x48300180 0x80 /* EQEP */
>> - 0x48300200 0x48300200 0x80>; /* EHRPWM */
>> +ranges;
>>
>> /* child nodes go here */
>> };
>> --
>> 2.7.0
>>
Re: [PATCH 04/15] irqchip/gic: WARN if setting the interrupt type fails
On 18/03/16 09:20, Geert Uytterhoeven wrote: > On Thu, Mar 17, 2016 at 5:20 PM, Jon Hunter wrote: >> On 17/03/16 15:18, Jason Cooper wrote: >>> On Thu, Mar 17, 2016 at 03:04:01PM +, Jon Hunter wrote: On 17/03/16 14:51, Thomas Gleixner wrote: > On Thu, 17 Mar 2016, Jon Hunter wrote: >> Setting the interrupt type for private peripheral interrupts (PPIs) may >> not be supported by a given GIC because it is IMPLEMENTATION DEFINED >> whether this is allowed. There is no way to know if setting the type is >> supported for a given GIC and so the value written is read back to >> verify it matches the desired configuration. If it does not match then >> an error is return. >> >> There are cases where the interrupt configuration read from firmware >> (such as a device-tree blob), has been incorrect and hence >> gic_configure_irq() has returned an error. This error has gone >> undetected because the error code returned was ignored but the interrupt >> still worked fine because the configuration for the interrupt could not >> be overwritten. >> >> Given that this has done undetected and we should only fail to set the >> type for PPIs whose configuration cannot be changed anyway, don't return >> an error and simply WARN if this fails. This will allows us to fix up any >> places in the kernel where we should be checking the return status and >> maintain back compatibility with firmware images that may have incorrect >> interrupt configurations. > > Though silently returning 0 is really the wrong thing to do. You can add > the > warn, but why do you want to return success? Yes that would be the correct thing to do I agree. However, the problem is that if we do this, then after the patch "irqdomain: Don't set type when mapping an IRQ" is applied, we may break interrupts for some existing device-tree binaries that have bad configuration (such as omap4 and tegra20/30 ... see patches 1 and 2) that have gone unnoticed. So it is a back compatibility issue. > > Indeed (also for sh73a0 and r8a7779). Thanks. I was wondering if there are others. Do you know what the correct setting should be? Ie. should it be IRQ_TYPE_EDGE_RISING as well? I can then include this with OMAP and Tegra. >>> This sounds like a textbook case for adding a boolean dt property. If >>> "can-set-ppi-type" is absent (old DT blobs and new blobs without the >>> ability), warn and return zero. If it's present, the driver can set the >>> type, returning errors as encountered. >> >> True. However, if we did have this "can-set-ppi-type" property set for a >> device, it really should never fail (unless someone specified it >> incorrectly). So I am trying to understand the value in adding a new DT >> property. > > Do we really want to add properties that basically indicate that a description > in DT is correct? > > Alternatively, it can be fixed in the kernel in a DT quirk (if SoC == xxx then > fix TWD). I am not sure I fully understand your proposal, but please note that it may not be just limited to the TWD (although this does appear to be the one client that is wrong for a lot of SoCs). PPIs are also used for the armv7/8 timers as well. The problem is that we have a lot of SoCs with twd-timers and I have no way to test all of these to know which could be a problem. So I thought that warning would be a good first step to fixing them. However, I am still trying to see the real value in returning an error in this case. May be I am the only one with that perspective? Cheers Jon
Re: [PATCH V4] PM / clk: Add support for obtaining clocks from device-tree
On Tuesday, March 15, 2016 01:15:16 PM Geert Uytterhoeven wrote: > On Tue, Mar 15, 2016 at 12:33 PM, Jon Hunter wrote: > > The PM clocks framework requires clients to pass either a con-id or a > > valid clk pointer in order to add a clock to a device. Add a new > > function of_pm_clk_add_clks() to allows device clocks to be retrieved > > from device-tree and populated for a given device. Note that it is > > not necessary to make the compilation of this new function dependent > > upon CONFIG_OF because there are stubs functions for the device-tree > > APIs used. > > > > In order to handle errors encountered when adding clocks from > > device-tree, add a function pm_clk_remove_clk() to remove any clocks > > (using a pointer to the clk structure) that have been added > > successfully before the error occurred. > > > > Signed-off-by: Jon Hunter > > Acked-by: Geert Uytterhoeven > Applied. Thanks, Rafael
Re: [PATCH 7/7] regulator: act8865: Init at subsys level
On Monday 29 February 2016 20:35:37 Mark Brown wrote: > On Sun, Feb 28, 2016 at 04:53:29PM +0100, Maarten ter Huurne wrote: > > Since the defined regulators are used in other drivers, we can avoid > > deferred probing by registering this driver sooner. > > No, don't play silly link order games. We are never going to get a > link order that avoids deferred probes, faffing about changing things > to try to make one just leads to lots of noise. If you want to avoid > noise from deferred probe then work on something that communicates > dependencies to the driver core so we don't have to brute force > things, Raphael has some ideas there he's been looking at. On our device the LCD panel is powered by one of the ACT8600 outputs. Avoiding the deferred probe means the screen turns on a couple of seconds earlier. I agree that the current hardcoded priority system is not ideal and a dependency based system would be the right solution in the long term, but I was looking for a short term solution with this patch. In any case, I excluded this patch from the v2 series. I cleaned up the register configuration (debugfs) patch, split the of_node patch into two patches and resubmitted the redundant dev lookups patch. Thanks for reviewing and please let me know if there is anything more that needs changing. Bye, Maarten
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data
On Wed, Mar 16, 2016 at 03:59:18PM +0100, Rafael J. Wysocki wrote:
> +static void sugov_work(struct work_struct *work)
> +{
> + struct sugov_policy *sg_policy = container_of(work, struct
> sugov_policy, work);
> +
> + mutex_lock(&sg_policy->work_lock);
> + __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
> + CPUFREQ_RELATION_L);
> + mutex_unlock(&sg_policy->work_lock);
> +
Be aware that the below store can creep up and become visible before the
unlock. AFAICT that doesn't really matter, but still.
> + sg_policy->work_in_progress = false;
> +}
> +
> +static void sugov_irq_work(struct irq_work *irq_work)
> +{
> + struct sugov_policy *sg_policy;
> +
> + sg_policy = container_of(irq_work, struct sugov_policy, irq_work);
> + schedule_work(&sg_policy->work);
> +}
If you care what cpu the work runs on, you should schedule_work_on(),
regular schedule_work() can end up on any random cpu (although typically
it does not).
In particular schedule_work() -> queue_work() -> queue_work_on(.cpu =
WORK_CPU_UNBOUND) -> __queue_work() if (req_cpu == UNBOUND) cpu =
wq_select_unbound_cpu(), which has a Round-Robin 'feature' to detect
just such dependencies.
Re: [PATCH 2/5] ftrace perf: Move exclude_kernel tracepoint check to init event
On Wed, 16 Mar 2016 15:34:30 +0100 Jiri Olsa wrote: > We suppress events with attr::exclude_kernel set when > the event is generated, so following capture will > give no warning but won't produce any data: > > $ sudo perf record -e sched:sched_switch:u ls > $ sudo /perf script | wc -l > 0 > > Checking the attr::exclude_(kernel|user) at the event > init time and failing right away for tracepoints from > uprobes/kprobes and native ones: > > $ sudo perf record -e sched:sched_switch:u ls > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for > event (sched:sched_switch). > /bin/dmesg may provide additional information. > No CONFIG_PERF_EVENTS=y kernel support configured? > > $ sudo perf record -e probe:sys_read:u ls > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for > event (probe:sys_read). > /bin/dmesg may provide additional information. > No CONFIG_PERF_EVENTS=y kernel support configured? > > $ ./perf record -e probe_ex:main:k ./ex > Error: > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for > event (probe_ex:main). > /bin/dmesg may provide additional information. > No CONFIG_PERF_EVENTS=y kernel support configured? > > Acked-by: Namhyung Kim > Signed-off-by: Jiri Olsa Acked-by: Steven Rostedt -- Steve
Re: [PATCH] iio: add driver for Microchip MCP414X/416X/424X/426X
On Wed, Mar 16, 2016 at 6:25 PM, Slawomir Stepien wrote:
> On Mar 16, 2016 13:30, Peter Meerwald-Stadler wrote:
>> On Wed, 16 Mar 2016, Slawomir Stepien wrote:
>>
>> > The following functionalities are supported:
>> > - write, read from volatile and non volatile memory
>> > - increase and decrease commands
>> > - read from status register
>> > - write and read to tcon register
>> >
>> > Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/22059b.pdf
>
> Thank you for all your comments.
>
>> the driver naming is a mess: the subject says MCP414X, the file name is
>> mcp41xx, the DT compatible string says mcp4113x -- this does not match
>
> OK. I will change that to mcp414x in version 2.
Filename shouldn't be generic (e.g ending with xx). It should be a
specific chip name
(a good candidate is the first in alphabetical order), because there
could be chips falling
in the same name category but with a different driver.
>
>> plenty of the private API, some of which seems to be debug only?
>> what is really needed to interact with a poti?
>
> I wanted to export both the non volatile and volatile memory addresses for
> wiper
> position access. That is bare minimum for the poti to operate.
>
> But I also wanted to export additional features of this chip. That is way
> there
> is increase and decrease API, and STATUS and TCON register access.
>
> The memory_map API is a way to access all the not used by chip memory
> addresses.
> This API I think could be deleted. But I still think that some people might
> find
> it useful.
>
>> comments below
>>
>> > +File: /sys/bus/iio/devices/../out_resistanceN_raw
>>
>> this is already described in sysfs-bus-iio
>
> Should I leave it and add reference to sysfs-bus-iio or delete it completely?
>
>> > +struct mcp41xx_cfg {
>> > + unsigned long int devid;
>>
>> devid is not set/used
>
> That's true. Will fix it in v2.
>
>> > +static int mcp41xx_exec(struct mcp41xx_data *data,
>> > + u8 addr, u8 cmd,
>> > + int *trans, size_t n)
>>
>> should trans really be int, not u8?
>
> There is a need for 9 bit value write/read. I used int just for my
> convenience.
> However there is one piece of code missing now I see. I should check the value
> of tans[0] to see if it's > 256 or lower then 0. Will add it in v2.
>
> Using u8 will force additional bit operations. I could try using u16 to still
> have the option of parsing user input as 9 bit value (eg. 256 position).
>
>> > +{
>> > + int err;
>> > + struct spi_device *spi = data->spi;
>> > +
>> > + /* Two bytes are needed for the response */
>> > + if (n != 2)
>> > + return -EINVAL;
>>
>> why pass n if it is always 2?
>
> Will fix in v2.
>
>> > + err = devm_iio_device_register(&spi->dev, indio_dev);
>> > + if (err) {
>> > + dev_info(&spi->dev, "Unable to register %s", indio_dev->name);
>>
>> \n missing
>>
>> > + return err;
>> > + }
>> > +
>> > + dev_info(&spi->dev, "Registered %s", indio_dev->name);
>>
>> \n
>>
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static int mcp41xx_remove(struct spi_device *spi)
>> > +{
>> > + struct iio_dev *indio_dev = spi_get_drvdata(spi);
>> > + struct mcp41xx_data *data = iio_priv(indio_dev);
>> > +
>> > + mutex_destroy(&data->lock);
>> > + devm_iio_device_unregister(&spi->dev, indio_dev);
>> > + kfree(mcp41xx_attributes);
>> > +
>> > + dev_info(&spi->dev, "Unregistered %s", indio_dev->name);
>
> Also \n is missing here. Will fix in v2.
>
> --
> Slawomir Stepien
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()
On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches wrote:
[]
> > It's a name that seems like it should be a straightforward
> > cast of a kernel pointer to a __user pointer like:
> >
> > static inline void __user *to_user_ptr(void *p)
> > {
> > return (void __user *)p;
> > }
> ahh, ok. I guess I was used to using it in the context of ioctl
> structs.. in that context u64 -> (void __user *) made more sense.
>
> Maybe uapi_to_ptr()? (ok, not super-creative.. maybe someone has a
> better idea)
Maybe u64_to_user_ptr?
Re: 4.5.0+ panic when setup loop device
On Thu, 2016-03-17 at 10:52 +0100, Peter Zijlstra wrote: > Andreas; Borislav said to Cc you since you wrote all this. > The issue is that Linux assumes: > > > nr_logical_cpus = nr_cores * nr_siblings It also seems to now assume that if SMT is possible, it's enabled. Below is my 8 socket DL980 G7, which has SMT turned off for RT testing, booting NOPREEMPT master tuned for maximum bloat ala distro and getting confused by me telling it (as always) nr_cpus=64. Bad juju ensues. [0.216180] max_cores: 8, cpu_ids: 64, num_siblings: 2, coreid_bits: 5 [0.226593] smpboot: Max logical packages: 4 <== not [0.233742] smpboot: APIC(0) Converting physical 0 to logical package 0 [0.244233] smpboot: APIC(20) Converting physical 1 to logical package 1 [0.253765] smpboot: APIC(40) Converting physical 2 to logical package 2 [0.264081] smpboot: APIC(60) Converting physical 3 to logical package 3 [0.274827] smpboot: APIC(80) Package 4 exceeds logical package map [0.284705] smpboot: CPU 32 APICId 80 disabled [0.292277] smpboot: APIC(a0) Package 5 exceeds logical package map [0.302141] smpboot: CPU 40 APICId a0 disabled [0.308607] smpboot: APIC(c0) Package 6 exceeds logical package map [0.321682] smpboot: CPU 48 APICId c0 disabled [0.328179] smpboot: APIC(e0) Package 7 exceeds logical package map [0.337902] smpboot: CPU 56 APICId e0 disabled [0.345695] DMAR: Host address width 40 [0.351511] DMAR: DRHD base: 0x00b010 flags: 0x0 [0.360018] DMAR: dmar0: reg_base_addr b010 ver 1:0 cap c90780106f0462 ecap f0207e [0.373342] DMAR: DRHD base: 0x00a800 flags: 0x1 [0.383164] DMAR: dmar1: reg_base_addr a800 ver 1:0 cap c90780106f0462 ecap f0207e [0.396475] DMAR: RMRR base: 0x007f7ee000 end: 0x007f7e [0.407255] DMAR: RMRR base: 0x007f7e7000 end: 0x007f7ecfff [0.418136] DMAR: RMRR base: 0x007f62e000 end: 0x007f62 [0.429787] DMAR: ATSR flags: 0x0 [0.434778] DMAR: ATSR flags: 0x0 [0.441624] DMAR-IR: IOAPIC id 10 under DRHD base 0xb010 IOMMU 0 [0.452716] DMAR-IR: IOAPIC id 8 under DRHD base 0xa800 IOMMU 1 [0.465782] DMAR-IR: IOAPIC id 0 under DRHD base 0xa800 IOMMU 1 [0.477123] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. [0.492918] DMAR-IR: Enabled IRQ remapping in x2apic mode [0.502549] x2apic enabled [0.506678] Switched APIC routing to cluster x2apic. [0.519955] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.642858] smpboot: CPU0: Intel(R) Xeon(R) CPU X7560 @ 2.27GHz (family: 0x6, model: 0x2e, stepping: 0x6) [0.668111] Performance Events: PEBS fmt1+, 16-deep LBR, Nehalem events, Broken BIOS detected, complain to your hardware vendor. [0.694907] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is 330) [0.713186] Intel PMU driver. [0.719091] core: CPU erratum AAJ80 worked around [0.731647] core: CPUID marked event: 'bus cycles' unavailable [0.741499] ... version:3 [0.747982] ... bit width: 48 [0.754109] ... generic registers: 4 [0.760980] ... value mask: [0.769336] ... max period: 7fff [0.776913] ... fixed-purpose events: 3 [0.783861] ... event mask: 0007000f [0.793737] x86: Booting SMP configuration: [0.800069] node #0, CPUs:#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 #31 #33 #34 #35 #36 #37 #38 #39 #41 #42 #43 #44 #45 #46 #47 #49 #50 #51 #5> [4.717309] x86: Booted up 1 node, 60 CPUs [4.724551] smpboot: Total of 60 processors activated (271280.00 BogoMIPS) [5.007438] node 0 initialised, 1013474 pages in 36ms
[PATCH v2 7/9] drm: atmel-hlcdc: rework the output code to support drm bridges
The current output code only supports connection to drm panels.
First simplify the drm panel code, and then add support for external drm
bridges.
Signed-off-by: Boris Brezillon
Tested-by: Nicolas Ferre
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 193 +--
2 files changed, 113 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 930d603..b33f19d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -551,7 +551,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device
*dev)
ret = atmel_hlcdc_create_outputs(dev);
if (ret) {
- dev_err(dev->dev, "failed to create panel: %d\n", ret);
+ dev_err(dev->dev, "failed to create HLCDC outputs: %d\n", ret);
return ret;
}
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 75237b5..39802c0 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -34,11 +34,13 @@
* @connector: DRM connector
* @encoder: DRM encoder
* @dc: pointer to the atmel_hlcdc_dc structure
+ * @panel: panel connected on the RGB output
*/
struct atmel_hlcdc_rgb_output {
struct drm_connector connector;
struct drm_encoder encoder;
struct atmel_hlcdc_dc *dc;
+ struct drm_panel *panel;
};
static inline struct atmel_hlcdc_rgb_output *
@@ -54,46 +56,31 @@ drm_encoder_to_atmel_hlcdc_rgb_output(struct drm_encoder
*encoder)
return container_of(encoder, struct atmel_hlcdc_rgb_output, encoder);
}
-/**
- * Atmel HLCDC Panel device structure
- *
- * This structure is specialization of the slave device structure to
- * interface with drm panels.
- *
- * @base: base slave device fields
- * @panel: drm panel attached to this slave device
- */
-struct atmel_hlcdc_panel {
- struct atmel_hlcdc_rgb_output base;
- struct drm_panel *panel;
-};
-
-static inline struct atmel_hlcdc_panel *
-atmel_hlcdc_rgb_output_to_panel(struct atmel_hlcdc_rgb_output *output)
-{
- return container_of(output, struct atmel_hlcdc_panel, base);
-}
-
-static void atmel_hlcdc_panel_encoder_enable(struct drm_encoder *encoder)
+static void atmel_hlcdc_rgb_encoder_enable(struct drm_encoder *encoder)
{
struct atmel_hlcdc_rgb_output *rgb =
drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
- struct atmel_hlcdc_panel *panel = atmel_hlcdc_rgb_output_to_panel(rgb);
- drm_panel_enable(panel->panel);
+
+ if (rgb->panel) {
+ drm_panel_prepare(rgb->panel);
+ drm_panel_enable(rgb->panel);
+ }
}
-static void atmel_hlcdc_panel_encoder_disable(struct drm_encoder *encoder)
+static void atmel_hlcdc_rgb_encoder_disable(struct drm_encoder *encoder)
{
struct atmel_hlcdc_rgb_output *rgb =
drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
- struct atmel_hlcdc_panel *panel = atmel_hlcdc_rgb_output_to_panel(rgb);
- drm_panel_disable(panel->panel);
+ if (rgb->panel) {
+ drm_panel_disable(rgb->panel);
+ drm_panel_unprepare(rgb->panel);
+ }
}
static const struct drm_encoder_helper_funcs
atmel_hlcdc_panel_encoder_helper_funcs = {
- .disable = atmel_hlcdc_panel_encoder_disable,
- .enable = atmel_hlcdc_panel_encoder_enable,
+ .disable = atmel_hlcdc_rgb_encoder_disable,
+ .enable = atmel_hlcdc_rgb_encoder_enable,
};
static void atmel_hlcdc_rgb_encoder_destroy(struct drm_encoder *encoder)
@@ -110,9 +97,11 @@ static int atmel_hlcdc_panel_get_modes(struct drm_connector
*connector)
{
struct atmel_hlcdc_rgb_output *rgb =
drm_connector_to_atmel_hlcdc_rgb_output(connector);
- struct atmel_hlcdc_panel *panel = atmel_hlcdc_rgb_output_to_panel(rgb);
- return panel->panel->funcs->get_modes(panel->panel);
+ if (rgb->panel)
+ return rgb->panel->funcs->get_modes(rgb->panel);
+
+ return 0;
}
static int atmel_hlcdc_rgb_mode_valid(struct drm_connector *connector,
@@ -144,7 +133,13 @@ static const struct drm_connector_helper_funcs
atmel_hlcdc_panel_connector_helpe
static enum drm_connector_status
atmel_hlcdc_panel_connector_detect(struct drm_connector *connector, bool force)
{
- return connector_status_connected;
+ struct atmel_hlcdc_rgb_output *rgb =
+ drm_connector_to_atmel_hlcdc_rgb_output(connector);
+
+ if (rgb->panel)
+ return connector_status_connected;
+
+ return connector_status_disconnected;
}
static void
@@ -152,9 +147,10 @@ atmel_hlcdc_panel_connector_destroy(struct drm_connector
*connector)
{
struct atmel_hlcdc_rgb_outpu
[PATCH v2 0/2] iommu/vt-d: Fault logging improvements
Ratelimit and improve formatting. v2: - Use a single ratelimit state as suggested by Joe Perches, except I chose to move it up to dmar_fault() so that it includes the "handling fault status reg" pr_err and we can avoid collecting entries for logging if we don't plan to print them. - Added reformatting changes suggested by Joe Perches. - While there is clearly more that could be done with disabling fault handling for specific context entries on storm and sending errors to drivers, this makes a marked improvement on its own. Thanks, Alex --- Alex Williamson (2): iommu/vt-d: Ratelimit fault handler iommu/vt-d: Improve fault handler error messages drivers/iommu/dmar.c | 47 +++ 1 file changed, 27 insertions(+), 20 deletions(-)
[RELEASE] LTTng modules 2.8.0-rc1 (Linux kernel tracer)
Hi, We announce the first LTTng 2.8 - "Isseki Nicho" release candidate. LTTng modules is a Linux kernel tracer. The "Isseki Nicho" LTTng release name is a microbrew beer, following our usual theme. Its description: The result of a collaboration between "Dieu du Ciel!" and Nagano-based "Shiga Kogen", Isseki Nicho is a strong Imperial Dark Saison offering a rich roasted malt flavor combined with a complex fruity finish typical of Saison yeasts. Here are the new major features included in this release: --- Real-Time Contexts --- The new "interruptible", "preemptible", "need_reschedule" and Preempt-RT specific "migratable" contexts can be specified with the lttng add-context command. It allows tracing those states for the traced thread. --- Built-in LTTng modules --- It is now possible to build LTTng modules into your Linux kernel image rather than having them as kernel modules. To do so, follow this documentation: https://github.com/lttng/lttng-modules/blob/master/README.md#kernel-built-in-support --- Instrumentation updates --- - The ARM64 architecture is now supported, - x86 page faults are now available, - x86 irq_vectors are now available, - Supports all stable Linux kernels from 2.6.36 to 4.5, as well as currently maintained Preempt-RT kernels (4.4.4-rt11 4.1.19-rt22 4.0.8-rt6 3.18.28-rt28 3.14.64-rt67 3.12.56-rt76 3.10.100-rt110 3.4.110-rt140 3.2.78-rt113). --- Clock plugin support --- A clock plugin modules can now be loaded to override the clock source used by lttng-modules. It can be useful in combination with custom clock source hardware. --- Metadata Regeneration --- A number of users have been using LTTng to trace embedded systems, which often boot with an unset clock, before any NTP correction could occur. Since the wall-time would be sampled before any NTP correction, viewers would generally show traces as having been recorded at an incorrect point in time. This new command, lttng metadata regenerate, forces LTTng to resample the current wall-time to determine an appropriate offset and regenerate a trace's metadata. For more information on this command and its limitations, please refer to lttng-metadata(1). --- Discarded Events and Lost Packets Statistics --- This release adds discarded events and lost packets accounting which allows the LTTng client to print a warning when the tracer was forced to discard events or overwrite packets. The warnings take the following form: [warning] 1234 events discarded, please refer to the documentation on channel configuration. or [warning] 1234 packets, please refer to the documentation on channel configuration. We have decided to add these warnings since a growing number of users have been running analyses based on traces, the result of which may be unreliable when events or packets are dropped. A new packet sequence number was also added to the trace's packet context. This allows viewers to indicate lost packets when the "overwrite" mode is being used. See the LTTng documentation for a detailed explanation of discard and overwrite modes. https://lttng.org/docs/#doc-channel-overwrite-mode-vs-discard-mode We will cover all of these new features in depth in an upcoming post on the official LTTng blog at lttng.org/blog in time for the final release. The official documentation will also be updated to reflect the addition of these new features. As always, please report any issue you may encounter to bugs.lttng.org or on this mailing list. Project website: http://lttng.org Documentation: http://lttng.org/docs Download link: http://lttng.org/download Changelog: 2016-03-18 (Awkward Moments Day) LTTng modules 2.8.0-rc1 * Bump minor tracer ABI version * Fix: build against out-of-tree kernel build * probes/Kbuild: remove upper level header path * Move leftover relative include paths to system paths * syscall instrumentation: use system headers * tracepoint event instrumentation: use system headers * Use system include path in wrappers * libs: use system include paths * Use system header paths in core implementation files * Use system include paths in root directory headers * Use system include paths in probes * Update gitignore * Use system include paths in lttng-types.h * Use system include paths in lttng-tracepoint-event-impl.h * Use system include path in probes/define_trace.h * Use system include paths in probes/lttng-tracepoint-event-impl.h * Rename probes/lttng-events.h to probes/lttng-tracepoint-event-impl.h * Add makefile directory to include path * Fix: event ctx get size should be after chan ctx * Fix: filter interpreter with userspace strings * Fix: rename kvm x86 TRACE_SYSTEM to avoid name clash * Fix: format address fields as hexadecimal * PowerPC-64 ABIv1: add build error if KALLSYMS_ALL is missing * Fix: system call instrumentati
Re: 4.5.0+ panic when setup loop device
On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote: > On Thu, 17 Mar 2016, Peter Zijlstra wrote: > > > Could you please try? I'm not sure how this would explain your loop > > device bug fail, but it certainly pointed towards broken. > > It definitely does not explain it. The wreckage that topo stuff causes is that > it disables a cpu, but that really is not a reason for block/loop to explode. Right. Sadly I could not reproduce that error on my machine. But we can at least start by fixing the 'obvious' problems and then maybe we get more clues ;-)
Re: [PATCH] qeth: Default to allow promiscuous mode
Hello all,
-Alexander Graf wrote: -
>To: linux-s...@vger.kernel.org
>From: Alexander Graf
>Date: 2016-03-17 20:01
>Cc: Evgeny Cherkashin/Russia/IBM@IBMRU, linux-kernel@vger.kernel.org,
>Heiko Carstens , Martin Schwidefsky
>, Ursula Braun ,
>i...@suse.de, m...@suse.com, pwieczorkiew...@suse.de
>Subject: [PATCH] qeth: Default to allow promiscuous mode
>
>When a qeth device is in bridge role, one of the ports of an adapter
>can
>ask for promiscuous mode and get it enabled.
>
>The default until now was to not allow user space to enable
>promiscuous mode
>without switching sysfs attributes as well though, diverging from
>usual
>network device semantics.
>
>This patch sets the default to allow promiscuous enablement. That way
>all
>existing tools "just work", albeit only one port of an adapter can be
>in
>promiscuous mode at a given time.
>
>Signed-off-by: Alexander Graf
>---
> drivers/s390/net/qeth_l2_sys.c | 4
> 1 file changed, 4 insertions(+)
>
>diff --git a/drivers/s390/net/qeth_l2_sys.c
>b/drivers/s390/net/qeth_l2_sys.c
>index 692db49..98c7ac5 100644
>--- a/drivers/s390/net/qeth_l2_sys.c
>+++ b/drivers/s390/net/qeth_l2_sys.c
>@@ -258,6 +258,10 @@ void qeth_l2_setup_bridgeport_attrs(struct
>qeth_card *card)
> return;
> if (!card->options.sbp.supported_funcs)
> return;
>+
>+ /* Allow to set promiscuous by default */
>+ card->options.sbp.reflect_promisc = 1;
>+
> if (card->options.sbp.role != QETH_SBP_ROLE_NONE) {
> /* Conditional to avoid spurious error messages */
> qeth_bridgeport_setrole(card, card->options.sbp.role);
>--
>1.8.5.6
>
>
1. The patch changes the default behaviour (which is, on s390, to ignore
promisc setting) and has potential to break existing setups. One potentially
dangerous scenario is that a Linux instance may inadvertently snatch the
BRIDGEPORT role from a zVM VSWITCH that bridges the HiperSockets LAN to the
outer world, disrupting connectivity for many users.
2. The patch sets the reflect_promisc field without setting the
reflect_promisc_primary field, making it unclear to the user what is the
default role. (It will be "secondary" but it's better to set it explicitly.)
3. The patch should probably go via the -networking maillist.
It seems to me that it would be better to use the sysfs attribute from a
startup script or a udev rule, *only* when the system configuration requires
"real" promiscuous mode, e.g. when the interface is a member of a software
bridge.
Thanks,
Evgeny Cherkashin / Евгений Черкашин / Eugene Crosser (preferred)
Software Engineer, IBM Science and Technology Center, Linux on z-Systems
Development
tel. +7 495 775 8800 ext.1103, Moscow 123317, Presnenskaya emb. 10
Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context
Em Wed, 16 Mar 2016 10:28:35 +0200
Sakari Ailus escreveu:
> Hi Mauro,
>
> On Tue, Mar 15, 2016 at 12:55:35PM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 14 Mar 2016 14:09:09 +0200
> > Sakari Ailus escreveu:
> >
> > > Hi Mauro,
> > >
...
> > > Notify callbacks, perhaps not, but the list is still protected by the
> > > spinlock. It perhaps is not likely that another process would change it
> > > but
> > > I don't think we can rely on that.
> >
> > I can see only 2 risks protected by the lock:
> >
> > 1) mdev gets freed while an entity is being created. This is a problem
> >with the current memory protection schema we're using. I guess the
> >only way to fix it is to use kref for
> > mdev/entities/interfaces/links/pads.
> >This change doesn't make it better or worse.
> >Also, I don't think we have such risk with the current devices.
> >
> > 2) a notifier may be inserted or removed by another driver, while the
> >loop is running.
> >
> > To avoid (2), I see 3 alternatives:
> >
> > a) keep the loop as proposed on this patch. As the list is navigated using
> > list_for_each_entry_safe(), I guess[1] it should be safe to remove/add
> > new notify callbacks there while the loop is running by some other process.
> >
>
> list_for_each_entry_safe() does not protect against concurrent access, only
> against adding and removing list entries by the same user. List access
> serialisation is still needed, whether you use _safe() functions or not.
>
> >
> > [1] It *is* safe if the change were done inside the loop - but I'm not
> > 100% sure that it is safe if some other CPU touches the notify list.
>
> Indeed.
>
> >
> > b) Unlock/relock the spinlock every time:
> >
> > /* previous code that locks mdev->lock spinlock */
> >
> > /* invoke entity_notify callbacks */
> > list_for_each_entry_safe(notify, next, &mdev->entity_notify, list) {
> > spin_unlock(&mdev->lock);
> > (notify)->notify(entity, notify->notify_data);
> > spin_lock(&mdev->lock);
> > }
> >
> > spin_unlock(&mdev->lock);
> >
> > c) use a separate lock for the notify list -this seems to be an overkill.
> >
> > d) Protect it with the graph traversal mutex. That sounds the worse idea,
> >IMHO, as we'll be abusing the lock.
>
> I'd simply replace the spinlock with a mutex here. As we want to get rid of
> the graph mutex anyway in the long run, let's not mix the two as they're
> well separated now. As long as the mutex users do not sleep (i.e. the
> notify() callback) the mutex is about as fast to use as the spinlock.
It could work. I added such patch on an experimental branch, where
I'm addressing a few troubles with au0828 unbind logic:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=au0828-unbind-fixes
The patch itself is at:
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=au0828-unbind-fixes&id=dba4d41bdfa6bb8dc51cb0f692102919b2b7c8b4
At least for au0828, it seems to work fine.
Regards,
Mauro
Re: [PATCH v10 02/59] sparc/PCI: Use correct bus address to resource offset
On Sat, Mar 12, 2016 at 3:26 AM, Bjorn Helgaas wrote:
> On Sat, Mar 12, 2016 at 12:22:06AM -0800, Yinghai Lu wrote:
>> Good findings, that would break the sparc for a while.
>> (we should use res->start instead)
>
> We haven't even gotten to the part that your patch changes. If my
> analysis is correct, this call to iomem_is_exclusive() is already
> broken on sparc. I think we need the following patches:
Good for me. For your two patches
Acked-by: Yinghai Lu
>
> commit 4688b92991e43ab3b286d11e8f388b1b39d10b1b
> Author: Bjorn Helgaas
> Date: Sat Mar 12 04:27:39 2016 -0600
>
> PCI: Fix iomem_is_exclusive() checking in pci_mmap_resource()
>
> iomem_is_exclusive() requires a CPU physical address, but on some arches
> we
> supplied a PCI bus address instead.
>
> On most arches, pci_resource_to_user(res) returns "res->start", which is a
> CPU physical address. But on microblaze, mips, powerpc, and sparc, it
> returns the PCI bus address corresponding to "res->start".
>
> The result is that pci_mmap_resource() may fail when it shouldn't (if the
> bus address happens to match an existing resource), or it may succeed when
> it should fail (if the resource is exclusive but the bus address doesn't
> match it).
>
> Call iomem_is_exclusive() with "res->start", which is always a CPU
> physical
> address, not the result of pci_resource_to_user().
>
> Fixes: e8de1481fd71 ("resource: allow MMIO exclusivity for device
> drivers")
> Suggested-by: Yinghai Lu
> Signed-off-by: Bjorn Helgaas
> CC: Arjan van de Ven
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 95d9e7b..1559d67 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1004,6 +1004,9 @@ static int pci_mmap_resource(struct kobject *kobj,
> struct bin_attribute *attr,
> if (i >= PCI_ROM_RESOURCE)
> return -ENODEV;
>
> + if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
> + return -EINVAL;
> +
> if (!pci_mmap_fits(pdev, i, vma, PCI_MMAP_SYSFS)) {
> WARN(1, "process \"%s\" tried to map 0x%08lx bytes at page
> 0x%08lx on %s BAR %d (start 0x%16Lx, size 0x%16Lx)\n",
> current->comm, vma->vm_end-vma->vm_start,
> vma->vm_pgoff,
> @@ -1020,10 +1023,6 @@ static int pci_mmap_resource(struct kobject *kobj,
> struct bin_attribute *attr,
> pci_resource_to_user(pdev, i, res, &start, &end);
> vma->vm_pgoff += start >> PAGE_SHIFT;
> mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
> -
> - if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(start))
> - return -EINVAL;
> -
> return pci_mmap_page_range(pdev, vma, mmap_type, write_combine);
> }
>
> commit fd88769b8c4d840278137f9ca3968da5aa09c97f
> Author: Bjorn Helgaas
> Date: Sat Mar 12 05:10:11 2016 -0600
>
> alpha/PCI: Only check iomem_is_exclusive() for IORESOURCE_MEM, not
> IORESOURCE_IO
>
> The alpha pci_mmap_resource() is used for both IORESOURCE_MEM and
> IORESOURCE_IO resources, but iomem_is_exclusive() is only applicable for
> IORESOURCE_MEM.
>
> Call iomem_is_exclusive() only for IORESOURCE_MEM resources, and do it
> earlier to match the generic version of pci_mmap_resource().
>
> Fixes: 10a0ef39fbd1 ("PCI/alpha: pci sysfs resources")
> Signed-off-by: Bjorn Helgaas
> CC: Ivan Kokshaysky
>
> diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
> index 99e8d47..92c0d46 100644
> --- a/arch/alpha/kernel/pci-sysfs.c
> +++ b/arch/alpha/kernel/pci-sysfs.c
> @@ -77,10 +77,10 @@ static int pci_mmap_resource(struct kobject *kobj,
> if (i >= PCI_ROM_RESOURCE)
> return -ENODEV;
>
> - if (!__pci_mmap_fits(pdev, i, vma, sparse))
> + if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
> return -EINVAL;
>
> - if (iomem_is_exclusive(res->start))
> + if (!__pci_mmap_fits(pdev, i, vma, sparse))
> return -EINVAL;
>
> pcibios_resource_to_bus(pdev->bus, &bar, res);
Re: [PATCH v4 0/5] acpi, clocksource, kvm: add GTDT and ARM memory-mapped timer support
Hi Rafael, Great thanks for your feedback! On 18 March 2016 at 08:41, Rafael J. Wysocki wrote: > On Thursday, March 17, 2016 10:07:30 AM Timur Tabi wrote: >> fu@linaro.org wrote: >> > From: Fu Wei >> > >> > This patchset: >> > (1)Move some enums and marcos to header file for arm_arch_timer, >> > improve the pr_* code by defining "pr_fmt(fmt)" in arm_arch_timer.c >> > >> > (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c >> > Parse all kinds of timer in GTDT table of ACPI:arch timer, >> > memory-mapped timer and SBSA Generic Watchdog timer. >> > This driver can help to simplify all the relevant timer drivers, >> > and separate all the ACPI GTDT knowledge from them. >> > >> > (3)Simplify ACPI code for arch timer in arm_arch_timer.c >> > >> > (4)Add memory-mapped timer support in arm_arch_timer.c >> >> The SBSA watchdog driver is already in watchdog-next and will be merged >> into 4.6. These five patches are necessary for the watchdog driver to >> probe on an ACPI system. >> >> I'm guessing since that v4 was posted in the middle of the 4.6 merge >> window, that these patches won't make it and we'll have to wait until >> 4.7 (at the earliest)? > > First off, the last version I've seen is the v3. I must have overlooked > the v4 then, but I don't think it was CCed to linux-acpi (which should > have happened). Sorry for this, That is my fault. I updated the script of git-send-email for sending the v4 patchset, but lost a space between two "--cc". :-( > > Second, these patches require review from multiple maintainers and (or > including) > people who actually know how the GTDT is supposed to be used. I haven't > seen any responses from any of them yet, so the answer to your question is > "yes". > > I will have a couple of comments for patch [1/6] (in the v3), but it's > not been a priority due to the apparent overall lack of interest in this > series. Since this device is a generic watchdog for ARM server, it is(will be) used in a lot of chips. So I think many people are interested in it. They haven't provided any feedback, maybe due to my "--cc" mistake, or busy on something else now. :-( I would like to learn your comments for patch [1/6] , then improve my v4, post v5 ASAP. This patchset includes GTDT and memory-mapped timer patches, because my memory-mapped timer patches depends on GTDT. But maybe we can upstream GTDT separately? any suggestion? Thanks for your help! > > Thanks, > Rafael > -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021
Re: [PATCH v2 12/18] dt-bindings: Add PLX Technology OXNAS pinctrl and gpio bindings
On Wed, Mar 09, 2016 at 11:24:14AM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong
> ---
> .../devicetree/bindings/gpio/gpio_oxnas.txt| 27 ++
> .../bindings/pinctrl/plxtech,pinctrl.txt | 100
> +
> 2 files changed, 127 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> create mode 100644
> Documentation/devicetree/bindings/pinctrl/plxtech,pinctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> new file mode 100644
> index 000..cbb03c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> @@ -0,0 +1,27 @@
> +PLX Technology OXNAS SoC GPIO Controller
> +==
> +
> +Required properties:
> +- compatible: "oxsemi,ox810se-gpio".
> +- reg: Should contain GPIO controller registers location and length
> +- interrupts: Should be the port interrupt shared by all the pins.
> +- #gpio-cells: Should be two. The first cell is the pin number and
> + the second cell is used to specify optional parameters (currently
> + unused).
> +- gpio-controller: Marks the device node as a GPIO controller.
> +
> +optional properties:
> +- #gpio-lines: Number of gpio if absent 32.
> +
> +
> +Example:
> + gpio0: gpio@00 {
Drop the leading 0s.
> + compatible = "oxsemi,ox810se-gpio";
> + reg = <0x00 0x10>;
> + interrupts = <21>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + #gpio-lines = <32>;
> + };
> diff --git a/Documentation/devicetree/bindings/pinctrl/plxtech,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/plxtech,pinctrl.txt
> new file mode 100644
> index 000..0c5051a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/plxtech,pinctrl.txt
> @@ -0,0 +1,100 @@
> +PLX Technology OXNAS SoC Pinmux Controller
> +==
> +
> +The OXNAS Pinmux Controller, enables the IC to share one PAD to several
> +functional blocks. The sharing is done by multiplexing the PAD input/output
> +signals. For each PAD there are up to 8 muxing options (called periph modes).
> +Since different modules require different PAD settings
> +(like pull up, keeper, etc) the contoller controls also the PAD settings
> +parameters.
> +
> +Please refer to pinctrl-bindings.txt in this directory for details of the
> +common pinctrl bindings used by client devices, including the meaning of the
> +phrase "pin configuration node".
> +
> +OXNAS pin configuration node is a node of a group of pins which can be
> +used for a specific device or function. This node represents both mux and
> config
> +of the pins in that group. The 'pins' selects the function mode(also named
> pin
> +mode) this pin can work on and the 'config' configures various pad settings
> +such as pull-up, multi drive, etc.
> +
> +Required properties for iomux controller:
> +- compatible: "oxsemi,ox810se-pinctrl"
> +- plxtech,mux-mask: array of mask (periph per bank) to describe if a pin can
> be
> + configured in this periph mode. All the periph and bank need to be
> describe.
> +- plxtech,sys-ctrl: a phandle to the system controller syscon node
> +
> +How to create such array:
> +
> +Each column will represent the possible peripheral of the pinctrl
> +Each line will represent a pio bank
> +
> +For example :
> +Peripheral: 2 ( A and B)
> +Bank: 2 (A, B and C)
> +=>
> +
> + /*A B */
> + 0x 0xffc00c3b /* pioA */
> + 0x 0x7fff3ccf /* pioB */
> +
> +For each peripheral/bank we will descibe in a u32 if a pin can be
> +configured in it by putting 1 to the pin bit (1 << pin)
> +
> +Required properties for pin configuration node:
> +- plxtech,pins: 4 integers array, represents a group of pins mux and config
> + setting. The format is plxtech,pins = CONFIG>.
> + The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
> + PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
> +
> +Bits used for CONFIG:
> + - None Yet
> +
> +Examples:
> +
> +pinctrl: pinctrl {
> + compatible = "oxsemi,ox810se-pinctrl", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* Regmap for sys registers */
> + plxtech,sys-ctrl = <&sys>;
> +
> + /* Default, all-open mux-map */
> + plxtech,mux-mask = <
> + 0x 0x 0x 0x 0x
> + 0x 0x 0x 0x 0x
> + >;
> +
> + uart0 {
> + pinctrl_uart0: uart0 {
> + plxtech,pins = <0 31 3 0
> + 0 32 3 0>;
> + };
> + pinctrl_uart0_modem: uart0_modem {
> + plxtech,pins = <0 27 3 0
> +
Re: [RFC PATCH v4 5/7] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive
On 2016/3/17 0:30, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:36 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs.
But we should allow to mmap these sub-page MMIO BARs if PCI
resource allocator can make sure these BARs' mmio page will
not be shared with other BARs.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 1ce1d36..49d7a69 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -589,7 +589,8 @@ static long vfio_pci_ioctl(void *device_data,
VFIO_REGION_INFO_FLAG_WRITE;
if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) &&
pci_resource_flags(pdev, info.index) &
- IORESOURCE_MEM && info.size >= PAGE_SIZE) {
+ IORESOURCE_MEM && !pci_resources_share_page(pdev,
+ info.index)) {
this would be a preferable line wrap:
IORESOURCE_MEM &&
!pci_resources_share_page(pdev, info.index)) {
OK. I'll fix it.
Thanks,
Yongji Xie
Re: [PATCH v2 1/9] efi/x86: prepare GOP handling code for reuse as generic code
Hi Ard,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.5 next-20160318]
[cannot apply to efi/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Ard-Biesheuvel/EFI-framebuffer-support-for-ARM-and-arm64/20160319-005320
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
for-next/core
config: i386-randconfig-i1-201611 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: the
linux-review/Ard-Biesheuvel/EFI-framebuffer-support-for-ARM-and-arm64/20160319-005320
HEAD 26e82e0dc9f75ffe5b825ba3efbf659fbf1f138d builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from arch/x86/boot/compressed/eboot.c:10:0:
include/linux/efi.h:1296:7: warning: 'struct screen_info' declared inside
parameter list
unsigned long size);
^
include/linux/efi.h:1296:7: warning: its scope is only this definition or
declaration, which is probably not what you want
>> arch/x86/boot/compressed/eboot.c:861:14: error: conflicting types for
>> 'efi_setup_gop'
efi_status_t efi_setup_gop(efi_system_table_t *sys_table_arg,
^
In file included from arch/x86/boot/compressed/eboot.c:10:0:
include/linux/efi.h:1294:14: note: previous declaration of 'efi_setup_gop'
was here
efi_status_t efi_setup_gop(efi_system_table_t *sys_table_arg,
^
vim +/efi_setup_gop +861 arch/x86/boot/compressed/eboot.c
855 return status;
856 }
857
858 /*
859 * See if we have Graphics Output Protocol
860 */
> 861 efi_status_t efi_setup_gop(efi_system_table_t *sys_table_arg,
862 struct screen_info *si, efi_guid_t *proto,
863 unsigned long size)
864 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 6/8] cpufreq/schedutil: sum per-sched class utilization
On Wed, Mar 16, 2016 at 11:20:45AM -0700, Steve Muckle wrote:
> On 03/16/2016 12:38 AM, Peter Zijlstra wrote:
> > Somewhere in the giant discussions I mentioned that we should be looking
> > at a CPPC like interface and pass {min,max} tuples to the cpufreq
> > selection thingy.
> >
> > In that same discussion I also mentioned that we must compute min as the
> > hard dl reservation, but that for max we can actually use the avg dl +
> > avg rt + avg cfs.
> >
> > That way there is far more room for selecting a sensible frequency.
>
> Doesn't the above min/max policy mean that the platform will likely
> underserve the task load? If avg dl+rt+cfs represents our best estimate
> of the work to be done, I would think that should be the min.
Can't be the min, avg_dl might (and typically will be) must lower than
the worst case utilization estimates.
However if we use that as our min, peaks in DL utilization will not
complete, because we run at too low a frequency.
Therefore, the min must be given by our worst case utilization
reservation, not by the actual avg consumed.
RE: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist
>From: "David A. Long"
>
>Currrently taking exceptions when accessing user data from a kprobe'd
>instruction doesn't work. Avoid this situation by blacklisting the relevant
>functions.
>
>Signed-off-by: David A. Long
Looks good to me.
Reviewed-by: Masami Hiramatsu
Thanks,
>---
> arch/arm64/lib/copy_from_user.S | 1 +
> arch/arm64/lib/copy_to_user.S | 1 +
> 2 files changed, 2 insertions(+)
>
>diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
>index 4699cd7..0ac2131 100644
>--- a/arch/arm64/lib/copy_from_user.S
>+++ b/arch/arm64/lib/copy_from_user.S
>@@ -66,6 +66,7 @@
> .endm
>
> end .reqx5
>+ .section .kprobes.text,"ax",%progbits
> ENTRY(__copy_from_user)
> ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
>diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
>index 7512bbb..e4eb84c 100644
>--- a/arch/arm64/lib/copy_to_user.S
>+++ b/arch/arm64/lib/copy_to_user.S
>@@ -65,6 +65,7 @@
> .endm
>
> end .reqx5
>+ .section .kprobes.text,"ax",%progbits
> ENTRY(__copy_to_user)
> ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
>--
>2.5.0
>
>
>___
>linux-arm-kernel mailing list
>linux-arm-ker...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v7 2/4] gadget: Support for the usb charger framework
Hi Baolin, [auto build test ERROR on v4.5-rc7] [also build test ERROR on next-20160316] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20160316-195102 config: x86_64-allmodconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> ERROR: "usb_charger_init" [drivers/usb/gadget/udc/udc-core.ko] undefined! >> ERROR: "usb_charger_plug_by_gadget" [drivers/usb/gadget/udc/udc-core.ko] >> undefined! >> ERROR: "usb_charger_exit" [drivers/usb/gadget/udc/udc-core.ko] undefined! >> ERROR: "usb_charger_set_cur_limit_by_type" >> [drivers/usb/gadget/libcomposite.ko] undefined! >> ERROR: "usb_charger_detect_type" [drivers/usb/gadget/libcomposite.ko] >> undefined! >> ERROR: "usb_charger_set_cur_limit_by_type" >> [drivers/usb/gadget/legacy/gadgetfs.ko] undefined! >> ERROR: "usb_charger_detect_type" [drivers/usb/gadget/legacy/gadgetfs.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[git pull] m68knommu/coldfire fixes for 4.6
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. The main change is the removal of the bit-rotten 68360 support. Also a fix to always make the ethernet FEC platform info available. Regards Greg The following changes since commit f6cede5b49e822ebc41a099fe41ab4989f64e2cb: Linux 4.5-rc7 (2016-03-06 14:48:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to a3595962d82495f51a80feb19dcdb135556a9527: m68knommu: remove obsolete 68360 support (2016-03-07 10:07:17 +1000) Greg Ungerer (2): m68knommu: fix FEC platform device registration when driver is modular m68knommu: remove obsolete 68360 support arch/m68k/68360/Makefile | 12 - arch/m68k/68360/commproc.c | 309 arch/m68k/68360/config.c | 169 - arch/m68k/68360/entry.S | 164 - arch/m68k/68360/head-ram.S | 402 - arch/m68k/68360/head-rom.S | 413 -- arch/m68k/68360/ints.c | 138 arch/m68k/Kconfig.cpu| 7 - arch/m68k/Kconfig.debug | 2 +- arch/m68k/Kconfig.machine| 6 - arch/m68k/Makefile | 3 - arch/m68k/coldfire/device.c | 4 +- arch/m68k/include/asm/commproc.h | 664 --- arch/m68k/include/asm/m68360.h | 13 - arch/m68k/include/asm/m68360_enet.h | 177 -- arch/m68k/include/asm/m68360_pram.h | 431 --- arch/m68k/include/asm/m68360_quicc.h | 362 --- arch/m68k/include/asm/m68360_regs.h | 408 - arch/m68k/kernel/early_printk.c | 8 +- arch/m68k/kernel/setup_no.c | 7 - 20 files changed, 7 insertions(+), 3692 deletions(-) delete mode 100644 arch/m68k/68360/Makefile delete mode 100644 arch/m68k/68360/commproc.c delete mode 100644 arch/m68k/68360/config.c delete mode 100644 arch/m68k/68360/entry.S delete mode 100644 arch/m68k/68360/head-ram.S delete mode 100644 arch/m68k/68360/head-rom.S delete mode 100644 arch/m68k/68360/ints.c delete mode 100644 arch/m68k/include/asm/commproc.h delete mode 100644 arch/m68k/include/asm/m68360.h delete mode 100644 arch/m68k/include/asm/m68360_enet.h delete mode 100644 arch/m68k/include/asm/m68360_pram.h delete mode 100644 arch/m68k/include/asm/m68360_quicc.h delete mode 100644 arch/m68k/include/asm/m68360_regs.h
[PATCH] lib/spinlock_debug: Prevent a unnecessary recursive spin_dump()
This can protect an infinit recursion by unnecessary warning, too.
-8<-
>From 81f06a6f9c7f2e782267a2539c6c869d4214354c Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Fri, 18 Mar 2016 11:35:24 +0900
Subject: [PATCH] lib/spinlock_debug: Prevent a unnecessary recursive
spin_dump()
Printing "lockup suspected" for the same lock more than once is
meaningless. Furtheremore, it can cause an infinite recursion if it's
on the way printing something by printk().
Signed-off-by: Byungchul Park
---
kernel/locking/spinlock_debug.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/spinlock_debug.c b/kernel/locking/spinlock_debug.c
index fd24588..30559c6 100644
--- a/kernel/locking/spinlock_debug.c
+++ b/kernel/locking/spinlock_debug.c
@@ -138,14 +138,25 @@ static void __spin_lock_debug(raw_spinlock_t *lock)
{
u64 i;
u64 loops = loops_per_jiffy * HZ;
+ static raw_spinlock_t *suspected_lock = NULL;
for (i = 0; i < loops; i++) {
if (arch_spin_trylock(&lock->raw_lock))
return;
__delay(1);
}
- /* lockup suspected: */
- spin_dump(lock, "lockup suspected");
+
+ /*
+* When we suspect a lockup, it's good enough to inform it once for
+* the same lock. Otherwise it could cause an infinite recursion if
+* it's within printk().
+*/
+ if (suspected_lock != lock) {
+ suspected_lock = lock;
+ /* lockup suspected: */
+ spin_dump(lock, "lockup suspected");
+ suspected_lock = NULL;
+ }
#ifdef CONFIG_SMP
trigger_all_cpu_backtrace();
#endif
--
1.9.1
Re: [PATCH] drm/sti: restore mode_fixup callback
Thank you Arnd for highlighting this.
Acked-by: Vincent ABRIOU
On 03/17/2016 10:02 AM, Arnd Bergmann wrote:
> Commit 8a2fa38fddd3 removed the mode_fixup because it was empty,
> but 652353e6e561 modified it to call drm_mode_set_crtcinfo()
> instead.
>
> Both commits are correct, but the merge of the two kept the nonempty
> version without the reference to it, as shown by the gcc warning:
>
> drm/sti/sti_crtc.c:54:13: error: 'sti_crtc_mode_fixup' defined but not used
>
> This restores the callback pointer to fix the merge.
>
> Signed-off-by: Arnd Bergmann
> Reverts: 8a2fa38fddd3 ("drm/sti: removed optional dummy crtc mode_fixup
> function.")
> Fixes: 652353e6e561 ("drm/sti: set CRTC modesetting parameters")
> Fixes: cf481068cdd4 ("Merge branch '2016-02-26-st-drm-next' of
> http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next")
> ---
> drivers/gpu/drm/sti/sti_crtc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index fa47f63b5316..505620c7c2c8 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -230,6 +230,7 @@ static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
> static const struct drm_crtc_helper_funcs sti_crtc_helper_funcs = {
> .enable = sti_crtc_enable,
> .disable = sti_crtc_disabling,
> + .mode_fixup = sti_crtc_mode_fixup,
> .mode_set = drm_helper_crtc_mode_set,
> .mode_set_nofb = sti_crtc_mode_set_nofb,
> .mode_set_base = drm_helper_crtc_mode_set_base,
>
[PATCH 1/2] irqdomain: Export irq_domain_free_irqs_common
Export irq_domain_free_irqs_common so it can be used by modules. Signed-off-by: Axel Lin --- kernel/irq/irqdomain.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index 3a519a0..245a485 100644 --- a/kernel/irq/irqdomain.c +++ b/kernel/irq/irqdomain.c @@ -1099,6 +1099,7 @@ void irq_domain_free_irqs_common(struct irq_domain *domain, unsigned int virq, } irq_domain_free_irqs_parent(domain, virq, nr_irqs); } +EXPORT_SYMBOL_GPL(irq_domain_free_irqs_common); /** * irq_domain_free_irqs_top - Clear handler and handler data, clear irqdata and free parent -- 2.1.4
[PATCH] clk: sunxi: Add CSI (camera's Sensors Interface) module clock driver for sun[457]i
From: Yassin Jaffer
This patch adds a composite clock type consisting of
a clock gate, mux, configurable dividers, and a reset control.
Signed-off-by: Yassin Jaffer
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/Makefile| 1 +
drivers/clk/sunxi/clk-a10-csi.c | 188 ++
3 files changed, 190 insertions(+)
create mode 100644 drivers/clk/sunxi/clk-a10-csi.c
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index e59f57b..c3826f7 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -77,6 +77,7 @@ Required properties:
"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
+ "allwinner,sun4i-a10-csi-clk" - for the CSI module
Required properties for all clocks:
- reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3fd7901..42ce752 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -7,6 +7,7 @@ obj-y += clk-a10-codec.o
obj-y += clk-a10-hosc.o
obj-y += clk-a10-mod1.o
obj-y += clk-a10-pll2.o
+obj-y += clk-a10-csi.o
obj-y += clk-a10-ve.o
obj-y += clk-a20-gmac.o
obj-y += clk-mod0.o
diff --git a/drivers/clk/sunxi/clk-a10-csi.c b/drivers/clk/sunxi/clk-a10-csi.c
new file mode 100644
index 000..f17d206
--- /dev/null
+++ b/drivers/clk/sunxi/clk-a10-csi.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright 2016 Yassin Jaffer
+ *
+ * Yassin Jaffer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static DEFINE_SPINLOCK(sun4i_csi_lock);
+
+#define SUN4I_CSI_PARENTS 5
+#define SUN4I_CSI_GATE_BIT 31
+#define SUN4I_CSI_RESET_BIT 30
+#define SUN4I_CSI_MUX_SHIFT 24
+#define SUN4I_CSI_DIV_WIDTH 5
+#define SUN4I_CSI_DIV_SHIFT 0
+
+static u32 sun4i_csi_mux_table[SUN4I_CSI_PARENTS] = {
+ 0x0,
+ 0x1,
+ 0x2,
+ 0x5,
+ 0x6,
+};
+
+struct csi_reset_data {
+ void __iomem*reg;
+ spinlock_t *lock; /* lock for reset handling */
+ struct reset_controller_dev rcdev;
+};
+
+static int sun4i_csi_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct csi_reset_data *data = container_of(rcdev,
+ struct csi_reset_data,
+ rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg & ~BIT(SUN4I_CSI_RESET_BIT), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static int sun4i_csi_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct csi_reset_data *data = container_of(rcdev,
+ struct csi_reset_data,
+ rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg | BIT(SUN4I_CSI_RESET_BIT), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static int sun4i_csi_of_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ if (WARN_ON(reset_spec->args_count != 0))
+ return -EINVAL;
+
+ return 0;
+}
+
+static struct reset_control_ops sun4i_csi_reset_ops = {
+ .assert = sun4i_csi_assert,
+ .deassert = sun4i_csi_deassert,
+};
+
+static void __init sun4i_csi_clk_setup(struct device_node *node)
+{
+ const char *parents[SUN4I_CSI_PARENTS];
+ const char *clk_name = node->name;
+ struct csi_reset_data *reset_data;
+ struct clk_divider *div;
+ struct clk_gate *gate;
+ struct clk_mux *mux;
+ void __iomem *reg;
+ struct clk *clk;
+ int i = 0;
+
+ reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+ if (IS_ERR(reg))
+ return;
+
+ of_property_read_string(node, "c
Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods
On Thu, Mar 17, 2016 at 08:36:00PM +0100, Peter Zijlstra wrote: > On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote: > > Currently you can only request a backtrace of either all cpus, or > > all cpus but yourself. It can also be helpful to request a remote > > backtrace of a single cpu, and since we want that, the logical > > extension is to support a cpumask as the underlying primitive. > > > > This change modifies the existing lib/nmi_backtrace.c code to take > > a cpumask as its basic primitive, and modifies the linux/nmi.h code > > to use either the old "all/all_but_self" arch methods, or the new > > "cpumask" method, depending on which is available. > > > > The existing clients of nmi_backtrace (arm and x86) are converted > > to using the new cpumask approach in this change. > > So the past days I've been staring at RCU stall warns, and they can use > a little of this. Their remote stack unwinds are less than useful. The RCU stall-warn stack traces can be ugly, agreed. That said, RCU used to use NMI-based stack traces, but switched to the current scheme due to the NMIs having the unfortunate habit of locking things up, which IIRC often meant no stack traces at all. If I recall correctly, one of the problems was self-deadlock in printk(). Have these problems been fixed? Thanx, Paul
Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single
On 3/18/2016 10:20 AM, Boris Brezillon wrote:
> On Fri, 18 Mar 2016 09:51:37 -0400
> Sinan Kaya wrote:
>
>> On 3/18/2016 7:25 AM, Robin Murphy wrote:
>>> On 18/03/16 09:30, Boris Brezillon wrote:
On Thu, 17 Mar 2016 23:50:20 +
Russell King - ARM Linux wrote:
> On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
>> What is the correct way? I don't want to write engine->sram_dma = sram
>
> Well, what the driver _is_ wanting to do is to go from a CPU physical
> address to a device DMA address. phys_to_dma() looks like the correct
> thing there to me, but I guess that's just an offset and doesn't take
> account of any IOMMU that may be in the way.
>
> If you have an IOMMU, then the whole phys_to_dma() thing is a total
> failure as it only does a linear translation, and there are no
> interfaces in the kernel to take account of an IOMMU in the way. So,
> it needs something designed for the job, implemented and discussed by
> the normal methods of proposing a new cross-arch interface for drivers
> to use.
>
> What I'm certain of, though, is that the change proposed in this patch
> will break current users of this driver: virt_to_page() on an address
> returned by ioremap() is completely undefined, and will result in
> either a kernel oops, or if not poking at memory which isn't a struct
> page, ultimately resulting in something that isn't SRAM being pointed
> to by "engine->sram_dma".
>
Or we could just do
engine->sram_dma = res->start;
which is pretty much what the SRAM/genalloc code is doing already.
>>>
>>> As Russell points out this is yet another type of "set up a DMA master to
>>> access something other than kernel RAM" - there's already discussion in
>>> progress over how to handle this for dmaengine slaves[1], so gathering more
>>> use-cases might help distil exactly what the design of
>>> not-strictly-DMA-but-so-closely-coupled-it-can't-really-live-anywhere-else
>>> needs to be.
>>>
>>> Robin.
>>>
>>> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414422.html
>>>
>>
>> Thanks for the link.
>>
>> dma_map_resource looks like to be the correct way of doing things. Just from
>> the purist point of view, a driver is not supposed to know the physical
>> address
>> of a DMA address. That kills the intent of using DMA API. When programming
>> descriptors,
>> the DMA addresses should be programmed not physical addresses so that the
>> same
>> driver can be used in a system with IOMMU. The IOMMU DMA ops will remap the
>> DMA
>> address to a bus address that is not physical address. All of this operation
>> needs
>> to be isolated from the device driver.
>>
>>
>> I don't know the architecture or the driver enough to write this. This is
>> not ideally
>> right but I can do this if Boris you are OK with this.
>>
>> engine->sram_dma = res->start;
>
> I don't know.
>
> How about waiting for the 'dma_{map,unmap}_resource' discussion to
> settle down before removing phy_to_dma()/dma_to_phys() APIs (as
> suggested by Robin and Russell)?
>
>
Sure, that's fine for me.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
[PATCH v4 01/14] i2c-octeon: Cleanup i2c-octeon driver
Cleanup only without functional change.
- removed DRV_VERSION
- defines: use defines instead of plain values,
use BIT_ULL macro, add comments
- rename waitqueue return value to time_left
- sort local variables by length
- fix indentation and whitespace errors
- make function return void if the result is not used
(octeon_i2c_stop, octeon_i2c_set_clock)
- remove debug code from octeon_i2c_stop
- renamed some functions for readability
- update copyright
Signed-off-by: Jan Glauber
---
drivers/i2c/busses/i2c-octeon.c | 190 ++--
1 file changed, 84 insertions(+), 106 deletions(-)
diff --git a/drivers/i2c/busses/i2c-octeon.c b/drivers/i2c/busses/i2c-octeon.c
index 4a08418..9787379 100644
--- a/drivers/i2c/busses/i2c-octeon.c
+++ b/drivers/i2c/busses/i2c-octeon.c
@@ -2,7 +2,7 @@
* (C) Copyright 2009-2010
* Nokia Siemens Networks, michael.lawnick@nsn.com
*
- * Portions Copyright (C) 2010, 2011 Cavium Networks, Inc.
+ * Portions Copyright (C) 2010 - 2016 Cavium, Inc.
*
* This is a driver for the i2c adapter in Cavium Networks' OCTEON processors.
*
@@ -26,39 +26,48 @@
#define DRV_NAME "i2c-octeon"
-/* The previous out-of-tree version was implicitly version 1.0. */
-#define DRV_VERSION"2.0"
-
-/* register offsets */
-#define SW_TWSI 0x00
-#define TWSI_INT 0x10
+/* Register offsets */
+#define SW_TWSI0x00
+#define TWSI_INT 0x10
/* Controller command patterns */
-#define SW_TWSI_V 0x8000ull
-#define SW_TWSI_EOP_TWSI_DATA 0x0C01ull
-#define SW_TWSI_EOP_TWSI_CTL0x0C02ull
-#define SW_TWSI_EOP_TWSI_CLKCTL 0x0C03ull
-#define SW_TWSI_EOP_TWSI_STAT 0x0C03ull
-#define SW_TWSI_EOP_TWSI_RST0x0C07ull
-#define SW_TWSI_OP_TWSI_CLK 0x0800ull
-#define SW_TWSI_R 0x0100ull
+#define SW_TWSI_V BIT_ULL(63) /* Valid bit */
+#define SW_TWSI_R BIT_ULL(56) /* Result or read bit */
+
+/* Controller opcode word (bits 60:57) */
+#define SW_TWSI_OP_SHIFT 57
+#define SW_TWSI_OP_TWSI_CLK(4ULL << SW_TWSI_OP_SHIFT)
+#define SW_TWSI_OP_EOP (6ULL << SW_TWSI_OP_SHIFT) /* Extended opcode */
+
+/* Controller extended opcode word (bits 34:32) */
+#define SW_TWSI_EOP_SHIFT 32
+#define SW_TWSI_EOP_TWSI_DATA (SW_TWSI_OP_EOP | 1ULL << SW_TWSI_EOP_SHIFT)
+#define SW_TWSI_EOP_TWSI_CTL (SW_TWSI_OP_EOP | 2ULL << SW_TWSI_EOP_SHIFT)
+#define SW_TWSI_EOP_TWSI_CLKCTL(SW_TWSI_OP_EOP | 3ULL <<
SW_TWSI_EOP_SHIFT)
+#define SW_TWSI_EOP_TWSI_STAT (SW_TWSI_OP_EOP | 3ULL << SW_TWSI_EOP_SHIFT)
+#define SW_TWSI_EOP_TWSI_RST (SW_TWSI_OP_EOP | 7ULL << SW_TWSI_EOP_SHIFT)
/* Controller command and status bits */
-#define TWSI_CTL_CE 0x80
-#define TWSI_CTL_ENAB 0x40
-#define TWSI_CTL_STA 0x20
-#define TWSI_CTL_STP 0x10
-#define TWSI_CTL_IFLG 0x08
-#define TWSI_CTL_AAK 0x04
+#define TWSI_CTL_CE0x80
+#define TWSI_CTL_ENAB 0x40/* Bus enable */
+#define TWSI_CTL_STA 0x20/* Master-mode start, HW clears when
done */
+#define TWSI_CTL_STP 0x10/* Master-mode stop, HW clears when
done */
+#define TWSI_CTL_IFLG 0x08/* HW event, SW writes 0 to ACK */
+#define TWSI_CTL_AAK 0x04/* Assert ACK */
/* Some status values */
-#define STAT_START 0x08
-#define STAT_RSTART 0x10
-#define STAT_TXADDR_ACK 0x18
-#define STAT_TXDATA_ACK 0x28
-#define STAT_RXADDR_ACK 0x40
-#define STAT_RXDATA_ACK 0x50
-#define STAT_IDLE 0xF8
+#define STAT_START 0x08
+#define STAT_RSTART0x10
+#define STAT_TXADDR_ACK0x18
+#define STAT_TXDATA_ACK0x28
+#define STAT_RXADDR_ACK0x40
+#define STAT_RXDATA_ACK0x50
+#define STAT_IDLE 0xF8
+
+/* TWSI_INT values */
+#define TWSI_INT_CORE_EN BIT_ULL(6)
+#define TWSI_INT_SDA_OVR BIT_ULL(8)
+#define TWSI_INT_SCL_OVR BIT_ULL(9)
struct octeon_i2c {
wait_queue_head_t queue;
@@ -80,9 +89,7 @@ struct octeon_i2c {
*
* The I2C core registers are accessed indirectly via the SW_TWSI CSR.
*/
-static void octeon_i2c_write_sw(struct octeon_i2c *i2c,
- u64 eop_reg,
- u8 data)
+static void octeon_i2c_write_sw(struct octeon_i2c *i2c, u64 eop_reg, u8 data)
{
u64 tmp;
@@ -93,7 +100,7 @@ static void octeon_i2c_write_sw(struct octeon_i2c *i2c,
}
/**
- * octeon_i2c_read_sw - write an I2C core register
+ * octeon_i2c_read_sw - read lower bits of an I2C core register
* @i2c: The struct octeon_i2c
* @eop_reg: Register selector
*
@@ -133,12 +140,13 @@ static void octeon_i2c_write_int(struct octeon_i2c *i2c,
u64 data)
*/
static void octeon_i2c_int_enable(struct octeon_i2c *i2c)
{
- octeon_i2c_write_int(i2c, 0x40);
+ octeon_i2c_write_int(i2c, TWSI_INT_CORE_EN
Re: [RFC v2 -next 1/2] virtio: Start feature MTU support
On Thu, 17 Mar 2016 17:10:55 -0400
Aaron Conole wrote:
> Stephen Hemminger writes:
>
> > On Tue, 15 Mar 2016 17:04:12 -0400
> > Aaron Conole wrote:
> >
> >> --- a/include/uapi/linux/virtio_net.h
> >> +++ b/include/uapi/linux/virtio_net.h
> >> @@ -55,6 +55,7 @@
> >> #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
> >> * Steering */
> >> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> >> +#define VIRTIO_NET_F_MTU 25 /* Device supports Default MTU
> >> Negotiation */
> >>
> >> #ifndef VIRTIO_NET_NO_LEGACY
> >> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> >> @@ -73,6 +74,8 @@ struct virtio_net_config {
> >> * Legal values are between 1 and 0x8000
> >> */
> >>__u16 max_virtqueue_pairs;
> >> + /* Default maximum transmit unit advice */
> >> + __u16 mtu;
> >> } __attribute__((packed));
> >>
> >> /*
> >
> > You can't change user visible headers without breaking ABI.
> > This structure might be used by other user code. Also how can this
> > work if host is using old size of structure.
>
> How else can this field be added and remain compliant with the spec? The
> spec requires that mtu be passed in the virtio_net_config field.
>
> As for old sizeof, I think the absence of the VIRTIO_NET_F_MTU bit being
> asserted is confirmation that mtu is not valid (at least, it is implied
> in the spec).
Michael is right as long as the code checks for MTU flag before
referencing the mtu field, everything is fine. Actually, the structure
is never used directly only by fetching fields with offsetof
Re: [PATCH v5 1/5] ARM: at91: pm: create a separate procedure for the ULP0 mode
On 16/03/2016 at 14:58:05 +0800, Wenyou Yang wrote : > To make the code more legible and prepare to add the ULP1 mode > support in the future, create a separate procedure for the ULP0 mode. > > Signed-off-by: Wenyou Yang Acked-by: Alexandre Belloni > --- > > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: None > > arch/arm/mach-at91/pm_suspend.S | 65 > --- > 1 file changed, 40 insertions(+), 25 deletions(-) > > diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S > index a25defd..5fcffdc 100644 > --- a/arch/arm/mach-at91/pm_suspend.S > +++ b/arch/arm/mach-at91/pm_suspend.S > @@ -107,7 +107,7 @@ ENTRY(at91_pm_suspend_in_sram) > > ldr r0, .pm_mode > tst r0, #AT91_PM_SLOW_CLOCK > - beq skip_disable_main_clock > + beq standby_mode > > ldr pmc, .pmc_base > > @@ -131,32 +131,13 @@ ENTRY(at91_pm_suspend_in_sram) > orr tmp1, tmp1, #(1 << 29) /* bit 29 always set */ > str tmp1, [pmc, #AT91_CKGR_PLLAR] > > - /* Turn off the main oscillator */ > - ldr tmp1, [pmc, #AT91_CKGR_MOR] > - bic tmp1, tmp1, #AT91_PMC_MOSCEN > - orr tmp1, tmp1, #AT91_PMC_KEY > - str tmp1, [pmc, #AT91_CKGR_MOR] > - > -skip_disable_main_clock: > - ldr pmc, .pmc_base > - > - /* Wait for interrupt */ > - at91_cpu_idle > - > - ldr r0, .pm_mode > - tst r0, #AT91_PM_SLOW_CLOCK > - beq skip_enable_main_clock > +ulp0_mode: > + bl at91_pm_ulp0_mode > + b ulp_exit > > +ulp_exit: > ldr pmc, .pmc_base > > - /* Turn on the main oscillator */ > - ldr tmp1, [pmc, #AT91_CKGR_MOR] > - orr tmp1, tmp1, #AT91_PMC_MOSCEN > - orr tmp1, tmp1, #AT91_PMC_KEY > - str tmp1, [pmc, #AT91_CKGR_MOR] > - > - wait_moscrdy > - > /* Restore PLLA setting */ > ldr tmp1, .saved_pllar > str tmp1, [pmc, #AT91_CKGR_PLLAR] > @@ -177,7 +158,15 @@ skip_disable_main_clock: > > wait_mckrdy > > -skip_enable_main_clock: > + b pm_exit > + > +standby_mode: > + ldr pmc, .pmc_base > + > + /* Wait for interrupt */ > + at91_cpu_idle > + > +pm_exit: > /* Exit the self-refresh mode */ > mov r0, #SRAMC_SELF_FRESH_EXIT > bl at91_sramc_self_refresh > @@ -311,6 +300,32 @@ exit_sramc_sf: > mov pc, lr > ENDPROC(at91_sramc_self_refresh) > > +/* > + * void at91_pm_ulp0_mode(void) > + */ > +ENTRY(at91_pm_ulp0_mode) > + ldr pmc, .pmc_base > + > + /* Turn off the crystal oscillator */ > + ldr tmp1, [pmc, #AT91_CKGR_MOR] > + bic tmp1, tmp1, #AT91_PMC_MOSCEN > + orr tmp1, tmp1, #AT91_PMC_KEY > + str tmp1, [pmc, #AT91_CKGR_MOR] > + > + /* Wait for interrupt */ > + at91_cpu_idle > + > + /* Turn on the crystal oscillator */ > + ldr tmp1, [pmc, #AT91_CKGR_MOR] > + orr tmp1, tmp1, #AT91_PMC_MOSCEN > + orr tmp1, tmp1, #AT91_PMC_KEY > + str tmp1, [pmc, #AT91_CKGR_MOR] > + > + wait_moscrdy > + > + mov pc, lr > +ENDPROC(at91_pm_ulp0_mode) > + > .pmc_base: > .word 0 > .sramc_base: > -- > 1.7.9.5 > -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Re: [PATCH 1/2] of: add vendor prefix for Holtek Semiconductor
On Wed, Mar 16, 2016 at 04:52:08PM +0100, Robin van der Gracht wrote: > This patch introduces a vendor prefix for Holtek Semiconductor Inc. > > Signed-off-by: Robin van der Gracht > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index dd72e05..fa70359d 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -108,6 +108,7 @@ hitex Hitex Development Tools > holt Holt Integrated Circuits, Inc. > honeywellHoneywell > hp Hewlett Packard > +ht Holtek Semiconductor Inc. I think holtek being a bit longer would be better here. > i2se I2SE GmbH > ibm International Business Machines (IBM) > idt Integrated Device Technologies, Inc. > -- > 2.5.0 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()
On Wed, Mar 16, 2016 at 5:47 AM, Viresh Kumar wrote: > On 15-03-16, 13:11, Rafael J. Wysocki wrote: >> On Tue, Mar 15, 2016 at 7:10 AM, Viresh Kumar >> wrote: >> > On 12-03-16, 03:05, Rafael J. Wysocki wrote: >> >> From: Rafael J. Wysocki >> >> >> >> cpufreq_resume() attempts to resync the current frequency with >> >> policy->cur for the first online CPU, but first it does that after >> >> restarting governors for all active policies (which means that this >> >> is racy with respect to whatever the governors do) and second it >> > >> > Why? Its doing the update withing policy->rwsem .. >> >> Which doesn't matter. >> >> dbs_work_handler() doesn't acquire policy->rwsem and may be executed >> in parallel with this, for example. > > Right, so we need to fixup something here. > >> >> already is too late for that when cpufreq_resume() is called (that >> >> happens after invoking ->resume callbacks for all devices in the >> >> system). >> >> >> >> Also it doesn't make sense to do that for one CPU only in any case, >> >> because the other CPUs in the system need not share the policy with >> >> it and their policy->cur may be out of sync as well in principle. >> > >> > Its done just for the boot CPU, because that's the only CPU that goes to >> > suspend. All other CPUs are disabled/enabled and so the policies are >> > reinitialized for policy->cur as well. >> > >> > I think, its still important to get things in sync, as some bootloader may >> > change the frequency to something else during resume. >> > >> > And our code may not be safe for the case, the current frequency of the CPU >> > isn't part of the freq-table of the policy. >> >> Since we're already started the governor at this point (or called the >> driver's ->resume), so the CPU is (or shortly will be) running at a >> frequency that makes sense at this point. >> >> It might be running at a wrong one before, but not when this code is >> executed. > > Not necessarily. > > Consider Performance governor for example. Lets say policy->max is 1 GHz, so > before suspend policy->cur will be 1 GHz. We suspended and resumed, and the > bootloader changed the frequency to 500 MHz (but policy->cur remains the same > at > 1 GHz). Even after calling START for the governor, it will continue to run at > 500 MHz. No, it won't. This might be applicable to other governors, but not to "performance" (look at what it does on _START instead of just guessing). > So, your patch break things for sure. I'm not actually sure it breaks anything. Theoretically, it may, but practically? Is there any system out there where it makes any difference?
Re: [PATCH] MAINTAINERS: Add the stlinux kernel mailing list for the STi drm driver.
On 03/17/2016 04:07 PM, Peter Griffin wrote: Hi Lee, On Thu, 17 Mar 2016, Lee Jones wrote: On Thu, 17 Mar 2016, Peter Griffin wrote: Most drivers for STi are under the ARM/STI Architecture section which includes this mailing list. Signed-off-by: Peter Griffin --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6ee06ea..c541a89 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3814,6 +3814,7 @@ DRM DRIVERS FOR STI M:Benjamin Gaignard M:Vincent Abriou L:dri-de...@lists.freedesktop.org +L: ker...@stlinux.com T:git http://git.linaro.org/people/benjamin.gaignard/kernel.git S:Maintained F:drivers/gpu/drm/sti Doesn't it make more sense to add drivers/gpu/drm/sti/ to the ARM/STI ARCHITECTURE list of supported files? I assumed Vincent and Benjamin deliberately added a new entry because they want to be maintainers of this driver (which I think probably makes sense given that the display IP is quite complicated). I agree with Peter, let's just add kernel@stlinux entry in the DRM STi entry. Acked-by: Maxime Coquelin Regards, Maxime
Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util
On Wed, Mar 16, 2016 at 02:23:21PM +0100, Rafael J. Wysocki wrote:
> On Wed, Mar 16, 2016 at 2:10 PM, Peter Zijlstra wrote:
> > (this would of course require we allocate struct update_util_data with
> > the proper alignment thingies etc..)
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index ba49c9efd0b2..d34d75c5cc93 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -3236,8 +3236,10 @@ static inline unsigned long rlimit_max(unsigned int
> > limit)
> >
> > #ifdef CONFIG_CPU_FREQ
> > struct update_util_data {
> > - void (*func)(struct update_util_data *data,
> > -u64 time, unsigned long util, unsigned long max);
> > + unsigned long *cfs_util_avg;
> > + unsigned long *cfs_util_max;
> > +
> > + void (*func)(struct update_util_data *data, u64 time);
> > };
we should add: cacheline_aligned here
> How do we ensure proper alignment?
Depends on the allocator; not all of them respect the struct alignment
attribute.
kernel/sched/cpufreq.c:DEFINE_PER_CPU(struct update_util_data *,
cpufreq_update_util_data);
That one could use:
DEFINE_PER_CPU_ALIGNED() instead
as would this one:
drivers/cpufreq/cpufreq_governor.c:static DEFINE_PER_CPU(struct cpu_dbs_info,
cpu_dbs);
Because when you cacheline align dbs_info, its update_util_data member
will also get the correct alignment because of the structure attribute.
Re: [PATCH 3/3] dma-mapping: move swiotlb dma-phys functions to common header
On 17/03/16 22:02, Sinan Kaya wrote:
Moving the default implementation of swiotlb_dma_to_phys and
swiotlb_phys_to_dma functions to dma-mapping.h so that we can get
rid of the duplicate code in multiple ARCH.
Signed-off-by: Sinan Kaya
---
arch/arm64/include/asm/dma-mapping.h | 14 --
arch/ia64/include/asm/dma-mapping.h| 14 --
arch/mips/include/asm/mach-generic/dma-coherence.h | 16
arch/tile/include/asm/dma-mapping.h| 14 --
arch/unicore32/include/asm/dma-mapping.h | 14 --
arch/x86/include/asm/dma-mapping.h | 13 -
arch/xtensa/include/asm/dma-mapping.h | 14 --
include/linux/dma-mapping.h| 14 ++
8 files changed, 14 insertions(+), 99 deletions(-)
[...]
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 728ef07..871d620 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -683,4 +683,18 @@ static inline int dma_mmap_writecombine(struct device *dev,
#define dma_unmap_len_set(PTR, LEN_NAME, VAL)do { } while (0)
#endif
+#ifndef swiotlb_phys_to_dma
+static inline dma_addr_t swiotlb_phys_to_dma(struct device *dev, phys_addr_t
paddr)
+{
+ return paddr;
+}
+#endif
+
+#ifndef swiotlb_dma_to_phys
+static inline phys_addr_t swiotlb_dma_to_phys(struct device *dev, dma_addr_t
daddr)
+{
+return daddr;
+}
+#endif
+
#endif
Could the default definition not be pushed all the way down into
swiotlb.c (or at least swiotlb.h)?
Robin.
Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature
Rick Jones writes: > On 03/15/2016 02:04 PM, Aaron Conole wrote: >> The following series adds the ability for a hypervisor to set an MTU on the >> guest during feature negotiation phase. This is useful for VM orchestration >> when, for instance, tunneling is involved and the MTU of the various systems >> should be homogenous. >> >> The first patch adds the feature bit as described in the proposed VFIO spec >> addition found at >> https://lists.oasis-open.org/archives/virtio-dev/201603/msg1.html >> >> The second patch adds a user of the bit, and a warning when the guest changes >> the MTU from the hypervisor advised MTU. Future patches may add more thorough >> error handling. > > How do you see this interacting with VMs getting MTU settings via DHCP? This is intended for networks where the VMs are not given MTU via DHCP. I don't think it should negatively interfere with such a network. Does that make sense? -Aaron > rick jones > >> >> v2: >> * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni >> * Additional test before printing a warning >> >> Aaron Conole (2): >>virtio: Start feature MTU support >>virtio_net: Read the advised MTU >> >> drivers/net/virtio_net.c| 12 >> include/uapi/linux/virtio_net.h | 3 +++ >> 2 files changed, 15 insertions(+) >>
Re: [PATCH] livepatch: Update maintainers
On Wed, Mar 16, 2016 at 10:03:36AM -0500, Josh Poimboeuf wrote: > Seth and Vojtech are no longer active maintainers of livepatch, so > remove them in favor of Jessica and Miroslav. > > Also add Petr as a designated reviewer. > > Signed-off-by: Josh Poimboeuf > --- > MAINTAINERS | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 860e306..e04e0a5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6583,9 +6583,10 @@ F: drivers/platform/x86/hp_accel.c > > LIVE PATCHING > M: Josh Poimboeuf > -M: Seth Jennings > +M: Jessica Yu > M: Jiri Kosina > -M: Vojtech Pavlik > +M: Miroslav Benes > +R: Petr Mladek > S: Maintained > F: kernel/livepatch/ > F: include/linux/livepatch.h > -- > 2.4.3 Acked-by: Vojtech Pavlik -- Vojtech Pavlik Director SuSE Labs
[ANNOUNCE] Git v2.7.4 (and updates to older maintenance tracks)
The latest maintenance release Git v2.7.4 is now available at the usual places. The same set of bugfix patches from the current 'master' have been backported to older maintenance tracks and are available as v2.4.11, v2.5.5 and v2.6.6. These are to fix a heap corruption / buffer overflow bug and users are strongly encouraged to upgrade. The fix has already been in the release candidate v2.8.0-rc3 as well. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.7.4' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.7.4 Release Notes Fixes since v2.7.3 -- * Bugfix patches were backported from the 'master' front to plug heap corruption holes, to catch integer overflow in the computation of pathname lengths, and to get rid of the name_path API. Both of these would have resulted in writing over an under-allocated buffer when formulating pathnames while tree traversal. Changes since v2.7.3 are as follows: Jeff King (7): add helpers for detecting size_t overflow tree-diff: catch integer overflow in combine_diff_path allocation http-push: stop using name_path show_object_with_name: simplify by using path_name() list-objects: convert name_path to a strbuf list-objects: drop name_path entirely list-objects: pass full pathname to callbacks Junio C Hamano (4): Git 2.4.11 Git 2.5.5 Git 2.6.6 Git 2.7.4
Re: [PATCH V2 2/3] vfio, platform: make reset driver a requirement
Hi Baptiste, >> I couldn't see a reset function for AMBA devices. >> >> Is there anyway to write reset function for it? I have no experience with >> AMBA devices. > To my knowledge only the PL330 DMA controller (drivers/dma/pl330.c) was > passthrough'ed at some point, rather for development purpose than > production purpose. This was done by Virtual Open Systems (ask Baptiste > for more details). But I don't think this is really used. Are you OK with requiring reset driver for AMBA devices too? The PL330 driver won't work until a reset driver is submitted for it. >> >> Would you include a reset needed flag and just not require it for AMBA? >> (I honestly don't like this idea) >> > I think the requirement also makes sense for AMBA. > > Maybe an option would be to add a module parameter that would allow to > use the vfio platform/amba driver without reset module (with explicit > opt-in from the user). Maybe this can be done later on. I can see this flag useful for testing purposes but it should not be used in production. How about I add a module parameter which is not set by default? When set, I don't perform the reset requirement check. > > FYI I will not have access to my mailbox until the end of the week. OK, no rush. > > Best Regards > > Eric > -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks
On 03/16/2016 06:23 PM, Chris Mason wrote: On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: On 3/15/16 7:06 PM, Linus Torvalds wrote: On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: It is pretty clear that the onus is on the patch submitter to provide justification for inclusion, not for the reviewer/Maintainer to have to prove that the solution is unworkable. I agree, but quite frankly, performance is a good justification. So if Ted can give performance numbers, that's justification enough. We've certainly taken changes with less. I've been away from ext4 for a while, so I'm really not on top of the mechanics of the underlying problem at the moment. But I would say that in addition to numbers showing that ext4 has trouble with unwritten extent conversion, we should have an explanation of why it can't be solved in a way that doesn't open up these concerns. XFS certainly has different mechanisms, but is the demonstrated workload problematic on XFS (or btrfs) as well? If not, can ext4 adopt any of the solutions that make the workload perform better on other filesystems? When I've benchmarked this in the past, doing small random buffered writes into an preallocated extent was dramatically (3x or more) slower on xfs than doing them into a fully written extent. That was two years ago, but I can redo it. So I re-ran some benchmarks, with 4K O_DIRECT random ios on nvme (4.5 kernel). This is O_DIRECT without O_SYNC. I don't think xfs will do commits for each IO into the prealloc file? O_SYNC makes it much slower, so hopefully I've got this right. The test runs for 60 seconds, and I used an iodepth of 4: prealloc file: 32,000 iops overwrite:121,000 iops If I bump the iodepth up to 512: prealloc file: 33,000 iops overwrite: 279,000 iops For streaming writes, XFS converts prealloc to written much better when the IO isn't random. You can start seeing the difference at 16K sequential O_DIRECT writes, but really its not a huge impact. The worst case is 4K: prealloc file: 227MB/s overwrite: 340MB/s I can't think of sequential workloads where this will matter, since they will either end up with bigger IO or the performance impact won't get noticed. -chris I think that these numbers are the interesting ones, see a 4x slow down is certainly significant. If you do the same patch after hacking XFS preallocation as Dave suggested with xfs_db, do we get most of the performance back? Ric
[PATCH] mtip32xx: fix checks for dma mapping errors
exec_drive_taskfile() checks for dma mapping errors by comparison
returned address with zero, while pci_dma_mapping_error() should be used.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/block/mtip32xx/mtip32xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 9b180dbbd03c..06390f2a7d85 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -2039,7 +2039,7 @@ static int exec_drive_taskfile(struct driver_data *dd,
outbuf,
taskout,
DMA_TO_DEVICE);
- if (outbuf_dma == 0) {
+ if (pci_dma_mapping_error(dd->pdev, outbuf_dma)) {
err = -ENOMEM;
goto abort;
}
@@ -2056,7 +2056,7 @@ static int exec_drive_taskfile(struct driver_data *dd,
inbuf_dma = pci_map_single(dd->pdev,
inbuf,
taskin, DMA_FROM_DEVICE);
- if (inbuf_dma == 0) {
+ if (pci_dma_mapping_error(dd->pdev, inbuf_dma)) {
err = -ENOMEM;
goto abort;
}
--
1.9.1
Re: [PATCH 1/2] x86/perf/intel/uncore: Make Intel uncore modular
On Thu, Mar 17, 2016 at 05:34:14AM -0700, kan.li...@intel.com wrote:
> +static void __exit intel_uncore_exit(void)
> +{
> + cpu_notifier_register_done();
Did you even test this? That should be _begin();
> + __unregister_cpu_notifier(&uncore_cpu_nb);
> + uncore_types_exit(uncore_msr_uncores);
> + uncore_pci_exit();
> + cpu_notifier_register_done();
> +}
> +module_exit(intel_uncore_exit);
> --
> 2.5.0
>
Linux 3.12.57
I'm announcing the release of the 3.12.57 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary A diff can be found at: https://git.kernel.org/stable/linux-stable/d/v3.12.56/v3.12.57 Al Cooper (1): usb: Add connected retry on resume for non SS devices Andreas Schwab (1): powerpc: Fix dedotify for binutils >= 2.26 Andy Lutomirski (1): x86/entry/compat: Add missing CLAC to entry_INT80_32 Arnd Bergmann (1): libata: fix HDIO_GET_32BIT ioctl Daniele Palmas (1): USB: serial: option: add support for Telit LE922 PID 0x1045 David Woodhouse (2): jffs2: Fix page lock / f->sem deadlock Fix directory hardlinks from deleted directories Felix Fietkau (1): mac80211: minstrel_ht: set default tx aggregation timeout to 0 Hannes Frederic Sowa (1): unix: correctly track in-flight fds in sending process user_struct Harvey Hunt (1): libata: Align ata_device's id on a cacheline Jason Andryuk (1): lib/ucs2_string: Correct ucs2 -> utf8 conversion Jiri Slaby (2): Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new" Linux 3.12.57 Johannes Berg (1): wext: fix message delay/ordering Justin Maggard (1): cifs: fix out-of-bounds access in lease parsing Konrad Rzeszutek Wilk (6): xen/pciback: Return error on XEN_PCI_OP_enable_msi when device has MSI or MSI-X enabled xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled xen/pciback: Do not install an IRQ handler for MSI interrupts. xen/pciback: For XEN_PCI_OP_disable_msi[|x] only disable if device has MSI(X) enabled. xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set. xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY Konstantin Shkolnyy (3): USB: cp210x: flush device queues at close USB: cp210x: relocate private data from USB interface to port USB: cp210x: work around cp2108 GET_LINE_CTL bug Maciej W. Rozycki (1): MIPS: traps: Fix SIGFPE information leak from `do_ov' and `do_trap_or_bp' Marcelo Tosatti (1): KVM: x86: move steal time initialization to vcpu entry time Matt Fleming (1): efi: Add pstore variables to the deletion whitelist Michal Marek (1): genksyms: Handle string literals with spaces in reference files NeilBrown (1): nfsd: fix problem with setting ACL on directories Oliver Neukum (1): [media] usbvision fix overflow of interfaces array Pavel Shilovsky (1): CIFS: Fix SMB2+ interim response processing for read requests Peter Jones (5): lib/ucs2_string: Add ucs2 -> utf8 helper functions efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version efi: Do variable name validation tests in utf8 efi: Make our variable validation list include the guid efi: Make efivarfs entries immutable by default Radim Krčmář (1): KVM: VMX: disable PEBS before a guest entry Richard Weinberger (1): ubi: Fix out of bounds write in volume update code Rusty Russell (1): modules: fix longstanding /proc/kallsyms vs module insertion race. Steven Rostedt (Red Hat) (1): tracing: Fix check for cpu online when event is disabled Suravee Suthikulpanit (1): iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered Takashi Iwai (10): ALSA: ctl: Fix ioctls for X32 ABI ALSA: rawmidi: Fix ioctls X32 ABI ALSA: timer: Fix ioctls for X32 ABI ALSA: seq: oss: Don't drain at closing a client ALSA: hdspm: Fix wrong boolean ctl value accesses ALSA: hdsp: Fix wrong boolean ctl value accesses ALSA: hdspm: Fix zero-division ALSA: timer: Fix broken compat timer user status ioctl ASoC: wm8994: Fix enum ctl accesses in a wrong type ASoC: wm8958: Fix enum ctl accesses in a wrong type Thomas Betker (1): Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin" Timothy Pearson (1): drm/ast: Fix incorrect register check for DRAM width Todd E Brandt (1): PM / sleep / x86: Fix crash on graph trace through x86 suspend Vasu Dev (2): ixgbe: use correct FCoE DDP max check ixgbe: fix broken PFC with X550 Vittorio Alfieri (1): USB: cp210x: Add ID for Parrot NMEA GPS Flight Recorder Yegor Yefremov (1): USB: serial: option: add support for Quectel UC20 willy tarreau (1): unix: properly account for FDs passed over unix sockets Documentation/filesystems/efivarfs.txt | 7 + Makefile | 2 +- arch/mips/kernel/traps.c | 13 +- arch/powerpc/kernel/
Re: [PATCH] regulator: Don't print error in devm_regulator_bulk_get() on -EPROBE_DEFER
Hello Mark, On 03/16/2016 06:59 AM, Mark Brown wrote: > On Tue, Mar 15, 2016 at 05:35:14PM -0300, Javier Martinez Canillas wrote: > >> The regulators may not be available just because their driver's probe was >> not executed and the regulators were not registered yet. So don't print an >> error in this case to avoid polluting the kernel log and confuse the users. > > We've been through this repeatedly - this is the case for all probe > deferrals and if we just don't print the errors at all then people won't > be able to tell if they've got a missing dependency. We need people to I wonder if we can use a dev_dbg() then so it will be printed at debug level. That way users can have that info if they want but not pollute the boot log. Basically I want to get rid of things like this: [1.438422] exynos-hdmi 1453.hdmi: Failed to get supply 'vdd': -517 [1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators [1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed The HDMI driver probed correctly but looking at the log it seems that things failed so can mislead users not familiar with the probe deferral mechanism. > work on things like allowing the kernel to make use of the dependency > information it has to order probes more sensibly. > Agreed, I've seen Tomeu's patches and the following discussions. > Raphael had some ideas he was talking about at Kernel Summit for this, > Russell King also proposed just suppressing the errors until we're at > the last deferred probe run at the end of init. > Suppressing errors is a nice idea but will again lead to false positives when the drivers are built as a module AFAICT. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data
On Wednesday, March 16, 2016 06:35:41 PM Peter Zijlstra wrote:
> On Wed, Mar 16, 2016 at 03:59:18PM +0100, Rafael J. Wysocki wrote:
>
> > +static unsigned int get_next_freq(struct cpufreq_policy *policy,
> > + unsigned long util, unsigned long max)
> > +{
> > + unsigned int freq = arch_scale_freq_invariant() ?
> > + policy->cpuinfo.max_freq : policy->cur;
> > +
> > + return (freq + (freq >> 2)) * util / max;
> > +}
> > +
> > +static void sugov_update_single(struct update_util_data *hook, u64 time,
> > + unsigned long util, unsigned long max)
> > +{
> > + struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu,
> > update_util);
> > + struct sugov_policy *sg_policy = sg_cpu->sg_policy;
> > + struct cpufreq_policy *policy = sg_policy->policy;
> > + unsigned int next_f;
> > +
> > + if (!sugov_should_update_freq(sg_policy, time))
> > + return;
> > +
> > + next_f = util <= max ?
> > + get_next_freq(policy, util, max) : policy->cpuinfo.max_freq;
>
> I'm not sure that is correct, would not something like this be more
> accurate?
>
> if (util > max)
> util = max;
> next_f = get_next_freq(policy, util, max);
>
> After all, if we clip util we will still only increment to the next freq
> with our multiplication factor.
>
> Hmm, or was this meant to deal with the DL/RT stuff?
Yes, it was.
> Would then not something like:
>
> /* ULONG_MAX is used to force max_freq for Real-Time policies */
> if (util == ULONG_MAX) {
> next_f = policy->cpuinfo.max_freq;
> } else {
> if (util > max)
That cannot happen given the way CFS deals with max before passing it
to cpufreq_update_util().
> util = max;
> next_f = get_next_freq(policy, util, max);
> }
>
> Be clearer?
>
> > + sugov_update_commit(sg_policy, time, next_f);
> > +}
So essentially I can replace the util > max check with the util == ULONG_MAX one
(here and in some other places) if that helps to understand the code, but
functionally that won't change anything.
[PATCH v5 0/6] (mostly) Arch-independent livepatch
This patchset removes livepatch's need for architecture-specific relocation
code by leveraging existing code in the module loader to perform
arch-dependent work. Specifically, instead of duplicating code and
re-implementing what the apply_relocate_add() function in the module loader
already does in livepatch's klp_write_module_reloc(), we reuse
apply_relocate_add() to write relocations. The hope is that this will make
livepatch more easily portable to other architectures and greatly reduce
the amount of arch-specific code required to port livepatch to a particular
architecture.
Background: Why does livepatch need to write its own relocations?
==
A typical livepatch module contains patched versions of functions that can
reference non-exported global symbols and non-included local symbols.
Relocations referencing these types of symbols cannot be left in as-is
since the kernel module loader cannot resolve them and will therefore
reject the livepatch module. Furthermore, we cannot apply relocations that
affect modules not loaded yet at run time (e.g. a patch to a driver). The
current kpatch build system therefore solves this problem by embedding
special "dynrela" (dynamic reloc) sections in the resulting patch module
Elf output. Using these dynrela sections, livepatch can correctly resolve
symbols while taking into account its scope and what module the symbol
belongs to, and then manually apply the dynamic relocations.
Motivation: Why is having arch-dependent relocation code a problem?
==
The original motivation for this patchset stems from the increasing
roadblocks encountered while attempting to port livepatch to s390.
Specifically, there were problems dealing with s390 PLT and GOT relocation
types (R_390_{PLT,GOT}), which are handled differently from x86's
relocation types (which are much simpler to deal with, and a single
livepatch function (klp_write_module_reloc()) has been sufficient enough).
These s390 reloc types cannot be handled by simply performing a calculation
(as in the x86 case). For s390 modules with PLT/GOT relocations, the kernel
module loader allocates and fills in PLT+GOT table entries for every symbol
referenced by a PLT/GOT reloc in module core memory. So the problem of
porting livepatch to s390 became much more complicated than simply writing
an s390-specific klp_write_module_reloc() function. How can livepatch
handle these relocation types if the s390 module loader needs to allocate
and fill PLT/GOT entries ahead of time? The potential solutions were: 1)
have livepatch possibly allocate and maintain its own PLT/GOT tables for
every patch module (requiring even more arch-specific code), 2) modify the
s390 module loader heavily to accommodate livepatch modules (i.e. allocate
all the needed PLT/GOT entries for livepatch in advance but refrain from
applying relocations for to-be-patched modules), or 3) eliminate this
potential mess by leveraging module loader code to do all the relocation
work, letting livepatch off the hook completely. Solution #3 is what this
patchset implements.
How does this patchset remedy these problems?
==
Reusing the module loader code to perform livepatch relocations means that
livepatch no longer needs arch-specific reloc code and the aforementioned
problems with s390 PLT/GOT reloc types disappear (because we let the module
loader do all the relocation work for us). It will enable livepatch to be
more easily ported to other architectures.
Summary of proposed changes
==
This patch series enables livepatch to use the module loader's
apply_relocate_add() function to apply livepatch relocations (i.e. what
used to be dynrelas). apply_relocate_add() requires access to a patch
module's section headers, symbol table, reloc section indices, etc., and all
of these are accessible through the load_info struct used in the module
loader. Therefore we persist module Elf information (copied from load_info)
for livepatch modules.
The ELF-related changes enable livepatch to patch modules that are not yet
loaded (as well as patch vmlinux when kaslr is enabled). In order to use
apply_relocate_add(), we need real SHT_RELA sections to pass in. A
complication here is that relocations for not-yet-loaded modules should not
be applied when the patch module loads; they should only be applied once
the target module is loaded. Thus kpatch build scripts were modified to
output a livepatch module that contains special .klp.rela. sections that
are managed by livepatch and are applied at the appropriate time (i.e. when
target module loads). They are marked with a special SHF_RELA_LIVEPATCH
section flag to indicate to the module loader that livepatch will handle
them. The SHN_LIVEPATCH shndx marks symbols that need to be resolved
once their respective target module loads. So, the module loader ignores
these symbols and does not attempt to resolve them. These ELF constants
were selected from OS-specific ranges according to the definitions from
glibc.
Patches based on linux-next.
Previous pa
linux-next: build failure after merge of the drm tree
Hi Dave,
After merging the drm tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_userptr_ioctl':
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:321:2: error: implicit declaration of
function 'release_pages' [-Werror=implicit-function-declaration]
release_pages(bo->tbo.ttm->pages, bo->tbo.ttm->num_pages, false);
^
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_bos':
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:410:5: error: implicit declaration of
function 'release_pages' [-Werror=implicit-function-declaration]
release_pages(e->user_pages,
^
Caused by commit
2f568dbd6b94 ("drm/amdgpu: move get_user_pages out of
amdgpu_ttm_tt_pin_userptr v6")
Presumably a forgotten include file.
I added this fix patch for today:
From: Stephen Rothwell
Date: Thu, 17 Mar 2016 15:30:49 +1100
Subject: [PATCH] drm/amdgpu: release_pages requires linux/pagemap.h
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4f5ef4149e87..9392e50a7ba4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
*Jerome Glisse
*/
#include
+#include
#include
#include
#include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 1ecdf6c01368..0f2391ec1ed9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -26,6 +26,7 @@
* Jerome Glisse
*/
#include
+#include
#include
#include
#include "amdgpu.h"
--
2.7.0
--
Cheers,
Stephen Rothwell
Re: [RFC][PATCH v3 1/5] mm/zsmalloc: introduce class auto-compaction
Hi, On (03/18/16 10:17), Minchan Kim wrote: > > > > hm, in this scenario both solutions are less than perfect. we jump > > > > X times over 40% margin, we have X*NR_CLASS compaction scans in the > > > > end. the difference is that we queue less works, yes, but we don't > > > > have to use workqueue in the first place; compaction can be done > > > > asynchronously by a pool's dedicated kthread. so we will just > > > > wake_up() the process. > > > > > > Hmm, kthread is over-engineered to me. If we want to create new kthread > > > in the system, I guess we should persuade many people to merge in. > > > Surely, we should have why it couldn't be done by others(e.g., workqueue). > > > > > > I think your workqueue approach is good to me. > > > Only problem I can see with it is we cannot start compaction when > > > we want instantly so my conclusion is we need both direct and > > > background compaction. > > > > well, if we will keep the shrinker callbacks then it's not such a huge > > issue, IMHO. for that type of forward progress guarantees we can have > > our own, dedicated, workqueue with a rescuer thread (WQ_MEM_RECLAIM). > > What I meant with direct compaction is shrinker while backgroud > compaction is workqueue. > So do you mean that you agree to remain shrinker? hm, probably yes, hard to say. we don't have yet a solution for background compaction. > And do you want to use workqueue with WQ_MEM_RECLAIM rather than > new kthread? I have some concerns here. WQ_MEM_RECLAIM implies that there is a kthread attached to wq, a rescuer thread, which will be idle until wq declares mayday. But the kthread will be allocated anyway. And we can queue only one global compaction work at a time; so wq does not buy us a lot here and a simple wake_up_process() looks much better. it make sense to use wq if we can have N compaction jobs queued, like I did in my initial patch, but otherwise it's sort of overkill, isn't it? > > just thought... I think it'll be tricky to implement this. We scan classes > > from HIGH class_size to SMALL class_size, counting fragmentation value and > > re-calculating the global fragmentation all the time; once the global > > fragmentation passes the watermark, we start compacting from HIGH to > > SMALL. the problem here is that as soon as we calculated the class B > > fragmentation index and moved to class A we can't trust B anymore. classes > > are not locked and absolutely free to change. so the global fragmentation > > index likely will be inaccurate. > > > > Actually, I don't think such inaccuracy will make big trouble here. > But How about this simple idea? > > If zs_free find wasted space is bigger than threshold(e.g., 10M) > > user defined, zs_free can queue work for background compaction( > that background compaction work should be WQ_MEM_RECLAIM | > WQ_CPU_INTENSIVE?). Once that work is executed, the work compacts > all size_class unconditionally. ok. global pool stats that will give us a fragmentation index, so we can start compaction when the entire pool passes the watermark, not an individual class. > With it, less background compaction and more simple algorithm, so you want to have zs_free() check pool watermark queue class compaction queue pool compaction ? I think a simpler one will be to just queue global compaction, if pool is fragmented -- compact everything, like we do in shrinker callback. > no harmful other works by WQ_CPU_INTENSIVE. > > > so I'm thinking about triggering a global compaction from zs_free() (to > > queue less works), but instead of calculating global watermark and > > compacting > > afterwards, just compact every class that has fragmentation over XY% (for > > example 30%). "iterate from HI to LO and compact everything that is too > > fragmented". > > The problem with approach is we can compact only small size class which > is fragment ratio is higher than bigger size class but compaction benefit > is smaller than higher size class which is lower fragment ratio. > With that, continue to need to background work until it meets user-defined > global threshold. good point. > > > > we still need some sort of a pool->compact_ts timestamp to prevent too > > frequent compaction jobs. > > Yes, we need something to throttle mechanism. Need time to think more. :) yes, need to think more :) -ss
[PATCH] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
media_snd_stream_delete() fails to release resources during unbind. This
leads to use-after-free in media_gobj_create() on a subsequent bind.
[ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470
[media] at addr 8801ead49998
[ 1445.086771] Call Trace:
[ 1445.086779] [] dump_stack+0x67/0x94
[ 1445.086785] [] print_trailer+0xf9/0x150
[ 1445.086790] [] object_err+0x34/0x40
[ 1445.086796] [] kasan_report_error+0x221/0x530
[ 1445.086803] [] __asan_report_store8_noabort+0x43/0x50
[ 1445.086813] [] ? media_gobj_create+0x3a1/0x470 [media]
[ 1445.086822] [] media_gobj_create+0x3a1/0x470 [media]
[ 1445.086831] [] media_device_register_entity+0x259/0x6f0
[media]
[ 1445.086841] [] ?
media_device_unregister_entity_notify+0x100/0x100 [media]
[ 1445.086846] [] ? ___slab_alloc+0x172/0x500
[ 1445.086854] [] ? mark_held_locks+0xc8/0x120
[ 1445.086859] [] ? __slab_alloc+0x50/0x70
[ 1445.086878] [] ? media_snd_mixer_init+0x16c/0x500
[snd_usb_audio]
[ 1445.086884] [] ? kasan_unpoison_shadow+0x36/0x50
[ 1445.086890] [] ? kasan_unpoison_shadow+0x36/0x50
[ 1445.086895] [] ? kasan_kmalloc+0x5e/0x70
Signed-off-by: Shuah Khan
---
sound/usb/media.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/usb/media.c b/sound/usb/media.c
index 44a5de9..0d03773 100644
--- a/sound/usb/media.c
+++ b/sound/usb/media.c
@@ -135,7 +135,7 @@ void media_snd_stream_delete(struct snd_usb_substream *subs)
if (mctl && mctl->media_dev) {
struct media_device *mdev;
- mdev = subs->stream->chip->media_dev;
+ mdev = mctl->media_dev;
if (mdev && media_devnode_is_registered(&mdev->devnode)) {
media_devnode_remove(mctl->intf_devnode);
media_device_unregister_entity(&mctl->media_entity);
--
2.5.0
[PATCH v2] openvswitch: call only into reachable nf-nat code
The openvswitch code has gained support for calling into the
nf-nat-ipv4/ipv6 modules, however those can be loadable modules
in a configuration in which openvswitch is built-in, leading
to link errors:
net/built-in.o: In function `__ovs_ct_lookup':
:(.text+0x2cc2c8): undefined reference to `nf_nat_icmp_reply_translation'
:(.text+0x2cc66c): undefined reference to `nf_nat_icmpv6_reply_translation'
The dependency on (!NF_NAT || NF_NAT) prevents similar issues,
but NF_NAT is set to 'y' if any of the symbols selecting
it are built-in, but the link error happens when any of them
are modular.
A second issue is that even if CONFIG_NF_NAT_IPV6 is built-in,
CONFIG_NF_NAT_IPV4 might be completely disabled. This is unlikely
to be useful in practice, but the driver currently only handles
IPv6 being optional.
This patch improves the Kconfig dependency so that openvswitch
cannot be built-in if either of the two other symbols are set
to 'm', and it replaces the incorrect #ifdef in ovs_ct_nat_execute()
with two "if (IS_ENABLED())" checks that should catch all corner
cases also make the code more readable.
The same #ifdef exists ovs_ct_nat_to_attr(), where it does not
cause a link error, but for consistency I'm changing it the same
way.
Signed-off-by: Arnd Bergmann
Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
Acked-by: Joe Stringer
---
v2: leave (!NF_NAT || NF_NAT) dependency in there, we also need that
net/openvswitch/Kconfig | 4 +++-
net/openvswitch/conntrack.c | 16
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
index 234a73344c6e..ce947292ae77 100644
--- a/net/openvswitch/Kconfig
+++ b/net/openvswitch/Kconfig
@@ -7,7 +7,9 @@ config OPENVSWITCH
depends on INET
depends on !NF_CONNTRACK || \
(NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
-(!NF_NAT || NF_NAT)))
+(!NF_NAT || NF_NAT) && \
+(!NF_NAT_IPV4 || NF_NAT_IPV4) && \
+(!NF_NAT_IPV6 || NF_NAT_IPV6)))
select LIBCRC32C
select MPLS
select NET_MPLS_GSO
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index dc5eb29fe7d6..ff04b5db04b3 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -535,14 +535,15 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct
nf_conn *ct,
switch (ctinfo) {
case IP_CT_RELATED:
case IP_CT_RELATED_REPLY:
- if (skb->protocol == htons(ETH_P_IP) &&
+ if (IS_ENABLED(CONFIG_NF_NAT_IPV4) &&
+ skb->protocol == htons(ETH_P_IP) &&
ip_hdr(skb)->protocol == IPPROTO_ICMP) {
if (!nf_nat_icmp_reply_translation(skb, ct, ctinfo,
hooknum))
err = NF_DROP;
goto push;
-#if IS_ENABLED(CONFIG_NF_NAT_IPV6)
- } else if (skb->protocol == htons(ETH_P_IPV6)) {
+ } else if (IS_ENABLED(CONFIG_NF_NAT_IPV6) &&
+ skb->protocol == htons(ETH_P_IPV6)) {
__be16 frag_off;
u8 nexthdr = ipv6_hdr(skb)->nexthdr;
int hdrlen = ipv6_skip_exthdr(skb,
@@ -557,7 +558,6 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct
nf_conn *ct,
err = NF_DROP;
goto push;
}
-#endif
}
/* Non-ICMP, fall thru to initialize if needed. */
case IP_CT_NEW:
@@ -1238,7 +1238,8 @@ static bool ovs_ct_nat_to_attr(const struct
ovs_conntrack_info *info,
}
if (info->range.flags & NF_NAT_RANGE_MAP_IPS) {
- if (info->family == NFPROTO_IPV4) {
+ if (IS_ENABLED(CONFIG_NF_NAT_IPV4) &&
+ info->family == NFPROTO_IPV4) {
if (nla_put_in_addr(skb, OVS_NAT_ATTR_IP_MIN,
info->range.min_addr.ip) ||
(info->range.max_addr.ip
@@ -1246,8 +1247,8 @@ static bool ovs_ct_nat_to_attr(const struct
ovs_conntrack_info *info,
(nla_put_in_addr(skb, OVS_NAT_ATTR_IP_MAX,
info->range.max_addr.ip
return false;
-#if IS_ENABLED(CONFIG_NF_NAT_IPV6)
- } else if (info->family == NFPROTO_IPV6) {
+ } else if (IS_ENABLED(CONFIG_NF_NAT_IPV6) &&
+ info->family == NFPROTO_IPV6) {
if (nla_put_in6_addr(skb, OVS_NAT_ATTR_IP_MIN,
&info->range.min_addr.in6) ||
(memcmp(&info->range.max_addr.
[PATCH v20 15/23] richacl: Update the file masks in chmod()
Doing a chmod() sets the file mode, which includes the file permission
bits. When a file has a richacl, the permissions that the richacl
grants need to be limited to what the new file permission bits allow.
This is done by setting the file masks in the richacl to what the file
permission bits map to. The richacl access check algorithm takes the
file masks into account, which ensures that the richacl cannot grant too
many permissions.
It is possible to explicitly add permissions to the file masks which go
beyond what the file permission bits can grant (like the
RICHACE_WRITE_ACL permission). The POSIX.1 standard calls this an
alternate file access control mechanism. A subsequent chmod() would
ensure that those permissions are disabled again.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: J. Bruce Fields
---
fs/richacl.c| 71 +
include/linux/richacl.h | 1 +
2 files changed, 72 insertions(+)
diff --git a/fs/richacl.c b/fs/richacl.c
index 59ef600..23c1aa9 100644
--- a/fs/richacl.c
+++ b/fs/richacl.c
@@ -543,3 +543,74 @@ out:
return denied ? -EACCES : 0;
}
EXPORT_SYMBOL_GPL(richacl_permission);
+
+/**
+ * __richacl_chmod - update the file masks to reflect the new mode
+ * @acl: access control list
+ * @mode: new file permission bits including the file type
+ *
+ * Return a copy of @acl where the file masks have been replaced by the file
+ * masks corresponding to the file permission bits in @mode, or returns @acl
+ * itself if the file masks are already up to date. Takes over a reference
+ * to @acl.
+ */
+static struct richacl *
+__richacl_chmod(struct richacl *acl, umode_t mode)
+{
+ unsigned int x = S_ISDIR(mode) ? 0 : RICHACE_DELETE_CHILD;
+ unsigned int owner_mask, group_mask, other_mask;
+ struct richacl *clone;
+
+ owner_mask = richacl_mode_to_mask(mode >> 6) & ~x;
+ group_mask = richacl_mode_to_mask(mode >> 3) & ~x;
+ other_mask = richacl_mode_to_mask(mode) & ~x;
+
+ if (acl->a_owner_mask == owner_mask &&
+ acl->a_group_mask == group_mask &&
+ acl->a_other_mask == other_mask &&
+ (acl->a_flags & RICHACL_MASKED) &&
+ (acl->a_flags & RICHACL_WRITE_THROUGH))
+ return acl;
+
+ clone = richacl_clone(acl, GFP_KERNEL);
+ richacl_put(acl);
+ if (!clone)
+ return ERR_PTR(-ENOMEM);
+
+ clone->a_flags |= (RICHACL_WRITE_THROUGH | RICHACL_MASKED);
+ clone->a_owner_mask = owner_mask;
+ clone->a_group_mask = group_mask;
+ clone->a_other_mask = other_mask;
+
+ return clone;
+}
+
+/**
+ * richacl_chmod - filesystem chmod helper
+ * @inode: inode whose file permission bits to change
+ * @mode: new file permission bits including the file type
+ *
+ * Helper for filesystems to use to perform a chmod on the richacl of an inode.
+ */
+int
+richacl_chmod(struct inode *inode, umode_t mode)
+{
+ struct richacl *acl;
+ int retval;
+
+ if (S_ISLNK(mode))
+ return -EOPNOTSUPP;
+ if (!inode->i_op->set_richacl)
+ return -EOPNOTSUPP;
+ acl = get_richacl(inode);
+ if (IS_ERR_OR_NULL(acl))
+ return PTR_ERR(acl);
+ acl = __richacl_chmod(acl, mode);
+ if (IS_ERR(acl))
+ return PTR_ERR(acl);
+ retval = inode->i_op->set_richacl(inode, acl);
+ richacl_put(acl);
+
+ return retval;
+}
+EXPORT_SYMBOL(richacl_chmod);
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
index d19b61b..554f050 100644
--- a/include/linux/richacl.h
+++ b/include/linux/richacl.h
@@ -185,5 +185,6 @@ extern unsigned int richacl_mode_to_mask(umode_t);
extern unsigned int richacl_want_to_mask(unsigned int);
extern void richacl_compute_max_masks(struct richacl *);
extern int richacl_permission(struct inode *, const struct richacl *, int);
+extern int richacl_chmod(struct inode *, umode_t);
#endif /* __RICHACL_H */
--
2.5.0
Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header
On Fri, Mar 18, 2016 at 02:07:25PM +0700, Suravee Suthikulpanit wrote: > Actually the exposed APIs (in both files) are from the AMD IOMMU driver, > which is not necessary x86-specific. They mostly use struct pci_dev, which > is also arch-agnostic. It is correct that the current IOMMU IP is only > available in x86 systems. However, if AMD plans to use the IOMMU IP in the > ARM-based processors in the future, putting these into > include/linux/amd-iommu.h would work better. Let's wait until AMD does that then. Moving the header is the easiest part. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev
Hello,
On 03/11/2016, 06:12 PM, Tejun Heo wrote:
> On Thu, Mar 03, 2016 at 10:12:01AM +0100, Jiri Slaby wrote:
>> On 03/02/2016, 04:45 PM, Tejun Heo wrote:
>>> On Fri, Feb 19, 2016 at 01:10:00PM +0100, Jiri Slaby wrote:
> 1. didn't help, the problem persists. So I haven't applied the patch from
> 2.
FWIW I dumped more info about the wq:
wq->name='hci0' pwq=8800390d7600 wq->dfl_pwq=8800390d5200
pwq->refcnt=2 pwq->nr_active=0 delayed_works:
>>>
>>> Can you please print out the same info for all pwq's during shutdown?
>>> It looks like we're leaking pwq refcnt but I can't spot a place where
>>> that could happen on an empty pwq.
>>
>> I have not done that yet, but today, I see:
>> destroy_workqueue: name='req_hci0' pwq=88002f590300
>> wq->dfl_pwq=88002f591e00 pwq->refcnt=2 pwq->nr_active=0 delayed_works:
>>pwq 12: cpus=0-1 node=0 flags=0x4 nice=-20 active=0/1
>> in-flight: 18568:wq_barrier_func
>
> So, this means that there's flush_work() racing against workqueue
> destruction, which can't be safe. :(
But I cannot trigger the WARN_ONs in the attached patch, so I am
confused how this can happen :(. (While I am still seeing the destroy
WARNINGs.)
BTW. what did you mean by dumping the states at shutdown? Is it still
relevant?
thanks,
--
js
suse labs
---
include/linux/workqueue.h|1 +
include/net/bluetooth/hci_core.h |5 +
kernel/reboot.c |1 +
kernel/workqueue.c | 34 +++---
net/bluetooth/hci_core.c | 39 +++
5 files changed, 73 insertions(+), 7 deletions(-)
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -312,6 +312,7 @@ enum {
__WQ_DRAINING = 1 << 16, /* internal: workqueue is draining */
__WQ_ORDERED = 1 << 17, /* internal: workqueue is ordered */
__WQ_LEGACY = 1 << 18, /* internal: create*_workqueue() */
+ __WQ_DESTROYING = 1 << 19,
WQ_MAX_ACTIVE = 512, /* I like 512, better ideas? */
WQ_MAX_UNBOUND_PER_CPU = 4, /* 4 * #cpus for unbound wq */
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -312,6 +312,11 @@ struct hci_dev {
struct workqueue_struct *workqueue;
struct workqueue_struct *req_workqueue;
+#define HCI_WQ_A 0
+#define HCI_WQ_D 1
+#define HCI_WQR_A 8
+#define HCI_WQR_D 9
+ unsigned long wq_status;
struct work_struct power_on;
struct delayed_work power_off;
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -231,6 +231,7 @@ static void kernel_shutdown_prepare(enum
(state == SYSTEM_HALT) ? SYS_HALT : SYS_POWER_OFF, NULL);
system_state = state;
usermodehelper_disable();
+ show_workqueue_state();
device_shutdown();
}
/**
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1366,6 +1366,9 @@ static void __queue_work(int cpu, struct
unsigned int work_flags;
unsigned int req_cpu = cpu;
+ if (WARN_ON(wq->flags & __WQ_DESTROYING))
+ return;
+
/*
* While a work item is PENDING && off queue, a task trying to
* steal the PENDING will busy-loop waiting for it to either get
@@ -2804,6 +2807,9 @@ static bool start_flush_work(struct work
pwq = worker->current_pwq;
}
+ if (WARN_ON(pwq->wq->flags & __WQ_DESTROYING))
+ return false;
+
check_flush_dependency(pwq->wq, work);
insert_wq_barrier(pwq, barr, work, worker);
@@ -2821,6 +2827,8 @@ static bool start_flush_work(struct work
lock_map_acquire_read(&pwq->wq->lockdep_map);
lock_map_release(&pwq->wq->lockdep_map);
+ WARN_ON(pwq->wq->flags & __WQ_DESTROYING);
+
return true;
already_gone:
spin_unlock_irq(&pool->lock);
@@ -3998,6 +4006,8 @@ err_destroy:
}
EXPORT_SYMBOL_GPL(__alloc_workqueue_key);
+static void show_pwq(struct pool_workqueue *pwq);
+
/**
* destroy_workqueue - safely terminate a workqueue
* @wq: target workqueue
@@ -4010,6 +4020,7 @@ void destroy_workqueue(struct workqueue_
int node;
/* drain it before proceeding with destruction */
+ wq->flags |= __WQ_DESTROYING;
drain_workqueue(wq);
/* sanity checks */
@@ -4024,9 +4035,26 @@ void destroy_workqueue(struct workqueue_
}
}
- if (WARN_ON((pwq != wq->dfl_pwq) && (pwq->refcnt > 1)) ||
- WARN_ON(pwq->nr_active) ||
- WARN_ON(!list_empty(&pwq->delayed_works))) {
+ if ((pwq != wq->dfl_pwq) && (pwq->refcnt > 1)) {
+ pr_info("%s: name='%s' pwq=%p wq->dfl_pwq=%p pwq->refcnt=%d pwq->nr_active=%d delayed_works:",
+ __func__, wq->name, pwq, wq->dfl_pwq,
+ pwq->refcnt, pwq->nr_active);
+
+ show_pwq(pwq);
+
+ mutex_unlock(&wq->mutex);
+ WARN_ON(1);
+ return;
+ }
+
+ if (WARN_ON(pwq->nr_active)) {
+ pr_info("%s: %ps\n", __func__, wq);
+ mutex_unlock(&wq->mutex);
+ return;
+ }
+
+ if (WARN_ON(!list_empty(&pwq->delayed_works))) {
+ pr_info("%s: %ps\n", __func__, wq);
mutex_unlock(&wq->mutex);
return;
}
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1471,7 +1471,11 @@ int hci_dev_open(__u16 dev)
* has fi
Re: Nokia N900 - audio TPA6130A2 problems
Hi On Fri Mar 18 12:33:14 2016 Peter Ujfalusi wrote: > > But enabling the pull via DT for the i2c2 works? > No :(. I even migrated the driver to regmap - no gain. Maybe i2c bus is blocked by another device held in reset. The next thing I am going to try is to deassert reset/power gpios on all the devices on i2c-2 bus, to see if it will make any difference. Or if you have any other ideas, please share. Ivo
[PATCH v12 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
Signed-off-by: Jitao Shi
---
Changes since v11:
- Remove depends on I2C, add DRM depends
- Reuse ps8640_write_bytes() in ps8640_write_byte()
- Use timer check for polling like the routines in
- Fix no drm_connector_unregister/drm_connector_cleanup when
ps8640_bridge_attach fail
- Check the ps8640 hardware id in ps8640_validate_firmware
- Remove fw_version check
- Move ps8640_validate_firmware before ps8640_enter_bl
- Add ddc_i2c unregister when probe fail and ps8640_remove
The following patches are needed to support dsi host through none dsi bus:
https://patchwork.kernel.org/patch/8289181/ ("drm/dsi: check for CONFIG_OF when
defining")
https://patchwork.kernel.org/patch/8289051/ ("drm/dsi: Use
mipi_dsi_device_register_full for DSI device")
https://patchwork.kernel.org/patch/8289081/ ("drm/dsi: Try to match non-DT DSI
devices")
https://patchwork.kernel.org/patch/8289121/ ("drm/dsi: Add routine to
unregister a DSI device")
https://patchwork.kernel.org/patch/8289091/ ("drm/dsi: Get DSI host by DT
device node")
---
drivers/gpu/drm/bridge/Kconfig | 12 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/parade-ps8640.c | 1073
3 files changed, 1086 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..be6084e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,16 @@ config DRM_PARADE_PS8622
---help---
Parade eDP-LVDS bridge chip driver.
+config DRM_PARADE_PS8640
+ tristate "Parade PS8640 MIPI DSI to eDP Converter"
+ depends on DRM
+ depends on OF
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL
+ ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..fbe38dc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..d7700e2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1073 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET 0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA 0x90
+#define PAGE2_SWSPI_RDATA 0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK 0x01
+#define PAGE2_SPI_STATUS 0x9e
+#define PAGE2_GPIO_L 0xa6
+#define PAGE2_GPIO_H 0xa7
+#define PS_GPIO9 BIT(1)
+#define PAGE2_IROM_CTRL0xb0
+#define IROM_ENABLE0xc0
+#define IROM_DISABLE 0x80
+#define PAGE2_SW_REST 0xbc
+#define SPI_SW_RESET BIT(7)
+#define MPU_SW_RESET BIT(6)
+#define PAGE2_ENCTLSPI_WR 0xda
+#define PAGE2_I2C_BYPASS 0xea
+#define I2C_BYPASS_EN 0xd0
+#define PAGE3_SET_ADD 0xfe
+#define PAGE3_SET_VAL 0xff
+#define VDO_CTL_ADD0x13
+#define VDO_DIS0x18
+#define VDO_EN 0x1c
+#define PAGE4_REV_L0xf0
+#define PAGE4_REV_H0xf1
+#define PAGE4_CHIP_L 0xf2
+#define PAGE4_CHIP_H 0xf3
+
+/* Firmware */
+#define SPI_MAX_RETRY_CNT 8
+#define PS_FW_NAME "ps864x_fw.bin"
+
+#define FW_CHIP_ID_OFFSET 0
+#define FW_VERSION_OFFSET 2
+#define EDID_I2C_ADDR 0x50
+
+#define WRITE_STATUS_REG_CMD 0x01
+#define READ_STATUS_REG_CMD0x05
+#define BUSY BIT(0)
+
[PATCH 3.19.y-ckt 41/70] ALSA: seq: oss: Don't drain at closing a client
v3.19.8-ckt17 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Takashi Iwai
commit 197b958c1e76a575d77038cc98b4bebc2134279f upstream.
The OSS sequencer client tries to drain the pending events at
releasing. Unfortunately, as spotted by syzkaller fuzzer, this may
lead to an unkillable process state when the event has been queued at
the far future. Since the process being released can't be signaled
any longer, it remains and waits for the echo-back event in that far
future.
Back to history, the draining feature was implemented at the time we
misinterpreted POSIX definition for blocking file operation.
Actually, such a behavior is superfluous at release, and we should
just release the device as is instead of keeping it up forever.
This patch just removes the draining call that may block the release
for too long time unexpectedly.
BugLink:
http://lkml.kernel.org/r/cact4y+y4kd-abgj37rf-xbw9bh3gmu6p+myg4w1e-s-pavd...@mail.gmail.com
Reported-by: Dmitry Vyukov
Signed-off-by: Takashi Iwai
Signed-off-by: Kamal Mostafa
---
sound/core/seq/oss/seq_oss.c| 2 --
sound/core/seq/oss/seq_oss_device.h | 1 -
sound/core/seq/oss/seq_oss_init.c | 16
3 files changed, 19 deletions(-)
diff --git a/sound/core/seq/oss/seq_oss.c b/sound/core/seq/oss/seq_oss.c
index 16d4267..bb032d7 100644
--- a/sound/core/seq/oss/seq_oss.c
+++ b/sound/core/seq/oss/seq_oss.c
@@ -144,8 +144,6 @@ odev_release(struct inode *inode, struct file *file)
if ((dp = file->private_data) == NULL)
return 0;
- snd_seq_oss_drain_write(dp);
-
mutex_lock(®ister_mutex);
snd_seq_oss_release(dp);
mutex_unlock(®ister_mutex);
diff --git a/sound/core/seq/oss/seq_oss_device.h
b/sound/core/seq/oss/seq_oss_device.h
index b439243..d7b4d01 100644
--- a/sound/core/seq/oss/seq_oss_device.h
+++ b/sound/core/seq/oss/seq_oss_device.h
@@ -127,7 +127,6 @@ int snd_seq_oss_write(struct seq_oss_devinfo *dp, const
char __user *buf, int co
unsigned int snd_seq_oss_poll(struct seq_oss_devinfo *dp, struct file *file,
poll_table * wait);
void snd_seq_oss_reset(struct seq_oss_devinfo *dp);
-void snd_seq_oss_drain_write(struct seq_oss_devinfo *dp);
/* */
void snd_seq_oss_process_queue(struct seq_oss_devinfo *dp, abstime_t time);
diff --git a/sound/core/seq/oss/seq_oss_init.c
b/sound/core/seq/oss/seq_oss_init.c
index e0c1834..b5fdcd6 100644
--- a/sound/core/seq/oss/seq_oss_init.c
+++ b/sound/core/seq/oss/seq_oss_init.c
@@ -438,22 +438,6 @@ snd_seq_oss_release(struct seq_oss_devinfo *dp)
/*
- * Wait until the queue is empty (if we don't have nonblock)
- */
-void
-snd_seq_oss_drain_write(struct seq_oss_devinfo *dp)
-{
- if (! dp->timer->running)
- return;
- if (is_write_mode(dp->file_mode) && !is_nonblock_mode(dp->file_mode) &&
- dp->writeq) {
- while (snd_seq_oss_writeq_sync(dp->writeq))
- ;
- }
-}
-
-
-/*
* reset sequencer devices
*/
void
--
2.7.0
Re: [PATCH V2 1/2] x86/perf/intel/uncore: Make Intel uncore modular
On Fri, 18 Mar 2016, kan.li...@intel.com wrote:
> From: Kan Liang
>
> This patch makes Intel uncore pmu driver modular.
> By default, the uncore driver will be built in the kernel. If it is
> configured as module, the supported cpu model can be auto loaded.
> This patch also cleans up the code of cpu_init and pci_init.
Nice work!
> +static struct intel_uncore_init_fun skl_uncore_init = {
> + .pci_init = skl_uncore_pci_init,
> +};
> +
> +static const struct x86_cpu_id intel_uncore_match[] = {
Shouldn't all of these structs be const __initconst?
Other than that:
Reviewed-by: Thomas Gleixner
[PATCH] dma-buf/sync_file: de-stage sync_file
From: Gustavo Padovan
sync_file is useful to connect one or more fences to the file. The file is
used by userspace to track fences.
Signed-off-by: Gustavo Padovan
---
drivers/Kconfig| 2 +
drivers/dma-buf/Kconfig| 11 +
drivers/dma-buf/Makefile | 1 +
drivers/dma-buf/sync_file.c| 382 +
drivers/staging/android/Kconfig| 1 +
drivers/staging/android/sync.c | 362 ---
drivers/staging/android/sync.h | 92 +
drivers/staging/android/sync_debug.c | 1 +
include/linux/sync_file.h | 106 ++
.../uapi/sync.h => include/uapi/linux/sync_file.h | 0
10 files changed, 506 insertions(+), 452 deletions(-)
create mode 100644 drivers/dma-buf/Kconfig
create mode 100644 drivers/dma-buf/sync_file.c
create mode 100644 include/linux/sync_file.h
rename drivers/staging/android/uapi/sync.h => include/uapi/linux/sync_file.h
(100%)
diff --git a/drivers/Kconfig b/drivers/Kconfig
index d2ac339..430f761 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -114,6 +114,8 @@ source "drivers/rtc/Kconfig"
source "drivers/dma/Kconfig"
+source "drivers/dma-buf/Kconfig"
+
source "drivers/dca/Kconfig"
source "drivers/auxdisplay/Kconfig"
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
new file mode 100644
index 000..9824bc4
--- /dev/null
+++ b/drivers/dma-buf/Kconfig
@@ -0,0 +1,11 @@
+menu "DMABUF options"
+
+config SYNC_FILE
+ bool "sync_file support for fences"
+ default n
+ select ANON_INODES
+ select DMA_SHARED_BUFFER
+ ---help---
+ This option enables the fence framework synchronization to export
+ sync_files to userspace that can represent one or more fences.
+endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 57a675f..4a424ec 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1 +1,2 @@
obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
+obj-$(CONFIG_SYNC_FILE)+= sync_file.o
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
new file mode 100644
index 000..df786a2
--- /dev/null
+++ b/drivers/dma-buf/sync_file.c
@@ -0,0 +1,382 @@
+/*
+ * drivers/dma-buf/sync_file.c
+ *
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct file_operations sync_file_fops;
+
+static struct sync_file *sync_file_alloc(int size, const char *name)
+{
+ struct sync_file *sync_file;
+
+ sync_file = kzalloc(size, GFP_KERNEL);
+ if (!sync_file)
+ return NULL;
+
+ sync_file->file = anon_inode_getfile("sync_file", &sync_file_fops,
+sync_file, 0);
+ if (IS_ERR(sync_file->file))
+ goto err;
+
+ kref_init(&sync_file->kref);
+ strlcpy(sync_file->name, name, sizeof(sync_file->name));
+
+ init_waitqueue_head(&sync_file->wq);
+
+ return sync_file;
+
+err:
+ kfree(sync_file);
+ return NULL;
+}
+
+static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
+{
+ struct sync_file_cb *check;
+ struct sync_file *sync_file;
+
+ check = container_of(cb, struct sync_file_cb, cb);
+ sync_file = check->sync_file;
+
+ if (atomic_dec_and_test(&sync_file->status))
+ wake_up_all(&sync_file->wq);
+}
+
+/* TODO: implement a create which takes more that one fence */
+struct sync_file *sync_file_create(const char *name, struct fence *fence)
+{
+ struct sync_file *sync_file;
+
+ sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]),
+ name);
+ if (!sync_file)
+ return NULL;
+
+ sync_file->num_fences = 1;
+ atomic_set(&sync_file->status, 1);
+
+ sync_file->cbs[0].fence = fence;
+ sync_file->cbs[0].sync_file = sync_file;
+ if (fence_add_callback(fence, &sync_file->cbs[0].cb,
+ fence_check_cb_func))
+ atomic_dec(&sync_file->status);
+
+ return sync_file;
+}
+EXPORT_SYMBOL(sync_file_create);
+
+struct sync_file *sync_file_fdget(int fd)
+{
+ struct file *file = fget(fd);
+
+ if (!file)
+ return NULL;
+
+
Re: [PATCH] serial-uartlite: fix build warning
On Thu, Mar 10, 2016 at 2:14 PM, Sudip Mukherjee
wrote:
> We were getting build warnings about:
> drivers/tty/serial/uartlite.c: In function ‘ulite_request_port’:
> drivers/tty/serial/uartlite.c:348:21: warning: assignment discards
> 'const' qualifier from pointer target type
> port->private_data = &uartlite_be;
> ^
> drivers/tty/serial/uartlite.c:354:22: warning: assignment discards
> 'const' qualifier from pointer target type
> port->private_data = &uartlite_le;
> ^
>
> Fixes: 2905697a82ea ("serial-uartlite: Constify uartlite_be/uartlite_le")
> Signed-off-by: Sudip Mukherjee
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PART1 RFC v3 03/12] KVM: x86: Introducing kvm_x86_ops VCPU blocking/unblocking hooks
On 18/03/2016 07:09, Suravee Suthikulpanit wrote:
> Adding new function pointer in struct kvm_x86_ops, and calling them
> from the kvm_arch_vcpu[blocking/unblocking].
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/include/asm/kvm_host.h | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 4b0dd0f..87eac2a 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -972,6 +972,10 @@ struct kvm_x86_ops {
>*/
> int (*pre_block)(struct kvm_vcpu *vcpu);
> void (*post_block)(struct kvm_vcpu *vcpu);
> +
> + void (*vcpu_blocking)(struct kvm_vcpu *vcpu);
> + void (*vcpu_unblocking)(struct kvm_vcpu *vcpu);
> +
> int (*update_pi_irte)(struct kvm *kvm, unsigned int host_irq,
> uint32_t guest_irq, bool set);
> };
> @@ -1323,7 +1327,16 @@ bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct
> kvm_lapic_irq *irq,
> void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
>struct kvm_lapic_irq *irq);
>
> -static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
> +static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu)
> +{
> + if (kvm_x86_ops->vcpu_blocking)
> + kvm_x86_ops->vcpu_blocking(vcpu);
> +}
> +
> +static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu)
> +{
> + if (kvm_x86_ops->vcpu_unblocking)
> + kvm_x86_ops->vcpu_unblocking(vcpu);
> +}
>
> #endif /* _ASM_X86_KVM_HOST_H */
>
Reviewed-by: Paolo Bonzini
[PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY
This is a new phy driver for the SoC USB controllers on the TI DA8XX
family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
The USB 2.0 PHY also allows overriding the VBUS and ID pins.
Signed-off-by: David Lechner
---
v2 changes: This is new patch in v2.
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile| 1 +
drivers/phy/phy-da8xx-usb.c | 295
3 files changed, 305 insertions(+)
create mode 100644 drivers/phy/phy-da8xx-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..a6060ea 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -35,6 +35,15 @@ config ARMADA375_USBCLUSTER_PHY
depends on OF && HAS_IOMEM
select GENERIC_PHY
+config PHY_DA8XX_USB
+ tristate "TI DA8XX USB PHY Driver"
+ depends on ARCH_DAVINCI_DA8XX
+ select GENERIC_PHY
+ help
+ Enable this to support the USB PHY on DA8XX SoCs.
+
+ This driver controls both the USB 1.1 PHY and the USB 2.0 PHY.
+
config PHY_DM816X_USB
tristate "TI dm816x USB PHY driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..722e01c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
+obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
new file mode 100644
index 000..93a5f4d
--- /dev/null
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -0,0 +1,295 @@
+/*
+ * phy-da8xx-usb - TI DaVinci DA8XX USB PHY driver
+ *
+ * Copyright (C) 2016 David Lechner
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* DA8xx CFGCHIP2 (USB PHY Control) register bits */
+#define PHYCLKGD (1 << 17)
+#define VBUSSENSE (1 << 16)
+#define RESET (1 << 15)
+#define OTGMODE_MASK (3 << 13)
+#define NO_OVERRIDE(0 << 13)
+#define FORCE_HOST (1 << 13)
+#define FORCE_DEVICE (2 << 13)
+#define FORCE_HOST_VBUS_LOW(3 << 13)
+#define USB1PHYCLKMUX (1 << 12)
+#define USB2PHYCLKMUX (1 << 11)
+#define PHYPWRDN (1 << 10)
+#define OTGPWRDN (1 << 9)
+#define DATPOL (1 << 8)
+#define USB1SUSPENDM (1 << 7)
+#define PHY_PLLON (1 << 6)
+#define SESENDEN (1 << 5)
+#define VBDTCTEN (1 << 4)
+#define REFFREQ_MASK (0xf << 0)
+#define REFFREQ_12MHZ (1 << 0)
+#define REFFREQ_24MHZ (2 << 0)
+#define REFFREQ_48MHZ (3 << 0)
+#define REFFREQ_19_2MHZ(4 << 0)
+#define REFFREQ_38_4MHZ(5 << 0)
+#define REFFREQ_13MHZ (6 << 0)
+#define REFFREQ_26MHZ (7 << 0)
+#define REFFREQ_20MHZ (8 << 0)
+#define REFFREQ_40MHZ (9 << 0)
+
+struct da8xx_usbphy {
+ struct phy_provider *phy_provider;
+ struct phy *usb11_phy;
+ struct phy *usb20_phy;
+ struct clk *usb11_clk;
+ struct clk *usb20_clk;
+ void __iomem*phy_ctrl;
+};
+
+static inline u32 da8xx_usbphy_readl(void __iomem *base)
+{
+ return readl(base);
+}
+
+static inline void da8xx_usbphy_writel(void __iomem *base, u32 value)
+{
+ writel(value, base);
+}
+
+static int da8xx_usb11_phy_init(struct phy *phy)
+{
+ struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
+ int ret;
+ u32 val;
+
+ ret = clk_prepare_enable(d_phy->usb11_clk);
+ if (ret)
+ return ret;
+
+ val = da8xx_usbphy_readl(d_phy->phy_ctrl);
+ val |= USB1SUSPENDM;
+ da8xx_usbphy_writel(d_phy->phy_ctrl, val);
+
+ return 0;
+}
+
+static int da8xx_usb11_phy_shutdown(struct phy *phy)
+{
+ struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
+ u32 val;
+
+ val = da8xx_usbphy_readl(d_phy->phy_ctrl);
+ val &= ~USB1SUSPENDM;
+ da8xx_usbphy_writel(d_phy->phy_ctrl, val);
+
[PATCH v6 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting.
From: Gu Zheng
The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid <-> nodeid mapping such
as
wq_numa_possible_cpumask will not cause any problem.
It contains 4 steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
2. Introduce a new array storing all possible cpuid <-> apicid mapping.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
4. Establish all possible cpuid <-> nodeid mapping.
This patch finishes step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
arch/ia64/kernel/acpi.c | 2 +-
arch/x86/kernel/acpi/boot.c | 2 +-
drivers/acpi/bus.c| 3 ++
drivers/acpi/processor_core.c | 65 +++
include/linux/acpi.h | 6
5 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index b1698bc..7db5563 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -796,7 +796,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
* ACPI based hotplug CPU support
*/
#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
/*
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0ce06ee..7d45261 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -696,7 +696,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 0e85678..215177a 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1110,6 +1110,9 @@ static int __init acpi_init(void)
acpi_sleep_proc_init();
acpi_wakeup_device_init();
acpi_debugger_init();
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+ acpi_set_processor_mapping();
+#endif
return 0;
}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 824b98b..45580ff 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -261,6 +261,71 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static bool map_processor(acpi_handle handle, int *phys_id, int *cpuid)
+{
+ int type;
+ u32 acpi_id;
+ acpi_status status;
+ acpi_object_type acpi_type;
+ unsigned long long tmp;
+ union acpi_object object = { 0 };
+ struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
+
+ status = acpi_get_type(handle, &acpi_type);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ switch (acpi_type) {
+ case ACPI_TYPE_PROCESSOR:
+ status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = object.processor.proc_id;
+ break;
+ case ACPI_TYPE_DEVICE:
+ status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = tmp;
+ break;
+ default:
+ return false;
+ }
+
+ type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
+
+ *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false);
+ *cpuid = acpi_map_cpuid(*phys_id, acpi_id);
+ if (*cpuid == -1)
+ return false;
+
+ return true;
+}
+
+static acpi_status __init
+set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context,
+ void **rv)
+{
+ u32 apic_id;
+ int cpu_id;
+
+ if (!map_processor(handle, &apic_id, &cpu_id))
+ return AE_ERROR;
+
+ acpi_map_cpu2node(handle, cpu_id, apic_id);
+ return AE_OK;
+}
+
+void __init acpi_set_processor_mapping(void)
+{
+ /* Set persistent cpu <-> node mapping for all processors. */
+ acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+ ACPI_UINT32_MAX, set_processor_node_mapping,
+ NULL, NULL, NULL);
+}
+#endif
+
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
u64 *phys_addr, int *ioapic_id)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..ad9e7c7 100644
---
[PATCH 1/3] ARM: at91: use chipid device for soc detection
So far, the CIDR and EXID registers were in the DBGU interface. This device
has disappeared with the SAMA5D2 family. These registers are exposed
through a new device called chipid.
Signed-off-by: Ludovic Desroches
[nicolas.fe...@atmel.com: remove useless warnings]
---
.../devicetree/bindings/arm/atmel-at91.txt | 4 ++
arch/arm/mach-at91/soc.c | 81 +-
2 files changed, 67 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt
b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index 7fd64ec..0b1fcbf 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -41,6 +41,10 @@ compatible: must be one of:
- "atmel,sama5d43"
- "atmel,sama5d44"
+Chipid required properties:
+- compatible: Should be "atmel,sama5d2-chipid"
+- reg : Should contain registers location and length
+
PIT Timer required properties:
- compatible: Should be "atmel,at91sam9260-pit"
- reg: Should contain registers location and length
diff --git a/arch/arm/mach-at91/soc.c b/arch/arm/mach-at91/soc.c
index 54343ff..034d563 100644
--- a/arch/arm/mach-at91/soc.c
+++ b/arch/arm/mach-at91/soc.c
@@ -22,48 +22,93 @@
#include "soc.h"
#define AT91_DBGU_CIDR 0x40
-#define AT91_DBGU_CIDR_VERSION(x) ((x) & 0x1f)
-#define AT91_DBGU_CIDR_EXT BIT(31)
-#define AT91_DBGU_CIDR_MATCH_MASK 0x7fe0
#define AT91_DBGU_EXID 0x44
+#define AT91_CHIPID_CIDR 0x00
+#define AT91_CHIPID_EXID 0x04
+#define AT91_CIDR_VERSION(x) ((x) & 0x1f)
+#define AT91_CIDR_EXT BIT(31)
+#define AT91_CIDR_MATCH_MASK 0x7fe0
-struct soc_device * __init at91_soc_init(const struct at91_soc *socs)
+int __init at91_get_cidr_exid_from_dbgu(u32 *cidr, u32 *exid)
{
- struct soc_device_attribute *soc_dev_attr;
- const struct at91_soc *soc;
- struct soc_device *soc_dev;
struct device_node *np;
void __iomem *regs;
- u32 cidr, exid;
np = of_find_compatible_node(NULL, NULL, "atmel,at91rm9200-dbgu");
if (!np)
np = of_find_compatible_node(NULL, NULL,
"atmel,at91sam9260-dbgu");
+ if (!np)
+ return -ENODEV;
- if (!np) {
- pr_warn("Could not find DBGU node");
- return NULL;
+ regs = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!regs) {
+ pr_warn("Could not map DBGU iomem range");
+ return -ENXIO;
}
+ *cidr = readl(regs + AT91_DBGU_CIDR);
+ *exid = readl(regs + AT91_DBGU_EXID);
+
+ iounmap(regs);
+
+ return 0;
+}
+
+int __init at91_get_cidr_exid_from_chipid(u32 *cidr, u32 *exid)
+{
+ struct device_node *np;
+ void __iomem *regs;
+
+ np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-chipid");
+ if (!np)
+ return -ENODEV;
+
regs = of_iomap(np, 0);
of_node_put(np);
if (!regs) {
pr_warn("Could not map DBGU iomem range");
- return NULL;
+ return -ENXIO;
}
- cidr = readl(regs + AT91_DBGU_CIDR);
- exid = readl(regs + AT91_DBGU_EXID);
+ *cidr = readl(regs + AT91_CHIPID_CIDR);
+ *exid = readl(regs + AT91_CHIPID_EXID);
iounmap(regs);
+ return 0;
+}
+
+struct soc_device * __init at91_soc_init(const struct at91_soc *socs)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ const struct at91_soc *soc;
+ struct soc_device *soc_dev;
+ u32 cidr, exid;
+ int ret;
+
+ /*
+* With SAMA5D2 and later SoCs, CIDR and EXID registers are no more
+* in the dbgu device but in the chipid device whose purpose is only
+* to expose these two registers.
+*/
+ ret = at91_get_cidr_exid_from_dbgu(&cidr, &exid);
+ if (ret)
+ ret = at91_get_cidr_exid_from_chipid(&cidr, &exid);
+ if (ret) {
+ if (ret == -ENODEV)
+ pr_warn("Could not find identification node");
+ return NULL;
+ }
+
for (soc = socs; soc->name; soc++) {
- if (soc->cidr_match != (cidr & AT91_DBGU_CIDR_MATCH_MASK))
+ if (soc->cidr_match != (cidr & AT91_CIDR_MATCH_MASK))
continue;
- if (!(cidr & AT91_DBGU_CIDR_EXT) || soc->exid_match == exid)
+ if (!(cidr & AT91_CIDR_EXT) || soc->exid_match == exid)
break;
}
@@ -79,7 +124,7 @@ struct soc_device * __init at91_soc_init(const struct
at91_soc *socs)
soc_dev_attr->family = soc->family;
soc_dev_attr->soc_id = soc->name;
soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%X",
- A
[PATCH v4 2/2] auxdisplay: ht16k33: Driver for LED controller
This is a driver for the Holtek HT16K33 RAM mapping LED controller with keyscan.
Signed-off-by: Robin van der Gracht
---
Changes in v4:
- Removed trailing dot from patch title
- Removed unused defines
- Fixed brightness range (0 was presumed to be off but its 1/16 duty cycle)
- No longer checking 'reschedule' before setting it in ht16k33_keypad_scan()
- Use more efficient ffs() to find changed rows in ht16k33_keypad_scan()
- Use BIT macro in ht16k33_keypad_scan()
- Removed extra space in return line from ht16k33_bl_check_fb()
- Removed redundant 'Out of Memory' prints from ht16k33_probe()
- Changed bustype from BUS_HOST to BUS_I2C
.../devicetree/bindings/display/ht16k33.txt| 42 ++
drivers/auxdisplay/Kconfig | 9 +
drivers/auxdisplay/Makefile| 1 +
drivers/auxdisplay/ht16k33.c | 563 +
4 files changed, 615 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ht16k33.txt
create mode 100644 drivers/auxdisplay/ht16k33.c
diff --git a/Documentation/devicetree/bindings/display/ht16k33.txt
b/Documentation/devicetree/bindings/display/ht16k33.txt
new file mode 100644
index 000..20ef996
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ht16k33.txt
@@ -0,0 +1,42 @@
+Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan
+---
+
+Required properties:
+- compatible: "ht,ht16k33"
+- reg: I2C slave address of the chip.
+- interrupt-parent:A phandle pointing to the interrupt controller\
+ serving the interrupt for this chip.
+- interrupts: Interrupt specification for the key pressed interrupt.
+- refresh-rate-hz: Display update interval in HZ.
+- debounce-delay-ms: Debouncing interval time in microseconds.
+- linux,keymap:The keymap for keys as described in the binding
+ document (devicetree/bindings/input/matrix-keymap.txt).
+
+Optional properties:
+- linux,no-autorepeat: Disable keyrepeat.
+- default-brightness-level: Initial brightness level [0-15] (default: 15).
+
+Example:
+
+&i2c1 {
+ ht16k33: ht16k33@70 {
+ compatible = "ht,ht16k33";
+ reg = <0x70>;
+ refresh-rate-hz = <20>;
+ debounce-delay-ms = <50>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+ linux,keymap = <
+ MATRIX_KEY(2, 0, KEY_F6)
+ MATRIX_KEY(3, 0, KEY_F8)
+ MATRIX_KEY(4, 0, KEY_F0)
+ MATRIX_KEY(5, 0, KEY_F4)
+ MATRIX_KEY(6, 0, KEY_F2)
+ MATRIX_KEY(2, 1, KEY_F5)
+ MATRIX_KEY(3, 1, KEY_F7)
+ MATRIX_KEY(4, 1, KEY_F9)
+ MATRIX_KEY(5, 1, KEY_F3)
+ MATRIX_KEY(6, 1, KEY_F1)
+ >;
+ };
+};
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index c07e725..75ad4f5 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -119,4 +119,13 @@ config CFAG12864B_RATE
If you compile this as a module, you can still override this
value using the module parameters.
+config HT16K33
+ tristate "Holtek Ht16K33 LED controller with keyscan"
+ depends on FB && OF && I2C && INPUT
+ select INPUT_MATRIXKMAP
+ select FB_BACKLIGHT
+ help
+ Say yes here to add support for Holtek HT16K33, RAM mapping 16*8
+ LED controller driver with keyscan.
+
endif # AUXDISPLAY
diff --git a/drivers/auxdisplay/Makefile b/drivers/auxdisplay/Makefile
index 8a8936a..d7c9ef5 100644
--- a/drivers/auxdisplay/Makefile
+++ b/drivers/auxdisplay/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_KS0108) += ks0108.o
obj-$(CONFIG_CFAG12864B) += cfag12864b.o cfag12864bfb.o
+obj-$(CONFIG_HT16K33) += ht16k33.o
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
new file mode 100644
index 000..3d61b19
--- /dev/null
+++ b/drivers/auxdisplay/ht16k33.c
@@ -0,0 +1,563 @@
+/*
+ * HT16K33 driver
+ *
+ * Author: Robin van der Gracht
+ *
+ * Copyright: (C) 2016 Protonic Holland.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
[GIT PULL] Driver core patches for 4.6-rc1
The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865: Linux 4.5-rc4 (2016-02-14 13:05:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/driver-core-4.6-rc1 for you to fetch changes up to 112d125a89479519efc437b2961b8d4a98761c1b: Revert "driver-core: platform: probe of-devices only using list of compatibles" (2016-02-15 12:52:59 -0800) Driver core patches for 4.6-rc1 Just a few patches this time around for the 4.6-rc1 merge window. Largest is a new firmware driver, but there are some other updates to the driver core in here as well, the shortlog has the details. All have been in linux-next for a while with no reported issues. Signed-off-by: Greg Kroah-Hartman Arnd Bergmann (1): firmware: qemu config needs I/O ports Gabriel Somlo (4): kobject: export kset_find_obj() for module use firmware: introduce sysfs driver for QEMU's fw_cfg device firmware: create directory hierarchy for sysfs fw_cfg entries devicetree: update documentation for fw_cfg ARM bindings Geliang Tang (2): driver core: bus: use list_for_each_entry* driver core: bus: use to_subsys_private and to_device_private_bus Greg Kroah-Hartman (2): Merge 4.5-rc4 into driver-core-next Revert "driver-core: platform: probe of-devices only using list of compatibles" Jiaxing Wang (1): debugfs: Add stub function for debugfs_create_automount(). Michal Nazarewicz (1): drivers: dma-coherent: simplify dma_init_coherent_memory return value Sudip Mukherjee (1): component: remove impossible condition Tejun Heo (1): kernfs: make kernfs_walk_ns() use kernfs_pr_cont_buf[] Uwe Kleine-König (2): driver-core: platform: fix typo in documentation for multi-driver helper driver-core: platform: probe of-devices only using list of compatibles Valentin Rothberg (1): firmware: qemu_fw_cfg.c: fix typo FW_CFG_DATA_OFF .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 100 +++ Documentation/devicetree/bindings/arm/fw-cfg.txt | 38 +- Documentation/driver-model/platform.txt| 2 +- drivers/base/bus.c | 15 +- drivers/base/component.c | 2 +- drivers/base/dma-coherent.c| 28 +- drivers/firmware/Kconfig | 20 + drivers/firmware/Makefile | 1 + drivers/firmware/qemu_fw_cfg.c | 751 + fs/kernfs/dir.c| 19 +- include/linux/debugfs.h| 8 + lib/kobject.c | 1 + 12 files changed, 915 insertions(+), 70 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg create mode 100644 drivers/firmware/qemu_fw_cfg.c
[PART1 RFC v3 08/12] KVM: x86: Add trace events for AVIC
Introduce trace events for AMD AVIC incomplete IPI vmexit, and
AVIC unaccelerate access vmexit.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kvm/trace.h | 57
arch/x86/kvm/x86.c | 2 ++
2 files changed, 59 insertions(+)
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index ad9f6a2..3c85a3d 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -1288,6 +1288,63 @@ TRACE_EVENT(kvm_hv_stimer_cleanup,
__entry->vcpu_id, __entry->timer_index)
);
+/*
+ * Tracepoint for AMD AVIC
+ */
+TRACE_EVENT(kvm_avic_incomplete_ipi,
+ TP_PROTO(u32 vcpu, u32 icrh, u32 icrl, u32 id, u32 index),
+ TP_ARGS(vcpu, icrh, icrl, id, index),
+
+ TP_STRUCT__entry(
+ __field(u32, vcpu)
+ __field(u32, icrh)
+ __field(u32, icrl)
+ __field(u32, id)
+ __field(u32, index)
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu = vcpu;
+ __entry->icrh = icrh;
+ __entry->icrl = icrl;
+ __entry->id = id;
+ __entry->index = index;
+ ),
+
+ TP_printk("vcpu=%#x, icrh:icrl=%#010x:%08x, id=%u, index=%u\n",
+ __entry->vcpu, __entry->icrh, __entry->icrl,
+ __entry->id, __entry->index)
+);
+
+TRACE_EVENT(kvm_avic_unaccelerated_access,
+ TP_PROTO(u32 vcpu, u32 offset, bool ft, bool rw, u32 vec),
+ TP_ARGS(vcpu, offset, ft, rw, vec),
+
+ TP_STRUCT__entry(
+ __field(u32, vcpu)
+ __field(u32, offset)
+ __field(bool, ft)
+ __field(bool, rw)
+ __field(u32, vec)
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu = vcpu;
+ __entry->offset = offset;
+ __entry->ft = ft;
+ __entry->rw = rw;
+ __entry->vec = vec;
+ ),
+
+ TP_printk("vcpu=%#x, offset=%#x(%s), %s, %s, vec=%#x\n",
+ __entry->vcpu,
+ __entry->offset,
+ __print_symbolic(__entry->offset, kvm_trace_symbol_apic),
+ __entry->ft ? "trap" : "fault",
+ __entry->rw ? "write" : "read",
+ __entry->vec)
+);
+
#endif /* _TRACE_KVM_H */
#undef TRACE_INCLUDE_PATH
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4d2961d..775de1c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8395,3 +8395,5 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_write_tsc_offset);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_ple_window);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_pml_full);
EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_pi_irte_update);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_unaccelerated_access);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_incomplete_ipi);
--
1.9.1
[PATCH v14.1 09/17] drm: rockchip: dp: add rockchip platform dp driver
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14.1:
- replace rockchip_drm_encoder_get_mux_id with the new
drm_of_encoder_active_endpoint_id
Changes in v14: None
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
Changes in v12: None
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.
Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
and leave "sclk_edp" to analogix dp core driver which name to "dp",
and leave "pclk_edp" to rockchip dp platform driver which name to
"pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.
Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 384
include/drm/bridge/analogix_dp.h| 1 +
4 files changed, 395 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 76b3362..d30bdc3 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -16,6 +16,15 @@ config DRM_ROCKCHIP
2D or 3D acceleration; acceleration is performed by other
IP found on the SoC.
+config ROCKCHIP_ANALOGIX_DP
+ tristate "Rockchip specific extensions for Analogix DP driver"
+ depends on DRM_ROCKCHIP
+ select DRM_ANALOGIX_DP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
+
config ROCKCHIP_DW_HDMI
tristate "Rockchip specific extensions for Synopsys DW HDMI"
depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index df8fbef..05d0713 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,6 +6,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchip_drm_gem.o rockchip_drm_vop.o
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..a1d94d8
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,384 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan
+ * Yakir Yang
+ * Jeff Chen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+ struct drm_device
Re: [PATCH] acpi: Issue _OSC call for native thermal interrupt handling
On Wed, 2016-03-16 at 23:48 +0100, Rafael J. Wysocki wrote:
> On Wednesday, March 16, 2016 03:25:19 PM Srinivas Pandruvada wrote:
> > There are several reports of freeze on enabling HWP (Hardware
> > PStates)
> > feature on Skylake based systems by Intel P states driver. The root
> > cause is identified as the HWP interrupts causing BIOS code to
> > freeze.
> > HWP interrupts uses thermal LVT.
> > Linux natively handles thermal interrupts, but in Skylake based
> > systems
> > SMM will take control of thermal interrupts. This is a problem for
> > several
> > reasons:
> > - It is freezing in BIOS when tries to handle thermal interrupt,
> > which
> > will require BIOS upgrade
> > - With SMM handling thermal we loose all the reporting features of
> > Linux arch/x86/kernel/cpu/mcheck/therm_throt driver
> > - Some thermal drivers like x86-package-temp driver depends on the
> > thermal
> > threshold interrupts
> > - The HWP interrupts are useful for debugging and tuning
> > performance
> >
> > So we need native handling of thermal interrupts. To inform SMM
> > that
> > OS will handle thermal interrupts, we need to use _OSC under
> > processor
> > scope very early in ACPI initialization flow. This needs to be done
> > before SMM code path looks for _OSC capabilities. The bit 12 of
> > _OSC in processor scope defines whether OS will handle thermal
> > interrupts.
> > When bit 12 is set to 1, OS will handle thermal interrupts.
> > Refer to this document for details on _OSC
> > http://www.intel.com/content/www/us/en/standards/processor-vendor-
> > specific-acpi-specification.html
> >
> > This change introduces a new function
> > acpi_early_processor_set_osc(),
> > which walks acpi name space and finds acpi processor object and
> > set capability via _OSC method to take over thermal LVT.
> >
> > Also this change writes HWP status bits to 0 to clear any HWP
> > status
> > bits in intel_thermal_interrupt().
> >
> > Signed-off-by: Srinivas Pandruvada > .com>
>
> Has this version of the patch been tested on a system where the
> problem
> is reproducible?
1.
Yes. I tested on Yoga 260.
2.
Also in
https://bugzilla.kernel.org/show_bug.cgi?id=110941
One user confirmed it.
3.
One user in Debian forum
http://forums.debian.net/viewtopic.php?f=7&t=127415
I hope more users will confirm soon as this was reported on many distro
forums also.
I sent this for review and make available for more users to test.
>
> > ---
> > arch/x86/kernel/cpu/mcheck/therm_throt.c | 8 ++
> > drivers/acpi/acpi_processor.c| 42
> > +++-
> > drivers/acpi/bus.c | 3 +++
> > drivers/acpi/internal.h | 2 ++
> > 4 files changed, 54 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> > b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> > index 0b445c2..bb331f6 100644
> > --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> > +++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> > @@ -79,6 +79,8 @@ static atomic_t therm_throt_en=
> > ATOMIC_INIT(0);
> >
> > static u32 lvtthmr_init __read_mostly;
> >
> > +static bool thermal_hwp_interrupt_support;
> > +
> > #ifdef CONFIG_SYSFS
> > #define define_therm_throt_device_one_ro(_name)
> > \
> > static DEVICE_ATTR(_name, 0444,
> > \
> > @@ -384,6 +386,9 @@ static void intel_thermal_interrupt(void)
> > {
> > __u64 msr_val;
> >
> > + if (thermal_hwp_interrupt_support)
> > + wrmsrl_safe(MSR_HWP_STATUS, 0);
> > +
> > rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
> >
> > /* Check for violation of core thermal thresholds*/
> > @@ -552,6 +557,9 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
> > rdmsr(MSR_IA32_MISC_ENABLE, l, h);
> > wrmsr(MSR_IA32_MISC_ENABLE, l | MSR_IA32_MISC_ENABLE_TM1,
> > h);
> >
> > + if (static_cpu_has(X86_FEATURE_HWP))
> > + thermal_hwp_interrupt_support = true;
> > +
> > /* Unmask the thermal vector: */
> > l = apic_read(APIC_LVTTHMR);
> > apic_write(APIC_LVTTHMR, l & ~APIC_LVT_MASKED);
> > diff --git a/drivers/acpi/acpi_processor.c
> > b/drivers/acpi/acpi_processor.c
> > index 6979186..5a78279 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -391,7 +391,6 @@ static int acpi_processor_add(struct
> > acpi_device *device,
> > if (pr->id >= setup_max_cpus && pr->id != 0)
> > return 0;
> > #endif
> > -
> > BUG_ON(pr->id >= nr_cpu_ids);
> >
> > /*
> > @@ -491,6 +490,47 @@ static void acpi_processor_remove(struct
> > acpi_device *device)
> > }
> > #endif /* CONFIG_ACPI_HOTPLUG_CPU */
> >
>
> It occurs to me that the whole thing is only necessary on x86, so
> maybe it can
> go under a #ifdef?
OK. I will submit a new revision.
>
> Or even to arch/x86/acpi/ (boot.c or a new file)?
>
> > +static bool acpi_hwp_native_thermal_lvt_set;
> > +static acpi_status acpi_set_hwp_native_thermal_l
Re: [PATCH v4 01/13] pinctrl: sunxi: Add A83T R_PIO controller
Hello Linus, On Thu, Mar 17, 2016 at 10:51 PM, Linus Walleij wrote: > On Wed, Mar 16, 2016 at 5:04 PM, Vishnu Patekar > wrote: > >> The A83T has R_PIO pin controller, it's same as A23, execpt A83T >> interrupt bit is 6th and A83T has one extra pin PL12. >> >> Signed-off-by: Vishnu Patekar >> Acked-by: Chen-Yu Tsai >> Acked-by: Rob Herring > > I think I already merged this? AFAIK, this one is not yet merged. At least, you did not say it's merged. :) > > Yours, > Linus Walleij
[PATCH 3.19.y-ckt 32/70] ALSA: hdsp: Fix wrong boolean ctl value accesses
v3.19.8-ckt17 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Takashi Iwai
commit eab3c4db193f5fcccf70e884de9a922ca2c63d80 upstream.
snd-hdsp driver accesses enum item values (int) instead of boolean
values (long) wrongly for some ctl elements. This patch fixes them.
Signed-off-by: Takashi Iwai
Signed-off-by: Kamal Mostafa
---
sound/pci/rme9652/hdsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
index cf5a6c8..072cea2 100644
--- a/sound/pci/rme9652/hdsp.c
+++ b/sound/pci/rme9652/hdsp.c
@@ -2882,7 +2882,7 @@ static int snd_hdsp_get_dds_offset(struct snd_kcontrol
*kcontrol, struct snd_ctl
{
struct hdsp *hdsp = snd_kcontrol_chip(kcontrol);
- ucontrol->value.enumerated.item[0] = hdsp_dds_offset(hdsp);
+ ucontrol->value.integer.value[0] = hdsp_dds_offset(hdsp);
return 0;
}
@@ -2894,7 +2894,7 @@ static int snd_hdsp_put_dds_offset(struct snd_kcontrol
*kcontrol, struct snd_ctl
if (!snd_hdsp_use_is_exclusive(hdsp))
return -EBUSY;
- val = ucontrol->value.enumerated.item[0];
+ val = ucontrol->value.integer.value[0];
spin_lock_irq(&hdsp->lock);
if (val != hdsp_dds_offset(hdsp))
change = (hdsp_set_dds_offset(hdsp, val) == 0) ? 1 : 0;
--
2.7.0
[PATCH v3 5/5] ARM: davinci: remove mmc dma resources
The davinci_mmc driver no longer uses platform resources for getting dma
channels. Instead lookup is now done using dma_slave_map.
Signed-off-by: David Lechner
Acked-by: Sekhar Nori
---
v3 changes: none.
arch/arm/mach-davinci/devices-da8xx.c | 20
arch/arm/mach-davinci/devices.c | 16
2 files changed, 36 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 725e693..add3771 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -751,16 +751,6 @@ static struct resource da8xx_mmcsd0_resources[] = {
.end= IRQ_DA8XX_MMCSDINT0,
.flags = IORESOURCE_IRQ,
},
- { /* DMA RX */
- .start = DA8XX_DMA_MMCSD0_RX,
- .end= DA8XX_DMA_MMCSD0_RX,
- .flags = IORESOURCE_DMA,
- },
- { /* DMA TX */
- .start = DA8XX_DMA_MMCSD0_TX,
- .end= DA8XX_DMA_MMCSD0_TX,
- .flags = IORESOURCE_DMA,
- },
};
static struct platform_device da8xx_mmcsd0_device = {
@@ -788,16 +778,6 @@ static struct resource da850_mmcsd1_resources[] = {
.end= IRQ_DA850_MMCSDINT0_1,
.flags = IORESOURCE_IRQ,
},
- { /* DMA RX */
- .start = DA850_DMA_MMCSD1_RX,
- .end= DA850_DMA_MMCSD1_RX,
- .flags = IORESOURCE_DMA,
- },
- { /* DMA TX */
- .start = DA850_DMA_MMCSD1_TX,
- .end= DA850_DMA_MMCSD1_TX,
- .flags = IORESOURCE_DMA,
- },
};
static struct platform_device da850_mmcsd1_device = {
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 6257aa4..67d26c5 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -144,14 +144,6 @@ static struct resource mmcsd0_resources[] = {
.start = IRQ_SDIOINT,
.flags = IORESOURCE_IRQ,
},
- /* DMA channels: RX, then TX */
- {
- .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
- .flags = IORESOURCE_DMA,
- }, {
- .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCTXEVT),
- .flags = IORESOURCE_DMA,
- },
};
static struct platform_device davinci_mmcsd0_device = {
@@ -181,14 +173,6 @@ static struct resource mmcsd1_resources[] = {
.start = IRQ_DM355_SDIOINT1,
.flags = IORESOURCE_IRQ,
},
- /* DMA channels: RX, then TX */
- {
- .start = EDMA_CTLR_CHAN(0, 30), /* rx */
- .flags = IORESOURCE_DMA,
- }, {
- .start = EDMA_CTLR_CHAN(0, 31), /* tx */
- .flags = IORESOURCE_DMA,
- },
};
static struct platform_device davinci_mmcsd1_device = {
--
1.9.1
Re: [v3,1/8] powerpc: Create a helper for getting the kernel toc value
On Wed, Mar 16, 2016 at 09:23:19PM +1100, Michael Ellerman wrote: > > Sure. I'll try and get something working, though this merge window is not > starting well so I may not get time for a few weeks :) Do you already have something in mind? Can you give us a hint? Torsten
Re: [PART1 RFC v2 07/10] svm: Add VMEXIT handlers for AVIC
Hi Radim,
On 03/10/2016 03:55 AM, Radim Krčmář wrote:
>+ pr_debug("%s: offset=%#x, rw=%#x, vector=%#x, vcpu_id=%#x, cpu=%#x\n",
>+__func__, offset, rw, vector, svm->vcpu.vcpu_id, svm->vcpu.cpu);
>+
>+ BUG_ON(offset >= 0x400);
These are valid faulting registers, so our implementation has to handle
them. (And the rule is to never BUG if a recovery is simple.)
Just want to clarify the part that you mentioned "to handle them".
IIUC, offet 0x400 and above are for x2APIC stuff, which AVIC does not
currently support. Also, since I have only advertised as xAPIC when
enabling AVIC, if we run into the situation that the VM is trying to
access these register, we should just ignore it (and not BUG). Do I
understand that correctly?
Thanks,
Suravee
Re: [PATCH v4 02/13] clk: sunxi: add ahb1 clock for A83T
On Thu, Mar 17, 2016 at 12:04:25AM +0800, Vishnu Patekar wrote:
> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
> clock index 0b1x is PLL6.
>
> Signed-off-by: Vishnu Patekar
> Acked-by: Chen-Yu Tsai
> Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> drivers/clk/sunxi/clk-sunxi.c | 76
> +++
> 2 files changed, 77 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 834436f..cba9fe55 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -30,6 +30,7 @@ Required properties:
> "allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
> "allwinner,sun9i-a80-cpus-clk" - for the CPUS on A80
> "allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
> + "allwinner,sun8i-a83t-ahb1-clk" - for the AHB1 clock on A83T
> "allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
> "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
> "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 91de0a0..a7aab65 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -344,6 +344,67 @@ static void sun6i_ahb1_recalc(struct factors_request
> *req)
> req->rate >>= req->p;
> }
>
> +#define SUN8I_A83T_AHB1_PARENT_PLL6 2
> +/**
> + * sun8i_a83t_get_ahb_factors() - calculates m, p factors for AHB
> + * AHB rate is calculated as follows
> + * rate = parent_rate >> p
> + *
> + * if parent is pll6, then
> + * parent_rate = pll6 rate / (m + 1)
> + */
> +
> +static void sun8i_a83t_get_ahb1_factors(struct factors_request *req)
> +{
> + u8 div, calcp, calcm = 1;
> +
> + /*
> + * clock can only divide, so we will never be able to achieve
> + * frequencies higher than the parent frequency
> + */
> + if (req->parent_rate && req->rate > req->parent_rate)
> + req->rate = req->parent_rate;
> +
> + div = DIV_ROUND_UP(req->parent_rate, req->rate);
> +
> + /* calculate pre-divider if parent is pll6 */
> + if (req->parent_index >= SUN8I_A83T_AHB1_PARENT_PLL6) {
> + if (div < 4)
> + calcp = 0;
> + else if (div / 2 < 4)
> + calcp = 1;
> + else if (div / 4 < 4)
> + calcp = 2;
> + else
> + calcp = 3;
> +
> + calcm = DIV_ROUND_UP(div, 1 << calcp);
> + } else {
> + calcp = __roundup_pow_of_two(div);
> + calcp = calcp > 3 ? 3 : calcp;
> + }
> +
> + req->rate = (req->parent_rate / calcm) >> calcp;
> + req->p = calcp;
> + req->m = calcm - 1;
> +}
> +
> +/**
> +* sun8i_a83t_ahb1_recalc() - calculates AHB clock rate from m, p factors and
> +* parent index
> +*/
> +static void sun8i_a83t_ahb1_recalc(struct factors_request *req)
> +{
> + req->rate = req->parent_rate;
> +
> +/* apply pre-divider first if parent is pll6 */
The comment indentation is wrong
> + if (req->parent_index >= SUN6I_AHB1_PARENT_PLL6)
And this is not the right define you're using.
I still believe that duplicating the same logic just because of
different dividers is not the way to go.
You could solve that easily by adding a table for the muxes, and
associate it with parents and dividers, that you could store in
clk_factors.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH v10 3/3] staging/android: refactor SYNC IOCTLs
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.
However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.
Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.
Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.
info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.
An example userspace code for the later would be:
struct sync_file_info *info;
int err, size, num_fences;
info = malloc(sizeof(*info));
info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;
if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
sizeof(struct
sync_fence_info));
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}
Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
Acked-by: Greg Hackmann
Acked-by: Rob Clark
Acked-by: Daniel Vetter
---
v2: fix fence_info memory leak
v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()
Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size
Comments from Dan Carpenter
- fix info->sync_fence_info documentation
v4: remove allocated struct sync_file_info (comment from Maarten)
v5: merge all commits that were changing the ABI
v6: fix -Wint-to-pointer-cast error on info.sync_fence_info
---
drivers/staging/android/sync.c | 76 -
drivers/staging/android/uapi/sync.h | 36 +-
2 files changed, 67 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..f9c6094 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
goto err_put_fd;
}
+ if (data.flags || data.pad) {
+ err = -EINVAL;
+ goto err_put_fd;
+ }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
}
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+ struct sync_fence_info *info)
{
- struct sync_fence_info *info = data;
-
- if (size < sizeof(*info))
- return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,63 @@ static int sync_fill_fence_info(struct fence *fence, void
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
- return sizeof(*info);
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
{
- struct sync_file_info *info;
+ struct sync_file_info info;
+ struct sync_fence_info *fence_info = NULL;
__u32 size;
- __u32 len = 0;
int ret, i;
- if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+ if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
- if (size < sizeof(struct sync_file_info))
+ if (info.flags || info.pad)
return -EINVAL;
- if (size > 4096)
-
kernel/irq: Null-ptr deref on handle_irq_event_percpu function
+linux-kernel and irq maitainer.
Best Regards,
Baozeng Ding
On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote:
> On Wed Feb 24 08:44:30 2016, splovi...@gmail.com wrote:
> > Dear all,
> >
> > I hit the following bug when fuzzing kernel using
> > syzkaller:
> >
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory
> > accessgeneral protection fault: [#1] SMP KASAN
> > Modules linked in:
> > CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0+ #5
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> > task: 88002eb09700 ti: 88002eb88000 task.ti: 88002eb88000
> > RIP: 0010:[] []
> > handle_irq_event_percpu+0xcd/0x6d0
> > RSP: 0018:880053307e20 EFLAGS: 00010082
> > RAX: RBX: dc00 RCX: 0001
> > RDX: 0001 RSI: 88002eb09f18 RDI: 0046
> > RBP: 880053307e70 R08: 0001 R09: 0001
> > R10: R11: 0001 R12:
> > R13: 88002f1706b0 R14: ed0005e2e0de R15: 88002f1706b0
> > FS: () GS:88005330()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 8005003b
> > CR2: 2000c000 CR3: 00a82000 CR4: 06e0
> > Stack:
> > 88002f170680 2eb09700 10f464b2 fbfff0f464ba
> > 0004 88002f170680 88002f170720 88002f1706b0
> > ed0005e2e0de 88002f1706b0 880053307ea0 81433bd7
> > Call Trace:
> > Call Trace:
> >
> > [] handle_irq_event+0xa7/0x140
> > kernel/irq/handle.c:193
> > [] handle_edge_irq+0x1e1/0x8d0
> > kernel/irq/chip.c:623
> > [< inline >] generic_handle_irq_desc
> > kernel/include/linux/irqdesc.h:146
> > [] handle_irq+0x109/0x2a0
> > kernel/arch/x86/kernel/irq_64.c:78
> > [< inline >] ? rcu_lock_release
> > kernel/include/linux/rcupdate.h:495
> > [< inline >] ? rcu_read_unlock
> > kernel/include/linux/rcupdate.h:930
> > [< inline >] ? __atomic_notifier_call_chain
> > kernel/kernel/notifier.c:184
> > [] ? atomic_notifier_call_chain+0xbf/0x140
> > kernel/kernel/notifier.c:193
> > [] ? __atomic_notifier_call_chain+0x150/0x150
> > kernel/include/linux/rcupdate.h:926
> > [] do_IRQ+0x7d/0x1a0
> > kernel/arch/x86/kernel/irq.c:240
> > [] common_interrupt+0x8c/0x8c
> > kernel/arch/x86/entry/entry_64.S:520
> > [] ? native_safe_halt+0x6/0x10
> > kernel/arch/x86/include/asm/irqflags.h:49
> > [< inline >] arch_safe_halt
> > kernel/arch/x86/include/asm/paravirt.h:117
> > [] default_idle+0x22/0x2a0
> > kernel/arch/x86/kernel/process.c:304
> > [] arch_cpu_idle+0xa/0x10
> > kernel/arch/x86/kernel/process.c:295
> > [] default_idle_call+0x48/0x70
> > kernel/kernel/sched/idle.c:92
> > [< inline >] cpuidle_idle_call
> > kernel/kernel/sched/idle.c:156
> > [< inline >] cpu_idle_loop kernel/kernel/sched/idle.c:252
> > [] cpu_startup_entry+0x4bf/0x610
> > kernel/kernel/sched/idle.c:300
> > [] start_secondary+0x2a8/0x380
> > kernel/arch/x86/kernel/smpboot.c:251
> > [] ? set_cpu_sibling_map+0x1890/0x1890
> > kernel/include/linux/topology.h:80
> > Code: 48 89 45 c8 48 c7 c0 90 25 a3 87 48 c1 e8 03 48 89 45 c0 e9 4f
> > 01 00 00 e8 31 8e 0e 00 4c 89 e0 48 c1 e8 03 65 ff 0d 23 0a be 7e <80>
> > 3c 18 00 0f 85 8c 05 00 00 49 8d 7c 24 08 4d 8b 34 24 48 89
> > RIP [< inline >] __preempt_count_sub
> > kernel/arch/x86/include/asm/preempt.h:74
> > RIP [< inline >] rcu_read_unlock_sched_notrace
> > kernel/include/linux/rcupdate.h:1020
> > RIP [< inline >] trace_irq_handler_entry
> > kernel/include/trace/events/irq.h:52
> > RIP [] handle_irq_event_percpu+0xcd/0x6d0
> > kernel/kernel/irq/handle.c:144
> > RSP
> > ---[ end trace 0984a7cc502bc978 ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Fatal exception in interrupt
> >
> >
> > I cannot produce the bug, but by taking a look at the
> > code(irq/handle.c line176), it may
> > casue a null pointer deref:
> >
> > http://lxr.free-electrons.com/source/kernel/irq/handle.c#L176
> >
> > 141 do {
> > 142 irqreturn_t res;
> > 143
> > 144 trace_irq_handler_entry(irq, action);
> > 145 res = action->handler(irq, action->dev_id);
> > 146 trace_irq_handler_exit(irq, action, res);
> > 147
> > 148 if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF
> > enabled interrupts\n",
> > 149 irq, action->handler))
> > 150 local_irq_disable();
> > 151
> > 152 switch (res) {
> > 153 case IRQ_WAKE_THREAD:
> > 154 /*
> > 155 * Catch drivers which return WAKE_THREAD
> > but
> > 156 * did not set up a thread function
> > 157 */
> > 158 if (unlikely(!action->thread_fn)) {
> > 159 warn_no_thread(irq, action);
> > 160 break;
> > 161 }
> > 162
> > 163 __irq_wake_thread(desc, action);
> > 164
> > 165 /* Fall through to add to randomness */
> > 166 case IRQ_HANDLED:
> > 167 flags |= action->flags;
> > 168 break;
> > 169
> > 170
[PATCH 0/2] usb: dwc3: gadget: Fix erratic interrupts and delayed enumeration
Hi, The existing workaround (for STAR#9000525659) of forcing DEVSPD to SUPER_SPEED for HIGH_SPEED ports is causing another side effect which causes erratic interrupts and delayed gadget enumeration of upto 2 seconds. Work around the run/stop issue by detecting if it happened using debug LTSSM state and issuing soft reset to the device controller when changing RUN_STOP from 0 to 1. We apply the workaround only if PRTCAP is DEVICE mode as we don't yet support this workaround in OTG mode. Use USB RESET event as exit condition for workaround. cheers, -roger Roger Quadros (2): usb: dwc3: core: Introduce dwc3_device_reinit() usb: dwc3: gadget: usb: dwc3: run/stop metastability workaround drivers/usb/dwc3/core.c | 142 + drivers/usb/dwc3/core.h | 4 ++ drivers/usb/dwc3/gadget.c | 175 +- 3 files changed, 246 insertions(+), 75 deletions(-) -- 2.5.0
Re: [PATCH 1/2] pinctrl: sh-pfc: enable to indicate GPSR/IPSR/MOD_SEL for debug
Hi Morimoto-san,
Thank you for the patch.
On Wednesday 16 March 2016 00:47:48 Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> Current sh_pfc can't indicate GPSR/IPSR/MOD_SEL name for debug.
> Of course we can get it from indicated register address, but it
> is not convenient. This patch enables to indicate these.
>
> Signed-off-by: Kuninori Morimoto
> ---
> drivers/pinctrl/sh-pfc/core.c | 3 ++-
> drivers/pinctrl/sh-pfc/sh_pfc.h | 9 ++---
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
> index 0c2d14c..c59f858 100644
> --- a/drivers/pinctrl/sh-pfc/core.c
> +++ b/drivers/pinctrl/sh-pfc/core.c
> @@ -204,8 +204,9 @@ static void sh_pfc_write_config_reg(struct sh_pfc *pfc,
>
> sh_pfc_config_reg_helper(pfc, crp, field, &mapped_reg, &mask, &pos);
>
> - dev_dbg(pfc->dev, "write_reg addr = %x, value = 0x%x, field = %u, "
> + dev_dbg(pfc->dev, "%s: write_reg addr = %x, value = 0x%x, field = %u, "
> "r_width = %u, f_width = %u\n",
> + crp->name,
> crp->reg, value, field, crp->reg_width, crp->field_width);
>
> mask = ~(mask << pos);
> diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h
> b/drivers/pinctrl/sh-pfc/sh_pfc.h index a490834..2b593fc 100644
> --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> @@ -94,6 +94,7 @@ struct pinmux_func {
> };
>
> struct pinmux_cfg_reg {
> + const char *name;
This will increase the kernel size, I would remove the name field when
compiling the kernel in non-debug mode. You could use CONFIG_DYNAMIC_DEBUG or
CONFIG_DEBUG_PINCTRL.
> u32 reg;
> u8 reg_width, field_width;
> const u16 *enum_ids;
> @@ -110,7 +111,8 @@ struct pinmux_cfg_reg {
> * (from left to right, i.e. MSB to LSB), 2^f_width enum IDs must be
> specified, * one for each possible combination of the register field bit
> values. */
> -#define PINMUX_CFG_REG(name, r, r_width, f_width) \
> +#define PINMUX_CFG_REG(_name, r, r_width, f_width) \
> + .name = _name, \
> .reg = r, .reg_width = r_width, .field_width = f_width, \
> .enum_ids = (const u16 [(r_width / f_width) * (1 << f_width)])
>
> @@ -125,7 +127,8 @@ struct pinmux_cfg_reg {
> * (from left to right, i.e. MSB to LSB), 2^var_fwi enum IDs must be
> specified, * one for each possible combination of the register field bit
> values. */
> -#define PINMUX_CFG_REG_VAR(name, r, r_width, var_fw0, var_fwn...) \
> +#define PINMUX_CFG_REG_VAR(_name, r, r_width, var_fw0, var_fwn...) \
> + .name = _name, \
> .reg = r, .reg_width = r_width, \
> .var_field_width = (const u8 [r_width]) \
> { var_fw0, var_fwn, 0 }, \
> @@ -465,7 +468,7 @@ struct sh_pfc_soc_info {
> */
> #define PORTCR(nr, reg)
> \
> { \
> - PINMUX_CFG_REG_VAR("PORT" nr "CR", reg, 8, 2, 2, 1, 3) {\
> + PINMUX_CFG_REG_VAR("PORT" #nr "CR", reg, 8, 2, 2, 1, 3) {\
> /* PULMD[1:0], handled by .set_bias() */\
> 0, 0, 0, 0, \
> /* IE and OE */ \
--
Regards,
Laurent Pinchart
Re: next-20160314 - crash in i2c_dev_init/bus_register_notifier at boot
On Thu, 17 Mar 2016 21:52:25 +0100, Wolfram Sang said: > Can you try a newer -next or apply this patch on top? > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/drivers/i2c?id=3Db980a26d02d1f54be3134222304fcd27ea33 > > I think this should solve it. Confirming that issue is fixed in next-20160317. Now on to fix the *next* problem :) pgp3adPaRnEax.pgp Description: PGP signature
Re: [GIT PULL v2 rcu/next] memory-barriers.txt commits for 4.6
On Wed, Mar 16, 2016 at 08:26:25AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > [...] In fact, in view of the no-diagrams and no-quizzes restrictions, I > > don't > > see a way to improve on comments in the source code. [...] > > So I don't think there's such a hard restriction: AFAICS Linus's main problem > was > the dual .html and .htmlx file for what essentially are the same documents. > > If you can solve that with a single (.html?) file then I think it's all OK. Very good! I do have a prototype in -rcu on branch rcu/dev that uses Linus's second suggestion, namely blanking out the answer so that the user mouse-selects it to see it. I am now chasing down the w3c validator complaints. Of course, there will likely be some review feedback. ;-) > > The memory-barriers.txt commits are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > > for-mingo > > > > for you to fetch changes up to 65f95ff2e41a32dd190cf28e3abb029625eef968: > > > > documentation: Clarify compiler store-fusion example (2016-03-14 15:52:19 > > -0700) > > > > > > Paul E. McKenney (7): > > documentation: Fix control dependency and identical stores > > documentation: Fix memory-barriers.txt section references > > documentation: Remove obsolete reference to RCU-protected indexes > > documentation: Subsequent writes ordered by rcu_dereference() > > documentation: Distinguish between local and global transitivity > > documentation: Add alternative release-acquire outcome > > documentation: Transitivity is not cumulativity > > > > SeongJae Park (1): > > documentation: Clarify compiler store-fusion example > > > > Documentation/memory-barriers.txt | 141 > > +++--- > > 1 file changed, 116 insertions(+), 25 deletions(-) > > Pulled into tip:locking/urgent, thanks a lot Paul! Thank you, Ingo! I will likely have one more locktorture RFC pull request, if that works for you. This fixes a bug and has very few users, so very low risk. Thanx, Paul
[PATCH v2 1/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA
1.For coherent DMA
In swiotlb_alloc_coherent, it directly return vaddr on success, and
pass vaddr to free_pages on failure. So, we can directly transparent pass
vaddr from __dma_free to swiotlb_free_coherent.
2.Keep no change for non-coherent DMA.
Signed-off-by: Zhen Lei
---
arch/arm64/mm/dma-mapping.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a6e757c..ceb2018 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -187,16 +187,22 @@ static void __dma_free(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
struct dma_attrs *attrs)
{
- void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
-
size = PAGE_ALIGN(size);
if (!is_device_dma_coherent(dev)) {
if (__free_from_pool(vaddr, size))
return;
vunmap(vaddr);
+
+ /*
+* For non-coherent DMA, the vaddr is not part of the linear
+* mapping as it has been remapped by __dma_alloc() via
+* dma_common_contiguous_remap(), hence for swiotlb freeing we
+* need the actual linear map address.
+*/
+ vaddr = phys_to_virt(dma_to_phys(dev, dma_handle));
}
- __dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
+ __dma_free_coherent(dev, size, vaddr, dma_handle, attrs);
}
static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
--
2.5.0
Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single
On Thu, Mar 17, 2016 at 06:02:15PM -0400, Sinan Kaya wrote: > Getting ready to remove dma_to_phys API. Drivers should not be > using this API for DMA operations. Instead, they should go > through the dma_map or dma_alloc APIs. > > Signed-off-by: Sinan Kaya > --- > drivers/crypto/marvell/cesa.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c > index c0656e7..52ddfa4 100644 > --- a/drivers/crypto/marvell/cesa.c > +++ b/drivers/crypto/marvell/cesa.c > @@ -350,8 +350,8 @@ static int mv_cesa_get_sram(struct platform_device *pdev, > int idx) > if (IS_ERR(engine->sram)) > return PTR_ERR(engine->sram); > > - engine->sram_dma = phys_to_dma(cesa->dev, > -(phys_addr_t)res->start); > + engine->sram_dma = dma_map_single(cesa->dev, engine->sram, > + DMA_TO_DEVICE); Documentation/DMA-API.txt dma_addr_t dma_map_single(struct device *dev, void *cpu_addr, size_t size, enum dma_data_direction direction) Notes: Not all memory regions in a machine can be mapped by this API. Further, contiguous kernel virtual space may not be contiguous as physical memory. Since this API does not provide any scatter/gather capability, it will fail if the user tries to map a non-physically contiguous piece of memory. For this reason, memory to be mapped by this API should be obtained from sources which guarantee it to be physically contiguous (like kmalloc). Specifically, ioremapped memory will *not* work as you expect with dma_map_single(). -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH] staging: rtl8192e: fixed coding style issues
On Thu, Mar 17, 2016 at 04:55:37PM +, Yousof El-Sayed wrote: > Signed-off-by: Yousof El-Sayed I can't take patches without any changelog entry, sorry. And be specific about what and why you are changing anything, "coding style issues" is very vague. thanks, greg k-h
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()
On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
> > Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
> > timeout, there's no use for having this function anymore. Good riddens.
> >
> > Signed-off-by: Lyude
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 79
> > -
> > 1 file changed, 22 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index cdc2c15..fb4cbbe5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct
> > intel_encoder *encoder)
> > }
> >
> > /*
> > - * Native read with retry for link status and receiver capability reads for
> > - * cases where the sink may still be asleep.
> > - *
> > - * Sinks are *supposed* to come up within 1ms from an off state, but we're
> > also
> > - * supposed to retry 3 times per the spec.
> > - */
> > -static ssize_t
> > -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> > - void *buffer, size_t size)
> > -{
> > - ssize_t ret;
> > - int i;
> > -
> > - /*
> > -* Sometime we just get the same incorrect byte repeated
> > -* over the entire buffer. Doing just one throw away read
> > -* initially seems to "solve" it.
> > -*/
> > - drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
>
> NAK
>
> If people keep intentionally breaking my shit I'm going to become
> really grumpy soon.
Oh, and just in case someone wants to come up with a better kludge,
I just spent a few minutes analyzing the behavior of this crappy
monitor a.
What happens is that when the monitor is fully powered up (LED is blue)
things are fine. After the monitor goes to sleep (LED turns orange)
the first DPCD read will produce garbage. Further DPCD reads are fine,
even if I wait a significant amount of time between the reads, as long
as the monitor didn't do a power on->off cycle in between. So it looks
like it's always just the first read after power down that gets
corrupted.
Now I think I'll go and test how writes behave, assuming I can find a
decently sized chunk of DPCD address space I can write. And maybe I
should also try i2c-over-aux...
>
> > -
> > - for (i = 0; i < 3; i++) {
> > - ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> > - if (ret == size)
> > - return ret;
> > - msleep(1);
> > - }
> > -
> > - return ret;
> > -}
> > -
> > -/*
> > * Fetch AUX CH registers 0x202 - 0x207 which contain
> > * link status information
> > */
> > bool
> > intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> > link_status[DP_LINK_STATUS_SIZE])
> > {
> > - return intel_dp_dpcd_read_wake(&intel_dp->aux,
> > - DP_LANE0_1_STATUS,
> > - link_status,
> > - DP_LINK_STATUS_SIZE) ==
> > DP_LINK_STATUS_SIZE;
> > + return drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS, link_status,
> > + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> > }
> >
> > /* These are source-specific values. */
> > @@ -3865,8 +3832,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > uint8_t rev;
> >
> > - if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
> > - sizeof(intel_dp->dpcd)) < 0)
> > + if (drm_dp_dpcd_read(&intel_dp->aux, 0x000, intel_dp->dpcd,
> > +sizeof(intel_dp->dpcd)) < 0)
> > return false; /* aux transfer failed */
> >
> > DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> > intel_dp->dpcd);
> > @@ -3877,9 +3844,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > /* Check if the panel supports PSR */
> > memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
> > if (is_edp(intel_dp)) {
> > - intel_dp_dpcd_read_wake(&intel_dp->aux, DP_PSR_SUPPORT,
> > - intel_dp->psr_dpcd,
> > - sizeof(intel_dp->psr_dpcd));
> > + drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT,
> > +intel_dp->psr_dpcd,
> > +sizeof(intel_dp->psr_dpcd));
> > if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > dev_priv->psr.sink_support = true;
> > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > @@ -3890,9 +3857,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > uint8_t frame_sync_cap;
> >
> > dev_priv->psr.sink_support = true;
> > - intel_dp_dpcd_read_wake(&intel_dp->aux,
> > - DP_SINK_DEVICE_AUX_F
Re: [alsa-devel] [PATCH] ASoC: dapm: Do not traverse widget hooks to snd-soc-dummy
On Thursday 17 March 2016 09:12 PM, Mark Brown wrote: On Thu, Mar 17, 2016 at 01:37:16PM +0100, Lars-Peter Clausen wrote: I'd say as a quick fix for stable check that card is not NULL in dapm_widget_show_component(). And as a longterm fix get rid of dapm_widget file. Nobody should hopefully use it anymore with debugfs being available as the far better alternative. Getting rid of the file is definitely not a bad idea but I'd still like to see us make the dummy component more consistent with other components in order to minimise the chances that we'll run into other special cases. Right, I do see that we need dummy component to be fixed up. Today if we use dummy twice in a card it refers to same instance whereas IMO it should create separate instances. I will try something on these lines in next month or so... -- ~Vinod
Re: [PATCH v2 2/3] Run dump pipe in container's namespace
Hi Zhao, [auto build test ERROR on tip/sched/core] [also build test ERROR on v4.5 next-20160318] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Zhao-Lei/Make-core_pattern-support-namespace/20160318-205506 config: um-x86_64_defconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=um SUBARCH=x86_64 All errors (new ones prefixed by >>): kernel/time/Kconfig:155:warning: range is invalid In file included from arch/x86/um/asm/elf.h:9:0, from include/linux/elf.h:4, from arch/x86/um/shared/sysdep/kernel-offsets.h:3, from arch/um/kernel/asm-offsets.c:1: >> arch/um/include/shared/skas/skas.h:13:12: error: conflicting types for >> 'user_thread' extern int user_thread(unsigned long stack, int flags); ^ In file included from arch/x86/um/shared/sysdep/kernel-offsets.h:2:0, from arch/um/kernel/asm-offsets.c:1: include/linux/sched.h:2652:14: note: previous declaration of 'user_thread' was here extern pid_t user_thread(int (*fn)(void *), void *arg, unsigned long flags); ^ make[2]: *** [arch/um/kernel/asm-offsets.s] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [prepare0] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 vim +/user_thread +13 arch/um/include/shared/skas/skas.h ^1da177e4c arch/um/kernel/skas/include/skas.h Linus Torvalds 2005-04-16 7 #define __SKAS_H ^1da177e4c arch/um/kernel/skas/include/skas.h Linus Torvalds 2005-04-16 8 37185b3324 arch/um/include/shared/skas/skas.h Al Viro2012-10-08 9 #include ^1da177e4c arch/um/kernel/skas/include/skas.h Linus Torvalds 2005-04-16 10 ^1da177e4c arch/um/kernel/skas/include/skas.h Linus Torvalds 2005-04-16 11 extern int userspace_pid[]; ^1da177e4c arch/um/kernel/skas/include/skas.h Linus Torvalds 2005-04-16 12 ^1da177e4c arch/um/kernel/skas/include/skas.h Linus Torvalds 2005-04-16 @13 extern int user_thread(unsigned long stack, int flags); 3c91735099 arch/um/include/skas/skas.hJeff Dike 2006-09-27 14 extern void new_thread_handler(void); 77bf440031 arch/um/include/skas/skas.hJeff Dike 2007-10-16 15 extern void handle_syscall(struct uml_pt_regs *regs); ^1da177e4c arch/um/kernel/skas/include/skas.h Linus Torvalds 2005-04-16 16 extern long execute_syscall_skas(void *r); :: The code at line 13 was first introduced by commit :: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2 :: TO: Linus Torvalds :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[PATCH] drm/fb_cma_helper: Implement fb_mmap callback
In the absence of an fb_mmap callback, the fbdev code falls back to a
naive implementation which relies upon the DMA address being the same
as the physical address, and the buffer being physically contiguous
from there. Whilst this often holds for standard CMA allocations via
the platform's regular DMA ops, if the allocation is provided by an
IOMMU then such assumptions can fall apart spectacularly.
To resolve this, reroute the fb_mmap call to the appropriate DMA API
implementation, as per the other cma_helper calls.
Signed-off-by: Robin Murphy
---
Hi dri-devel,
This is an empirical fix for something I tickled via the newly-added
ARM HDLCD driver on a Juno platform - I have no idea whatsoever about
how "proper" it is in terms of the DRM infrastructure, so feel free to
treat this as a bug report rather than an actual patch if appropriate ;)
drivers/gpu/drm/drm_fb_cma_helper.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index bb88e3d..117d7ea 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
struct drm_fb_cma {
@@ -221,6 +222,12 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg)
EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
#endif
+static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ return dma_mmap_writecombine(info->device, vma, info->screen_base,
+info->fix.smem_start, info->fix.smem_len);
+}
+
static struct fb_ops drm_fbdev_cma_ops = {
.owner = THIS_MODULE,
.fb_fillrect= drm_fb_helper_sys_fillrect,
@@ -231,6 +238,7 @@ static struct fb_ops drm_fbdev_cma_ops = {
.fb_blank = drm_fb_helper_blank,
.fb_pan_display = drm_fb_helper_pan_display,
.fb_setcmap = drm_fb_helper_setcmap,
+ .fb_mmap= drm_fb_cma_mmap,
};
static int drm_fbdev_cma_create(struct drm_fb_helper *helper,
--
2.7.3.dirty
Re: [RFT] iommu/amd: use subsys_initcall() on amdv2 iommu
On Wed, Mar 16, 2016 at 05:57:47PM +0100, Luis R. Rodriguez wrote: > I'm afraid I am not sure where that hack is, can someone construct a patch to > revert that so this is a proper RFT series ? Oded mentioned 1bacc894c227fad8a727eb99728df708eba57654, which reverts fine here on v4.5. Joerg
[PATCH v2 08/11] ARM: dt: da850: Add usb phy node
Add a node for the new usb phy driver.
Signed-off-by: David Lechner
---
v2 changes: This is new patch in v2.
arch/arm/boot/dts/da850.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 591660d..06f36cd 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -324,6 +324,12 @@
>;
status = "disabled";
};
+ usbphy: usbphy@1c14184 {
+ compatible = "ti,da830-usbphy";
+ #phy-cells = <1>;
+ reg = <0x14184 4>;
+ status = "disabled";
+ };
gpio: gpio@1e26000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
1.9.1
Re: [PATCH v4 6/7] cpufreq: Support for fast frequency switching
On Wed, Mar 16, 2016 at 03:52:28PM +0100, Rafael J. Wysocki wrote:
> +/**
> + * cpufreq_enable_fast_switch - Enable fast frequency switching for policy.
> + * @policy: cpufreq policy to enable fast frequency switching for.
> + *
> + * Try to enable fast frequency switching for @policy.
> + *
> + * The attempt will fail if there is at least one transition notifier
> registered
> + * at this point, as fast frequency switching is quite fundamentally at odds
> + * with transition notifiers. Thus if successful, it will make registration
> of
> + * transition notifiers fail going forward.
> + *
> + * Call under policy->rwsem.
Nobody reads a comment..
> + */
> +void cpufreq_enable_fast_switch(struct cpufreq_policy *policy)
> +{
lockdep_assert_held(&policy->rwsem);
While everybody complains when there's a big nasty splat in their dmesg
;-)
> + mutex_lock(&cpufreq_fast_switch_lock);
> + if (policy->fast_switch_possible && cpufreq_fast_switch_count >= 0) {
> + cpufreq_fast_switch_count++;
> + policy->fast_switch_enabled = true;
> + } else {
> + pr_warn("cpufreq: CPU%u: Fast freqnency switching not
> enabled\n",
> + policy->cpu);
> + }
> + mutex_unlock(&cpufreq_fast_switch_lock);
> +}
Re: [PATCH 0/8 v4] bcm2835 DMA slave support
On 16.03.2016 20:24, Eric Anholt wrote: Here's the series for DMA slave and memcpy support for 2835, with the DT changes to enable the remaining channels dropped out while that goes through review. I had to do some minor conflict resolution, but it was pretty mechanical, and I tested again with dmatest on the last patch. Martin Sperl (8): dmaengine: bcm2835: set residue_granularity field dmaengine: bcm2835: remove unnecessary masking of dma channels dmaengine: bcm2835: add additional defines for DMA-registers dmaengine: bcm2835: move cyclic member from bcm2835_chan into bcm2835_desc dmaengine: bcm2835: move controlblock chain generation into separate method dmaengine: bcm2835: limit max length based on channel type dmaengine: bcm2835: add slave_sg support to bcm2835-dma dmaengine: bcm2835: add dma_memcopy support to bcm2835-dma I have successfully tested this modified patch-series playing BigBuckBunny on: * fb-tft device (fb_st7735r) - via spi-bcm2835 using slave_sg dma * I2S Hifiberry DAC (snd_soc_hifiberry_dac) - via bcm2835-i2s using cyclic dma Required additional patches to make this work (especially I2S support, which is non-working since ): * the clock-patchsets: * [PATCH 0/6] clk: bcm2835: fixes clk-bcm2835 driver issues (most are reviewed by Eric) * [PATCH 0/3] reorganize clock initialization and add PCM clock (no reviewed/acked so far) * i2s patchset to enable the use of the clock framework * [PATCH V2 0/3] ASOC: bcm2835: move bcm2835-i2s to use clock framework (if I remember correctly Mark Brown has merged the driver patches) * out of tree drivers for Hifiberry DAC (I guess I should upstream those...) Tested-by: Martin Sperl
Re: [PATCH 1/3] ARM: at91: use chipid device for soc detection
On 18/03/2016 at 08:21:19 +0100, Ludovic Desroches wrote :
> So far, the CIDR and EXID registers were in the DBGU interface. This device
> has disappeared with the SAMA5D2 family. These registers are exposed
> through a new device called chipid.
>
> Signed-off-by: Ludovic Desroches
> [nicolas.fe...@atmel.com: remove useless warnings]
Acked-by: Alexandre Belloni
> ---
> .../devicetree/bindings/arm/atmel-at91.txt | 4 ++
> arch/arm/mach-at91/soc.c | 81
> +-
> 2 files changed, 67 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt
> b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> index 7fd64ec..0b1fcbf 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> @@ -41,6 +41,10 @@ compatible: must be one of:
> - "atmel,sama5d43"
> - "atmel,sama5d44"
>
> +Chipid required properties:
> +- compatible: Should be "atmel,sama5d2-chipid"
> +- reg : Should contain registers location and length
> +
> PIT Timer required properties:
> - compatible: Should be "atmel,at91sam9260-pit"
> - reg: Should contain registers location and length
> diff --git a/arch/arm/mach-at91/soc.c b/arch/arm/mach-at91/soc.c
> index 54343ff..034d563 100644
> --- a/arch/arm/mach-at91/soc.c
> +++ b/arch/arm/mach-at91/soc.c
> @@ -22,48 +22,93 @@
> #include "soc.h"
>
> #define AT91_DBGU_CIDR 0x40
> -#define AT91_DBGU_CIDR_VERSION(x)((x) & 0x1f)
> -#define AT91_DBGU_CIDR_EXT BIT(31)
> -#define AT91_DBGU_CIDR_MATCH_MASK0x7fe0
> #define AT91_DBGU_EXID 0x44
> +#define AT91_CHIPID_CIDR 0x00
> +#define AT91_CHIPID_EXID 0x04
> +#define AT91_CIDR_VERSION(x) ((x) & 0x1f)
> +#define AT91_CIDR_EXTBIT(31)
> +#define AT91_CIDR_MATCH_MASK 0x7fe0
>
> -struct soc_device * __init at91_soc_init(const struct at91_soc *socs)
> +int __init at91_get_cidr_exid_from_dbgu(u32 *cidr, u32 *exid)
> {
> - struct soc_device_attribute *soc_dev_attr;
> - const struct at91_soc *soc;
> - struct soc_device *soc_dev;
> struct device_node *np;
> void __iomem *regs;
> - u32 cidr, exid;
>
> np = of_find_compatible_node(NULL, NULL, "atmel,at91rm9200-dbgu");
> if (!np)
> np = of_find_compatible_node(NULL, NULL,
>"atmel,at91sam9260-dbgu");
> + if (!np)
> + return -ENODEV;
>
> - if (!np) {
> - pr_warn("Could not find DBGU node");
> - return NULL;
> + regs = of_iomap(np, 0);
> + of_node_put(np);
> +
> + if (!regs) {
> + pr_warn("Could not map DBGU iomem range");
> + return -ENXIO;
> }
>
> + *cidr = readl(regs + AT91_DBGU_CIDR);
> + *exid = readl(regs + AT91_DBGU_EXID);
> +
> + iounmap(regs);
> +
> + return 0;
> +}
> +
> +int __init at91_get_cidr_exid_from_chipid(u32 *cidr, u32 *exid)
> +{
> + struct device_node *np;
> + void __iomem *regs;
> +
> + np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-chipid");
> + if (!np)
> + return -ENODEV;
> +
> regs = of_iomap(np, 0);
> of_node_put(np);
>
> if (!regs) {
> pr_warn("Could not map DBGU iomem range");
> - return NULL;
> + return -ENXIO;
> }
>
> - cidr = readl(regs + AT91_DBGU_CIDR);
> - exid = readl(regs + AT91_DBGU_EXID);
> + *cidr = readl(regs + AT91_CHIPID_CIDR);
> + *exid = readl(regs + AT91_CHIPID_EXID);
>
> iounmap(regs);
>
> + return 0;
> +}
> +
> +struct soc_device * __init at91_soc_init(const struct at91_soc *socs)
> +{
> + struct soc_device_attribute *soc_dev_attr;
> + const struct at91_soc *soc;
> + struct soc_device *soc_dev;
> + u32 cidr, exid;
> + int ret;
> +
> + /*
> + * With SAMA5D2 and later SoCs, CIDR and EXID registers are no more
> + * in the dbgu device but in the chipid device whose purpose is only
> + * to expose these two registers.
> + */
> + ret = at91_get_cidr_exid_from_dbgu(&cidr, &exid);
> + if (ret)
> + ret = at91_get_cidr_exid_from_chipid(&cidr, &exid);
> + if (ret) {
> + if (ret == -ENODEV)
> + pr_warn("Could not find identification node");
> + return NULL;
> + }
> +
> for (soc = socs; soc->name; soc++) {
> - if (soc->cidr_match != (cidr & AT91_DBGU_CIDR_MATCH_MASK))
> + if (soc->cidr_match != (cidr & AT91_CIDR_MATCH_MASK))
> continue;
>
> - if (!(cidr & AT91_DBGU_CIDR_EXT) || soc->exid_match == exid)
> + if (!(cidr & AT91_CIDR_EXT) || soc->exid_match == exid)
> break;
> }
>
> @@ -79,7 +124,7 @@ struct soc_device *
Re: [PATCH v4 3/7] usb: mux: add common code for Intel dual role port mux
On 03/17/2016 03:27 PM, Chanwoo Choi wrote: > Hi Lu, > > On 2016년 03월 17일 16:16, Lu Baolu wrote: >> Hi Chanwoo, >> >> On 03/17/2016 02:07 PM, Chanwoo Choi wrote: >>> Hi Lu, >>> >>> To handle extcon (external connector), I implemented the unique id >>> for each external connector on patch[1] instead of using the ambiguous >>> string type. >>> [1] 2a9de9c0f08d6 (extcon: Use the unique id for external connector instead >>> of string) >>> >>> So I recommend that you should use the unique id (ex. EXTCON_USB, >>> EXTCON_USB_HOST) >>> with extcon_register_notifier(), extcon_get_cable_state_() and >>> extcon_set_cable_state_(). >>> >>> extcon_register_interest() is deprecated-> extcon_register_notifier() >>> extcon_get_cable_state() is deprecated -> extcon_get_cable_state_() >>> extcon_set_cable_state() is deprecated -> extcon_set_cable_state_() >> Sure. I will use the new interfaces with a refreshed patch serial later. >> >>> >>> You can refer to usage for new function with unique id on patch[2] >>> [2] 5960387a2fb83 (usb: dwc3: omap: Replace deprecated API of extcon) >> Thanks. That's helpful. >> >> By the way, is extcon_get_extcon_dev() still available? > Yes. > This function find the extcon device with string name. > > If extcon client driver use the platform_data to get the name of extcon > device, > the extcon client driver should use the extcon_get_extcon_dev() funtcion. > Because we can not pass the point(instance) of extcon device through > platform_data. > > But, if extcon client driver support the devicetree, > we better to use the extcon_get_edev_by_phandle(). That's clear. Thank you! Best regards, Baolu > > Best Regards, > Chanwoo Choi > >>> I'm sorry for late reply. I add the some comment on below. >> Never mind. Thank you for reminding me. >> >> Best regards, >> Baolu >> >>> >>> On 2016년 03월 17일 14:46, Lu Baolu wrote: Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between device controller and host controller. A usb port mux could be abstracted as the following elements: 1) mux state: HOST or PERIPHERAL; 2) an extcon cable which triggers the change of mux state between HOST and PERIPHERAL; 3) The required action to do the real port switch. This patch adds the common code to handle usb port mux. With this common code, the individual mux driver, which always is platform dependent, could focus on the real operation of mux switch. Signed-off-by: Lu Baolu Reviewed-by: Heikki Krogerus Reviewed-by: Felipe Balbi --- Documentation/ABI/testing/sysfs-bus-platform | 15 +++ MAINTAINERS | 7 ++ drivers/usb/Kconfig | 2 + drivers/usb/Makefile | 1 + drivers/usb/mux/Kconfig | 12 ++ drivers/usb/mux/Makefile | 4 + drivers/usb/mux/intel-mux.c | 180 +++ include/linux/usb/intel-mux.h| 43 +++ 8 files changed, 264 insertions(+) create mode 100644 drivers/usb/mux/Kconfig create mode 100644 drivers/usb/mux/Makefile create mode 100644 drivers/usb/mux/intel-mux.c create mode 100644 include/linux/usb/intel-mux.h diff --git a/Documentation/ABI/testing/sysfs-bus-platform b/Documentation/ABI/testing/sysfs-bus-platform index 5172a61..23bf76e 100644 --- a/Documentation/ABI/testing/sysfs-bus-platform +++ b/Documentation/ABI/testing/sysfs-bus-platform @@ -18,3 +18,18 @@ Description: devices to opt-out of driver binding using a driver_override name such as "none". Only a single driver may be specified in the override, there is no support for parsing delimiters. + +What: /sys/bus/platform/devices/.../port_mux +Date: Febuary 2016 +Contact: Lu Baolu +Description: + In some platforms, a single USB port is shared between a USB host + controller and a device controller. A USB mux driver is needed to + handle the port mux. port_mux attribute shows and stores the mux + state. + For read: + 'peripheral' - mux switched to PERIPHERAL controller; + 'host' - mux switched to HOST controller. + For write: + 'peripheral' - mux will be switched to PERIPHERAL controller; + 'host' - mux will be switched to HOST controller. diff --git a/MAINTAINERS b/MAINTAINERS index da3e4d8..0dbee11 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11399,6 +11399,13 @@ T:git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git S:Maintained F:drivers/usb/phy/ +USB PORT MUX DRIVER +
[PATCH v6 14/17] XEN: EFI: Move x86 specific codes to architecture directory
From: Shannon Zhao
Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
---
arch/x86/xen/efi.c| 112
drivers/xen/efi.c | 174 ++
include/xen/xen-ops.h | 30 ++---
3 files changed, 168 insertions(+), 148 deletions(-)
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
#include
#include
+#include
#include
+#include
#include
#include
+#include
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+ .hdr = {
+ .signature = EFI_SYSTEM_TABLE_SIGNATURE,
+ .revision = 0, /* Initialized later. */
+ .headersize = 0, /* Ignored by Linux Kernel. */
+ .crc32 = 0, /* Ignored by Linux Kernel. */
+ .reserved = 0
+ },
+ .fw_vendor = EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+ .fw_revision= 0, /* Initialized later. */
+ .con_in_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_in = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .con_out= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr_handle = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .stderr = EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+ .runtime= (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .boottime = (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+ /* Not used under Xen. */
+ .nr_tables = 0, /* Initialized later. */
+ .tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+ .systab = NULL, /* Initialized later. */
+ .runtime_version = 0,/* Initialized later. */
+ .mps = EFI_INVALID_TABLE_ADDR,
+ .acpi = EFI_INVALID_TABLE_ADDR,
+ .acpi20 = EFI_INVALID_TABLE_ADDR,
+ .smbios = EFI_INVALID_TABLE_ADDR,
+ .smbios3 = EFI_INVALID_TABLE_ADDR,
+ .sal_systab = EFI_INVALID_TABLE_ADDR,
+ .boot_info= EFI_INVALID_TABLE_ADDR,
+ .hcdp = EFI_INVALID_TABLE_ADDR,
+ .uga = EFI_INVALID_TABLE_ADDR,
+ .uv_systab= EFI_INVALID_TABLE_ADDR,
+ .fw_vendor= EFI_INVALID_TABLE_ADDR,
+ .runtime = EFI_INVALID_TABLE_ADDR,
+ .config_table = EFI_INVALID_TABLE_ADDR,
+ .get_time = xen_efi_get_time,
+ .set_time = xen_efi_set_time,
+ .get_wakeup_time = xen_efi_get_wakeup_time,
+ .set_wakeup_time = xen_efi_set_wakeup_time,
+ .get_variable = xen_efi_get_variable,
+ .get_next_variable= xen_efi_get_next_variable,
+ .set_variable = xen_efi_set_variable,
+ .query_variable_info = xen_efi_query_variable_info,
+ .update_capsule = xen_efi_update_capsule,
+ .query_capsule_caps = xen_efi_query_capsule_caps,
+ .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+ .reset_system = NULL, /* Functionality provided by Xen. */
+ .set_virtual_address_map = NULL, /* Not used under Xen. */
+ .memmap = NULL, /* Not used under Xen. */
+ .flags= 0 /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+ struct xen_platform_op op = {
+ .cmd = XENPF_firmware_info,
+ .u.firmware_info = {
+ .type = XEN_FW_EFI_INFO,
+ .index = XEN_FW_EFI_CONFIG_TABLE
+ }
+ };
+ union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+ if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
+ return NULL;
+
+ /* Here we know that Xen runs on EFI platform. */
+
+ efi = efi_xen;
+
+ efi_systab_xen.tables = info->cfg.addr;
+ efi_systab_xen.nr_tables = info->cfg.nent;
+
+ op.cmd = XENPF_firmware_info;
+ op.u.firmware_info.type = XEN_FW_EFI_INFO;
+ op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+ info->vendor.bufsz = sizeof(ven
Re: [PATCH v8 3/6] cpufreq: powernv: Remove cpu_to_chip_id() from hot-path
On Wed, 2016-02-03 at 01:11 +0530, Shilpasri G Bhat wrote:
> cpu_to_chip_id() does a DT walk through to find out the chip id by
> taking a contended device tree lock. This adds an unnecessary overhead
> in a hot path. So instead of calling cpu_to_chip_id() everytime cache
> the chip ids for all cores in the array 'core_to_chip_map' and use it
> in the hotpath.
>
> Reported-by: Anton Blanchard
> Signed-off-by: Shilpasri G Bhat
> Reviewed-by: Gautham R. Shenoy
> Acked-by: Viresh Kumar
> ---
> No changes from v7.
How about this instead? It removes the linear lookup and seems a lot
less complex.
Mikey
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 547890f..d63d2cb 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -52,6 +52,7 @@ static struct chip {
} *chips;
static int nr_chips;
+static DEFINE_PER_CPU(unsigned int, chip_id);
/*
* Note: The set of pstates consists of contiguous integers, the
@@ -317,9 +318,7 @@ static void powernv_cpufreq_throttle_check(void *data)
pmsr = get_pmspr(SPRN_PMSR);
- for (i = 0; i < nr_chips; i++)
- if (chips[i].id == cpu_to_chip_id(cpu))
- break;
+ i = this_cpu_read(chip_id);
/* Check for Pmax Capping */
pmsr_pmax = (s8)PMSR_MAX(pmsr);
@@ -560,6 +559,7 @@ static int init_chip_info(void)
for_each_possible_cpu(cpu) {
unsigned int id = cpu_to_chip_id(cpu);
+ per_cpu(chip_id, cpu) = nr_chips;
if (prev_chip_id != id) {
prev_chip_id = id;
chip[nr_chips++] = id;
Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU
On Tue, Mar 15, 2016 at 05:04:13PM -0400, Aaron Conole wrote:
> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it
> exists, read the advised MTU and use it.
>
> No proper error handling is provided for the case where a user changes the
> negotiated MTU. A future commit will add proper error handling. Instead, a
> warning is emitted if the guest changes the device MTU after previously
> being given advice.
I don't see this as an error. Device might at best give a hint,
user/network admin always knows best.
>
> Signed-off-by: Aaron Conole
> ---
> v2:
> * Whitespace cleanup in the last hunk
> * Code style change around the pr_warn
> * Additional test for mtu change before printing warning
>
> drivers/net/virtio_net.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 767ab11..429fe01 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -146,6 +146,7 @@ struct virtnet_info {
> virtio_net_ctrl_ack ctrl_status;
> u8 ctrl_promisc;
> u8 ctrl_allmulti;
> + bool negotiated_mtu;
> };
>
> struct padded_vnet_hdr {
> @@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
>
> static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
> {
> + struct virtnet_info *vi = netdev_priv(dev);
> if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
> return -EINVAL;
> + if ((vi->negotiated_mtu) && (dev->mtu != new_mtu))
> + pr_warn("changing mtu while the advised mtu bit exists.");
I don't really see why are we warning here. Just drop this chunk,
as well as the flag in struct virtnet_info.
> dev->mtu = new_mtu;
> return 0;
> }
> @@ -1836,6 +1840,13 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> vi->has_cvq = true;
>
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
> + vi->negotiated_mtu = true;
> + dev->mtu = virtio_cread16(vdev,
> + offsetof(struct virtio_net_config,
> +mtu));
> + }
> +
> if (vi->any_header_sg)
> dev->needed_headroom = vi->hdr_len;
>
> @@ -2019,6 +2030,7 @@ static unsigned int features[] = {
> VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
> VIRTIO_NET_F_CTRL_MAC_ADDR,
> VIRTIO_F_ANY_LAYOUT,
> + VIRTIO_NET_F_MTU,
> };
>
> static struct virtio_driver virtio_net_driver = {
> --
> 2.5.0
