Re: [PATCH v4 01/16] drm: exynos/dp: fix code style
On Thu, 2015-09-03 at 13:33 +0800, Yakir Yang wrote:
[]
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
[]
> @@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct
> exynos_dp_device *dp)
> }
> exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
> -_vector);
> + _vector);
> if (test_vector & DP_TEST_LINK_EDID_READ) {
> -exynos_dp_write_byte_to_dpcd(dp,
> -DP_TEST_EDID_CHECKSUM,
> +exynos_dp_write_byte_to_dpcd(
> +dp, DP_TEST_EDID_CHECKSUM,
> edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
> -exynos_dp_write_byte_to_dpcd(dp,
> -DP_TEST_RESPONSE,
> +exynos_dp_write_byte_to_dpcd(
> +dp, DP_TEST_RESPONSE,
> DP_TEST_EDID_CHECKSUM_WRITE);
> >>> To me, missing argument after opening parenthesis, looks worse. I would
> >>> prefer:
> >>>
> >>> exynos_dp_write_byte_to_dpcd(dp,
> >>>
> >>> Why you moved the 'dp' argument to new line?
> >> Hmm... Just like style tool indicate, no more warning after
> >> that change.
> >>
> >> For now, I would like to follow the original style, just improved
> >> some obvious style problem. :-)
> > What was the checkpatch warning that said 'dp' has to move to new line?
> > I tried this and I don't see it.
>
> checkpatch haven't remind me that put dp to new line would fix
> this warning, this just come from my experiments. And I works,
> no more warnings from checkpatch, so I toke this style.
Checkpatch isn't a great arbiter of style.
It's just a brainless tool.
Always use your instead of anything brainless.
If it were code I was writing, I'd ignore 80 columns warnings
where appropriate.
These are long function names and long macro defines, so it's
inappropriate to use 80 columns as a guiding style.
I'd write:
exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
exynos_dp_write_byte_to_dpcd(dp, DP_TEST_EDID_CHECKSUM,
edid[EDID_BLOCK_LENGTH +
EDID_CHECKSUM]);
exynos_dp_write_byte_to_dpcd(dp, DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] firmware: annotate thou shalt not request fw on init or probe
On Thu, 3 Sep 2015, Luis R. Rodriguez wrote:
> On Sat, Aug 29, 2015 at 06:18:20PM +0200, Julia Lawall wrote:
> > > +@ defines_module_init exists @
> > > +declarer name module_init;
> > > +identifier init;
> > > +@@
> > > +
> > > +module_init(init);
> > > +
> > > +@ has_probe depends on defines_module_init @
> > > +identifier drv_calls, drv_probe;
> > > +type bus_driver;
> > > +identifier probe_op =~ "(probe)";
> > > +@@
> > > +
> > > +bus_driver drv_calls = {
> > > + .probe_op = drv_probe,
> > > +};
> >
> > I'm not sure that this is enough. For example, there is the macro
> > platform_driver_probe that initializes probe fields. There is likewise
> > module_platform_driver, which is a top-level declaration that encapsulates
> > the module_init and the definition of the module_init function, which in
> > turn calls platform_driver_probe. There is also module_platform_driver,
> > which encapsulates the module_init, but not the initialization of the probe
> > field. Are you concerned with any of these cases?
>
> Yes, and also it would seem this would only capture simple one level of
> routine indirection, for instance if probe called bar() and it was within
> bar() that the driver code called a fw request call, that would not be picked
> up, correct?
By default, Coccinelle is not interprocedural. You can encode that in the
script, though.
Probably the most convenient approach would be to start with the the call,
and then work backward to the entry point. I have code to do this, if and
when it turns out to be useful.
julia
> If true then the hunt is yet even more complex. The discussion that prompted
> me
> to send this is still unfolding though [0] and it seems we may want to allow
> for these type of calls within probe in the end but in order to vet for
> drivers
> that fw is available through the direct filesystem lookup we may need help
> from
> userspace. As that discussion unfolds it will be good to keep in mind what
> effort we'd need to hunt all users down for now.
>
> [0]
> http://lkml.kernel.org/r/CAB=NE6UBRa0K7=PomJzKxsoj4GzAqkYrkp=o+ufvvu2fwm2...@mail.gmail.com
>
> Luis
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] null_blk: fix memory leak on cleanup
Den 02-09-2015 kl. 20:39 skrev Ross Zwisler: On Mon, Aug 31, 2015 at 02:17:18PM +0200, Matias Bjørling wrote: From: Matias Bjørling Driver was not freeing the memory allocated for internal nullb queues. This patch frees the memory during driver unload. You may want to consider devm_* style allocations instead. These are freed automatically on driver unload, simplifying your error paths and your unload logic as well as preventing leaks. See this patch for an example: https://lkml.org/lkml/2015/8/10/992 Thanks for looking through the patches. I'll look into it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
On 03.09.2015 14:38, Anand Moon wrote: > Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, > LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for > Odroid-XU3/XU4 board. > > Signed-off-by: Anand Moon > > --- > Changes from last version > dropped following option. > CONFIG_LEDS_CLASS_FLASH > CONFIG_TRIGGER_ONESHOT > CONFIG_TRIGGER_GPIO > fixed the From address > --- > arch/arm/configs/exynos_defconfig | 7 +++ > 1 file changed, 7 insertions(+) Reviewed-by: Krzysztof Kozlowski BTW, Javier's email is different. All you previous mails bounced. I cc-ed here the proper one. Best regards, Krzysztof > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 9504e77..aaf7aa4 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_IDMAC=y > CONFIG_MMC_DW_EXYNOS=y > +CONFIG_NEW_LEDS=y > +CONFIG_LEDS_CLASS=y > +CONFIG_LEDS_GPIO=y > +CONFIG_LEDS_PWM=y > +CONFIG_LEDS_TRIGGERS=y > +CONFIG_LEDS_TRIGGER_TIMER=y > +CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_RTC_CLASS=y > CONFIG_RTC_DRV_MAX77686=y > CONFIG_RTC_DRV_MAX77802=y > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3][v3] arm: dts: ls1021a: Add quirk for Erratum A009116
Add "snps,quirk-frame-length-adjustment" property to USB3 node for erratum A009116. This property provides value of GFLADJ_30MHZ for post silicon frame length adjustment. Signed-off-by: Nikhil Badola --- Changes for v3 : None arch/arm/boot/dts/ls1021a.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index c70bb27..50ac0d4 100644 --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -404,6 +404,7 @@ reg = <0x0 0x310 0x0 0x1>; interrupts = ; dr_mode = "host"; + snps,quirk-frame-length-adjustment = <0x20>; }; }; }; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] staging: lustre: fix whitespace errors reported by checkpatch.pl
On Thu, Sep 03, 2015 at 08:22:55AM +0300, Mike Rapoport wrote: > On Wed, Sep 02, 2015 at 05:48:46PM -0700, Greg Kroah-Hartman wrote: > > On Sat, Aug 22, 2015 at 05:17:19PM +0300, Mike Rapoport wrote: > > > Added/removed spaces and replaced '+1' with '1' in several places to > > > eliminate SPACING and POINTER_LOCATION errors reported by checkpatch.pl > > > > > > Signed-off-by: Mike Rapoport > > > > Does not apply to my tree :( > > Rebased against current staging-testing. > > > >From 4f4cdc89b94aec9a72cec4cec171d049f6f65a2a Mon Sep 17 00:00:00 2001 > From: Mike Rapoport > Date: Sat, 22 Aug 2015 17:17:19 +0300 > Subject: [PATCH] staging: lustre: fix whitespace errors reported by > checkpatch.pl Please resend it in a form that doesn't require me to hand-edit it :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv6] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for Odroid-XU3/XU4 board. Signed-off-by: Anand Moon --- Changes from last version dropped following option. CONFIG_LEDS_CLASS_FLASH CONFIG_TRIGGER_ONESHOT CONFIG_TRIGGER_GPIO fixed the From address --- arch/arm/configs/exynos_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..aaf7aa4 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3][v3] drivers: usb: dwc3: Add frame length adjustment quirk
Add adjust_frame_length_quirk for writing to fladj register
which adjusts (micro)frame length to value provided by
"snps,quirk-frame-length-adjustment" property thus avoiding
USB 2.0 devices to time-out over a longer run
Signed-off-by: Nikhil Badola
---
Changes for v3:
- removed unnecessary if(fladj) condition
- removed stray newline
drivers/usb/dwc3/core.c | 34 ++
drivers/usb/dwc3/core.h | 5 +
drivers/usb/dwc3/platform_data.h | 2 ++
3 files changed, 41 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 064123e..75a17bf 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -143,6 +143,32 @@ static int dwc3_soft_reset(struct dwc3 *dwc)
return 0;
}
+/*
+ * dwc3_frame_length_adjustment - Adjusts frame length if required
+ * @dwc3: Pointer to our controller context structure
+ * @fladj: Value of GFLADJ_30MHZ to adjust frame length
+ */
+static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
+{
+ if (dwc->revision < DWC3_REVISION_250A)
+ return;
+
+ if (fladj == 0)
+ return;
+
+ u32 reg;
+ u32 dft;
+
+ reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
+ dft = reg & DWC3_GFLADJ_30MHZ_MASK;
+ if (!dev_WARN_ONCE(dwc->dev, dft == fladj,
+ "request value same as default, ignoring\n")) {
+ reg &= ~DWC3_GFLADJ_30MHZ_MASK;
+ reg |= DWC3_GFLADJ_30MHZ_SDBND_SEL | fladj;
+ dwc3_writel(dwc->regs, DWC3_GFLADJ, reg);
+ }
+}
+
/**
* dwc3_free_one_event_buffer - Frees one event buffer
* @dwc: Pointer to our controller context structure
@@ -779,6 +805,7 @@ static int dwc3_probe(struct platform_device *pdev)
u8 lpm_nyet_threshold;
u8 tx_de_emphasis;
u8 hird_threshold;
+ u32 fladj = 0;
int ret;
@@ -886,6 +913,9 @@ static int dwc3_probe(struct platform_device *pdev)
_de_emphasis);
of_property_read_string(node, "snps,hsphy_interface",
>hsphy_interface);
+ of_property_read_u32(node,
+"snps,quirk-frame-length-adjustment",
+);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
dwc->has_lpm_erratum = pdata->has_lpm_erratum;
@@ -915,6 +945,7 @@ static int dwc3_probe(struct platform_device *pdev)
tx_de_emphasis = pdata->tx_de_emphasis;
dwc->hsphy_interface = pdata->hsphy_interface;
+ fladj = pdata->fladj_value;
}
/* default to superspeed if no maximum_speed passed */
@@ -971,6 +1002,9 @@ static int dwc3_probe(struct platform_device *pdev)
goto err1;
}
+ /* Adjust Frame Length */
+ dwc3_frame_length_adjustment(dwc, fladj);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
ret = phy_power_on(dwc->usb2_generic_phy);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0447788..9188745 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -124,6 +124,7 @@
#define DWC3_GEVNTCOUNT(n) (0xc40c + (n * 0x10))
#define DWC3_GHWPARAMS80xc600
+#define DWC3_GFLADJ0xc630
/* Device Registers */
#define DWC3_DCFG 0xc700
@@ -234,6 +235,10 @@
/* Global HWPARAMS6 Register */
#define DWC3_GHWPARAMS6_EN_FPGA(1 << 7)
+/* Global Frame Length Adjustment Register */
+#define DWC3_GFLADJ_30MHZ_SDBND_SEL(1 << 7)
+#define DWC3_GFLADJ_30MHZ_MASK 0x3f
+
/* Device Configuration Register */
#define DWC3_DCFG_DEVADDR(addr)((addr) << 3)
#define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index d3614ec..400b197 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -46,5 +46,7 @@ struct dwc3_platform_data {
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
+ u32 fladj_value;
+
const char *hsphy_interface;
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3][v3] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property
Add snps,quirk-frame-length-adjustment property which provides value for post silicon frame length adjustment Signed-off-by: Nikhil Badola --- Changes for v3 : None Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 0815eac..8c7d585 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -40,6 +40,9 @@ Optional properties: - snps,hird-threshold: HIRD threshold - snps,hsphy_interface: High-Speed PHY interface selection between "utmi" for UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE has value 3. + - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ + register for post-silicon frame length adjustment when the + fladj_30mhz_sdbnd signal is invalid or incorrect. This is usually a subnode to DWC3 glue to which it is connected. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 01/16] drm: exynos/dp: fix code style
Hi Krzysztof,
在 09/03/2015 01:08 PM, Krzysztof Kozlowski 写道:
On 03.09.2015 14:04, Yakir Yang wrote:
Hi Krzysztof,
在 09/03/2015 08:21 AM, Krzysztof Kozlowski 写道:
On 01.09.2015 14:46, Yakir Yang wrote:
After run "checkpatch.pl -f --subjective" command, I see there
are lots of alignment problem in exynos_dp driver, so let just
fix them.
Hi,
Warnings from checkpatch are not a reason for a commit. Reason for a
commit could be for example an unreadable code, violation of
coding-style leading to decrease in code maintainability or just
improving the code readability so it will be easier to review and
maintain it.
You do not make commits because some tool tells you that. We do not
listen to machines :) ... If that would be the case, the commit could be
made automatically, without human interaction. Such automated commit
could be even easily tested by the machine by comparing object files.
Especially that you enabled "subjective" rule. This is not a valid
motivation for a commit.
Please rephrase this to sensible reason and convince that change is
worth the effort.
Oh, nice, thanks for your remind. I would rephrase the commit.
- Take Romain suggest, rebase on linux-next branch
That comment seems unrelated to the commit. Please remove it.
Done,
Signed-off-by: Yakir Yang
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
avoid using some uncommon style like bellow:
- retval = exynos_dp_read_bytes_from_i2c(...
...)
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/exynos/exynos_dp_core.c | 226
drivers/gpu/drm/exynos/exynos_dp_core.h | 54
drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
3 files changed, 188 insertions(+), 198 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..266f7f7 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
/* Read Extension Flag, Number of 128-byte EDID extension
blocks */
retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-EDID_EXTENSION_FLAG,
-_block);
+ EDID_EXTENSION_FLAG,
+ _block);
if (retval)
return retval;
@@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
-retval = exynos_dp_read_bytes_from_i2c(dp,
I2C_EDID_DEVICE_ADDR,
-EDID_HEADER_PATTERN,
-EDID_BLOCK_LENGTH,
-[EDID_HEADER_PATTERN]);
+retval = exynos_dp_read_bytes_from_i2c(
+dp, I2C_EDID_DEVICE_ADDR,
+EDID_HEADER_PATTERN,
+EDID_BLOCK_LENGTH,
+[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
}
/* Read additional EDID data */
-retval = exynos_dp_read_bytes_from_i2c(dp,
-I2C_EDID_DEVICE_ADDR,
-EDID_BLOCK_LENGTH,
-EDID_BLOCK_LENGTH,
-[EDID_BLOCK_LENGTH]);
+retval = exynos_dp_read_bytes_from_i2c(
+dp, I2C_EDID_DEVICE_ADDR,
+EDID_BLOCK_LENGTH,
+EDID_BLOCK_LENGTH,
+[EDID_BLOCK_LENGTH]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct
exynos_dp_device *dp)
}
exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-_vector);
+ _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
-exynos_dp_write_byte_to_dpcd(dp,
-DP_TEST_EDID_CHECKSUM,
+exynos_dp_write_byte_to_dpcd(
+dp, DP_TEST_EDID_CHECKSUM,
edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
-exynos_dp_write_byte_to_dpcd(dp,
-DP_TEST_RESPONSE,
+exynos_dp_write_byte_to_dpcd(
+dp, DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
To me, missing argument after opening parenthesis, looks worse. I would
prefer:
exynos_dp_write_byte_to_dpcd(dp,
Why you moved the 'dp' argument to new line?
Hmm... Just like style tool indicate, no more warning after
that change.
For now, I would like to follow the original style, just improved
some obvious style
Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Hi Krzysztof,
在 09/03/2015 08:58 AM, Krzysztof Kozlowski 写道:
On 01.09.2015 14:49, Yakir Yang wrote:
Split the dp core driver from exynos directory to bridge
directory, and rename the core driver to analogix_dp_*,
leave the platform code to analogix_dp-exynos.
Signed-off-by: Yakir Yang
---
Changes in v4:
- Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery.
- Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to "exynos_dp.c"
- Take Archit suggest, create a separate folder for analogix code in bridge/
Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
to analogix_dp-exynos platform driver, add get_modes method
to struct analogix_dp_plat_data.
- Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
Changes in v2:
- Take Jingoo Han suggest, remove new copyright
- Fix compiled failed dut to analogix_dp_device misspell
drivers/gpu/drm/bridge/Kconfig |2 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/analogix/Kconfig|4 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
.../analogix/analogix_dp_core.c} | 817 ++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 283 +
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1265
.../analogix/analogix_dp_reg.h}| 258 ++--
drivers/gpu/drm/exynos/Kconfig |3 +-
drivers/gpu/drm/exynos/Makefile|2 +-
drivers/gpu/drm/exynos/exynos_dp.c | 306 +
drivers/gpu/drm/exynos/exynos_dp_core.h| 282 -
drivers/gpu/drm/exynos/exynos_dp_reg.c | 1259 ---
include/drm/bridge/analogix_dp.h | 24 +
14 files changed, 2357 insertions(+), 2150 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
bridge/analogix/analogix_dp_core.c} (50%)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
bridge/analogix/analogix_dp_reg.h} (64%)
create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
create mode 100644 include/drm/bridge/analogix_dp.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2de52a5..7b5b77a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
---help---
Parade eDP-LVDS bridge chip driver.
+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e2eef1c..5366c6b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
new file mode 100644
index 000..5ff6551
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -0,0 +1,4 @@
+config DRM_ANALOGIX_DP
+ tristate
+ depends on DRM
+ select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
new file mode 100644
index 000..9107b86
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
similarity index 50%
rename from drivers/gpu/drm/exynos/exynos_dp_core.c
rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bed0252..7d62f22 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1,14 +1,14 @@
/*
- * Samsung SoC DP (Display Port) interface driver.
- *
- * Copyright (C) 2012 Samsung Electronics Co., Ltd.
- * Author: Jingoo Han
- *
- * 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.
- */
+* Analogix DP (Display Port) core interface driver.
+*
+* Copyright (C) 2012 Samsung Electronics Co., Ltd.
+* Author: Jingoo Han
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms of the GNU
Re: [RFC 00/30] x86: Rewrite all syscall entries except native 64-bit
On Tue, Sep 1, 2015 at 6:41 PM, Andy Lutomirski wrote: > Here's a monster series that I'm working on. I think it's in decent > shape now. > > The first couple patches are tests and some old stuff. There's a > test that validates the vDSO AT_SYSINFO annotations (which fails on > 32-bit Debian systems for some reason that I can't yet fathom > because fast syscalls simply don't happen on my VM for unknown > reasons presumably related to glibc bugs or misconfiguration, and I > need to do something about the test). There's also a test that > exercises some assumptions that signal handling and ptracers make > about syscalls that currently do *not* hold on 64-bit AMD using > 32-bit AT_SYSINFO. > > The next few patches are the NT stuff. Ingo, feel free to pretend > you don't see it until the merge window closes :) > > The rest is basically a rewrite of syscalls for all cases except > 64-bit native. With these patches applied, there is a single 32-bit > vDSO and it uses SYSCALL, SYSENTER, and INT80 almost interchangeably > via alternatives. The semantics of SYSENTER and SYSCALL are defined > as: > > 1. If SYSCALL, ESP = ECX > 2. ECX = *ESP > 3. IP = INT80 landing pad > 4. Opportunistic SYSRET/SYSEXIT is enabled on return > > The vDSO is rearranged so that these semantics work. Anything that > backs IP up by 2 ends up pointing at a bona fide int $0x80 > instruction with the expected regs. > > In the process, the vDSO CFI annotations (which are actually used) > get rewritten using normal CFI directives. > > Opportunistic SYSRET/SYSEXIT only happens on return when CS and SS > are as expected, IP points to the INT80 landing pad, and flags are > in good shape. I think the opportunistic exit code could be improved a bit more. The checks are only be necessary if force_iret() was called meaning registers were changed. One possibility is to add a ti->status flag TS_FASTSYSCALL. Then we could move the tests to force_iret(), which would clear the flag if the registers fail validation. The syscall exit path then would check the flag and exit via IRET if it's clear. That would reduce the impact of the tests on the fast path where no regs were changed. > Other than that, the system call entries are simplified to the bare > minimum prologue and a call to a C function. Amusingly, SYSENTER > and SYSCALL32 use the same C function. > > To make that work, I had to remove all the 32-bit syscall stubs > except the clone argument hack. This is because, for C code to call > through the system call table, the system call table entries need to > be real function pointers with C-compatible ABIs. > > There is nothing at all anymore that requires that x86_32 syscalls > be asmlinkage. That could be removed in a subsequent patch. Other arches (at least IA-64) still need asmlinkage or something equivalent for their syscalls. asmlinkage_protect() can also be removed. > The upshot appears to be a ~25 cycle performance hit on 32-bit fast > path syscalls. The slow path is probably faster under most > circumstances and, if the exit slow path gets hit, it'll be much > faster because (as we already do in the 64-bit native case) we can > still use SYSEXIT/SYSRET. > > The patchset is structured as a removal of the old fast syscall > code, then the change that makes syscalls into real functions, then > a clean re-implementation of fast syscalls. > > If we want some of the 25 cycles back, we could consider open-coding > a new C fast path. Is the 25 cycles for the compat or native case? I'd expect the native case to be hit harder because of register pressure. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] staging: lustre: fix whitespace errors reported by checkpatch.pl
On Wed, Sep 02, 2015 at 05:48:46PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Aug 22, 2015 at 05:17:19PM +0300, Mike Rapoport wrote:
> > Added/removed spaces and replaced '+1' with '1' in several places to
> > eliminate SPACING and POINTER_LOCATION errors reported by checkpatch.pl
> >
> > Signed-off-by: Mike Rapoport
>
> Does not apply to my tree :(
Rebased against current staging-testing.
>From 4f4cdc89b94aec9a72cec4cec171d049f6f65a2a Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Sat, 22 Aug 2015 17:17:19 +0300
Subject: [PATCH] staging: lustre: fix whitespace errors reported by
checkpatch.pl
Added/removed spaces and replaced '+1' with '1' in several places to
eliminate SPACING and POINTER_LOCATION errors reported by checkpatch.pl
Signed-off-by: Mike Rapoport
---
.../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 4 +-
drivers/staging/lustre/lnet/selftest/conrpc.h | 4 +-
drivers/staging/lustre/lnet/selftest/console.c | 16 +--
drivers/staging/lustre/lnet/selftest/selftest.h| 2 +-
drivers/staging/lustre/lustre/include/cl_object.h | 14 +-
drivers/staging/lustre/lustre/include/lu_object.h | 16 +--
.../lustre/lustre/include/lustre/lustre_idl.h | 12 +-
.../lustre/lustre/include/lustre/lustre_user.h | 4 +-
.../staging/lustre/lustre/include/lustre_capa.h| 2 +-
.../staging/lustre/lustre/include/lustre_disk.h| 2 +-
drivers/staging/lustre/lustre/include/lustre_dlm.h | 6 +-
.../lustre/lustre/include/lustre_dlm_flags.h | 152 ++---
drivers/staging/lustre/lustre/include/lustre_lib.h | 6 +-
drivers/staging/lustre/lustre/include/lustre_net.h | 2 +-
drivers/staging/lustre/lustre/include/obd.h| 2 +-
.../staging/lustre/lustre/include/obd_support.h| 2 +-
drivers/staging/lustre/lustre/libcfs/tracefile.c | 4 +-
.../staging/lustre/lustre/llite/llite_internal.h | 2 +-
drivers/staging/lustre/lustre/llite/lproc_llite.c | 2 +-
drivers/staging/lustre/lustre/llite/rw.c | 6 +-
drivers/staging/lustre/lustre/llite/statahead.c| 4 +-
drivers/staging/lustre/lustre/llite/vvp_io.c | 2 +-
drivers/staging/lustre/lustre/lmv/lmv_obd.c| 2 +-
drivers/staging/lustre/lustre/lov/lov_obd.c| 4 +-
drivers/staging/lustre/lustre/obdclass/cl_io.c | 10 +-
drivers/staging/lustre/lustre/obdclass/cl_lock.c | 6 +-
drivers/staging/lustre/lustre/obdclass/cl_object.c | 2 +-
drivers/staging/lustre/lustre/obdclass/class_obd.c | 4 +-
drivers/staging/lustre/lustre/obdclass/genops.c| 6 +-
drivers/staging/lustre/lustre/obdclass/llog.c | 4 +-
.../staging/lustre/lustre/obdclass/obd_config.c| 2 +-
drivers/staging/lustre/lustre/osc/osc_request.c| 6 +-
.../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c| 2 +-
33 files changed, 157 insertions(+), 157 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index ffdc06c..d0c79d1 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -714,7 +714,7 @@ ksocknal_queue_tx_locked (ksock_tx_t *tx, ksock_conn_t
*conn)
LASSERT(tx->tx_resid == tx->tx_nob);
CDEBUG (D_NET, "Packet %p type %d, nob %d niov %d nkiov %d\n",
- tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type:
+ tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type :
KSOCK_MSG_NOOP,
tx->tx_nob, tx->tx_niov, tx->tx_nkiov);
@@ -1092,7 +1092,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
conn->ksnc_rx_iov[niov].iov_len = nob;
niov++;
skipped += nob;
- nob_to_skip -=nob;
+ nob_to_skip -= nob;
} while (nob_to_skip != 0 &&/* mustn't overflow conn's rx iov */
niov < sizeof(conn->ksnc_rx_iov_space) / sizeof (struct
iovec));
diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.h
b/drivers/staging/lustre/lnet/selftest/conrpc.h
index 7d33cf9..ae7ed75 100644
--- a/drivers/staging/lustre/lnet/selftest/conrpc.h
+++ b/drivers/staging/lustre/lnet/selftest/conrpc.h
@@ -105,8 +105,8 @@ typedef struct lstcon_rpc_trans {
#define LST_TRANS_STATQRY 0x21
-typedef int (* lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
-typedef int (* lstcon_rpc_readent_func_t)(int, srpc_msg_t *, lstcon_rpc_ent_t
*);
+typedef int (*lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
+typedef int (*lstcon_rpc_readent_func_t)(int, srpc_msg_t *, lstcon_rpc_ent_t
*);
int lstcon_sesrpc_prep(struct lstcon_node *nd, int transop,
unsigned version, lstcon_rpc_t **crpc);
diff --git a/drivers/staging/lustre/lnet/selftest/console.c
b/drivers/staging/lustre/lnet/selftest/console.c
index f47c8f2..5c624e1 100644
---
Re: [PATCH] ARM: exynos_defconfig: Make S3C2410_WATCHDOG as loadable module
Hi Krzysztof On 3 September 2015 at 10:32, Krzysztof Kozlowski wrote: > On 03.09.2015 13:10, Anand Moon wrote: >> S3C2410_WATCHDOG watchdog drivers should not be loaded automatically, >> but only if a watchdog daemon is installed. > > First of all: why? > > Secondly: even as a module driver could be loaded automatically to match > enabled device (it has MODULE_DEVICE_TABLE). In the same time loading it > does not hurt - watchdog should be inactive: > > s3c2410-wdt 1006.watchdog: watchdog inactive, reset disabled, irq > disabled > > Best regards, > Krzysztof > >> >> Signed-off-by: Anand Moon >> --- >> arch/arm/configs/exynos_defconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index aaf7aa4..b5d382e 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -101,7 +101,7 @@ CONFIG_CPU_THERMAL=y >> CONFIG_THERMAL_EMULATION=y >> CONFIG_EXYNOS_THERMAL=y >> CONFIG_WATCHDOG=y >> -CONFIG_S3C2410_WATCHDOG=y >> +CONFIG_S3C2410_WATCHDOG=m >> CONFIG_MFD_CROS_EC=y >> CONFIG_MFD_CROS_EC_I2C=y >> CONFIG_MFD_CROS_EC_SPI=y >> All the watchdog drivers are blacklisted not to be loaded by the ubuntu. Their are some configurable parameters which get configured while loading of the module using watchdog daemon. Watchdog service will reconfigure watchdog driver while loading. -Anand Moon > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: x86: set TMR when the interrupt is accepted
On Wed, Sep 2, 2015 at 3:38 PM, Steve Rutherford wrote: > On Thu, Aug 13, 2015 at 09:31:48AM +0200, Paolo Bonzini wrote: > Pinging this thread. > > Should I put together a patch to make split irqchip work properly with the > old TMR behavior? Yes, please. Intel® 64 and IA-32 Architectures Software Developer’s Manual: 24.11.4 Software Access to Related Structures In addition to data in the VMCS region itself, VMX non-root operation can be controlled by data structures that are referenced by pointers in a VMCS (for example, the I/O bitmaps). While the pointers to these data structures are parts of the VMCS, the data structures themselves are not. They are not accessible using VMREAD and VMWRITE but by ordinary memory writes. Software should ensure that each such data structure is modified only when no logical processor with a current VMCS that references it is in VMX non-root operation. Doing otherwise may lead to unpredictable behavior (including behaviors identified in Section 24.11.1) 29.6 POSTED-INTERRUPT PROCESSING ... Use of the posted-interrupt descriptor differs from that of other data structures that are referenced by pointers in a VMCS. There is a general requirement that software ensure that each such data structure is modified only when no logical processor with a current VMCS that references it is in VMX non-root operation. That requirement does not apply to the posted-interrupt descriptor. There is a requirement, however, that such modifications be done using locked read-modify-write instructions. > >> >> >> On 13/08/2015 08:35, Zhang, Yang Z wrote: >> >> You may be right. It is safe if no future hardware plans to use >> >> it. Let me check with our hardware team to see whether it will be >> >> used or not in future. >> > >> > After checking with Jun, there is no guarantee that the guest running >> > on another CPU will operate properly if hypervisor modify the vTMR >> > from another CPU. So the hypervisor should not to do it. >> >> I guess I can cause a vmexit on level-triggered interrupts, it's not a >> big deal, but no weasel words, please. >> >> What's going to break, and where is it documented? >> >> Paolo >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jun Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] staging: fbtft: fbtft_request_gpios: reduce nesting
Returning immediately if no platform_data or platform_data->gpios is
specified reduceis code nesting
Signed-off-by: Mike Rapoport
---
drivers/staging/fbtft/fbtft-core.c | 51 +++---
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 81ba416..f55936a 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -127,33 +127,34 @@ static int fbtft_request_gpios(struct fbtft_par *par)
unsigned long flags;
int ret;
- if (pdata && pdata->gpios) {
- gpio = pdata->gpios;
- while (gpio->name[0]) {
- flags = FBTFT_GPIO_NO_MATCH;
- /* if driver provides match function, try it first,
- if no match use our own */
- if (par->fbtftops.request_gpios_match)
- flags = par->fbtftops.request_gpios_match(par,
gpio);
- if (flags == FBTFT_GPIO_NO_MATCH)
- flags = fbtft_request_gpios_match(par, gpio);
- if (flags != FBTFT_GPIO_NO_MATCH) {
- ret = devm_gpio_request_one(par->info->device,
- gpio->gpio, flags,
-
par->info->device->driver->name);
- if (ret < 0) {
- dev_err(par->info->device,
- "%s: gpio_request_one('%s'=%d)
failed with %d\n",
- __func__, gpio->name,
- gpio->gpio, ret);
- return ret;
- }
- fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par,
- "%s: '%s' = GPIO%d\n",
- __func__, gpio->name, gpio->gpio);
+ if (!(pdata && pdata->gpios))
+ return 0;
+
+ gpio = pdata->gpios;
+ while (gpio->name[0]) {
+ flags = FBTFT_GPIO_NO_MATCH;
+ /* if driver provides match function, try it first,
+ if no match use our own */
+ if (par->fbtftops.request_gpios_match)
+ flags = par->fbtftops.request_gpios_match(par, gpio);
+ if (flags == FBTFT_GPIO_NO_MATCH)
+ flags = fbtft_request_gpios_match(par, gpio);
+ if (flags != FBTFT_GPIO_NO_MATCH) {
+ ret = devm_gpio_request_one(par->info->device,
+ gpio->gpio, flags,
+ par->info->device->driver->name);
+ if (ret < 0) {
+ dev_err(par->info->device,
+ "%s: gpio_request_one('%s'=%d) failed
with %d\n",
+ __func__, gpio->name,
+ gpio->gpio, ret);
+ return ret;
}
- gpio++;
+ fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par,
+ "%s: '%s' = GPIO%d\n",
+ __func__, gpio->name, gpio->gpio);
}
+ gpio++;
}
return 0;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] staging: fbtft: fb_ssd1351: define backlight_ops statically
instead of devm_kzalloc'ing them
Signed-off-by: Mike Rapoport
---
drivers/staging/fbtft/fb_ssd1351.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ssd1351.c
b/drivers/staging/fbtft/fb_ssd1351.c
index 9bcd7a0..dff5809 100644
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -208,25 +208,22 @@ static int update_onboard_backlight(struct
backlight_device *bd)
return 0;
}
+static const struct backlight_ops bl_ops = {
+ .update_status = update_onboard_backlight,
+};
+
static void register_onboard_backlight(struct fbtft_par *par)
{
struct backlight_device *bd;
struct backlight_properties bl_props = { 0, };
- struct backlight_ops *bl_ops;
fbtft_par_dbg(DEBUG_BACKLIGHT, par, "%s()\n", __func__);
- bl_ops = devm_kzalloc(par->info->device, sizeof(struct backlight_ops),
- GFP_KERNEL);
- if (!bl_ops)
- return;
-
- bl_ops->update_status = update_onboard_backlight;
bl_props.type = BACKLIGHT_RAW;
bl_props.power = FB_BLANK_POWERDOWN;
bd = backlight_device_register(dev_driver_string(par->info->device),
- par->info->device, par, bl_ops, _props);
+ par->info->device, par, _ops, _props);
if (IS_ERR(bd)) {
dev_err(par->info->device,
"cannot register backlight device (%ld)\n",
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] staging: fbtft: fbtft-core: define backlight_ops statically
instead of devm_kzalloc'ing them
Signed-off-by: Mike Rapoport
---
drivers/staging/fbtft/fbtft-core.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index bbc394a..81ba416 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -280,11 +280,15 @@ void fbtft_unregister_backlight(struct fbtft_par *par)
}
}
+static const struct backlight_ops fbtft_bl_ops = {
+ .get_brightness = fbtft_backlight_get_brightness,
+ .update_status = fbtft_backlight_update_status,
+};
+
void fbtft_register_backlight(struct fbtft_par *par)
{
struct backlight_device *bd;
struct backlight_properties bl_props = { 0, };
- struct backlight_ops *bl_ops;
fbtft_par_dbg(DEBUG_BACKLIGHT, par, "%s()\n", __func__);
@@ -294,13 +298,6 @@ void fbtft_register_backlight(struct fbtft_par *par)
return;
}
- bl_ops = devm_kzalloc(par->info->device, sizeof(struct backlight_ops),
- GFP_KERNEL);
- if (!bl_ops)
- return;
-
- bl_ops->get_brightness = fbtft_backlight_get_brightness;
- bl_ops->update_status = fbtft_backlight_update_status;
bl_props.type = BACKLIGHT_RAW;
/* Assume backlight is off, get polarity from current state of pin */
bl_props.power = FB_BLANK_POWERDOWN;
@@ -308,7 +305,7 @@ void fbtft_register_backlight(struct fbtft_par *par)
bl_props.state |= BL_CORE_DRIVER1;
bd = backlight_device_register(dev_driver_string(par->info->device),
- par->info->device, par, bl_ops, _props);
+ par->info->device, par, _bl_ops,
_props);
if (IS_ERR(bd)) {
dev_err(par->info->device,
"cannot register backlight device (%ld)\n",
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] staging: fbtft: fb_watterott: define backlight_ops statically
instead of devm_kzalloc'ing them
Signed-off-by: Mike Rapoport
---
drivers/staging/fbtft/fb_watterott.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/fbtft/fb_watterott.c
b/drivers/staging/fbtft/fb_watterott.c
index 88fb2c0..e8ebe2e 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -257,31 +257,24 @@ static int backlight_chip_update_status(struct
backlight_device *bd)
return 0;
}
+static const struct backlight_ops bl_ops = {
+ .update_status = backlight_chip_update_status,
+};
+
static void register_chip_backlight(struct fbtft_par *par)
{
struct backlight_device *bd;
struct backlight_properties bl_props = { 0, };
- struct backlight_ops *bl_ops;
fbtft_par_dbg(DEBUG_BACKLIGHT, par, "%s()\n", __func__);
- bl_ops = devm_kzalloc(par->info->device, sizeof(struct backlight_ops),
- GFP_KERNEL);
- if (!bl_ops) {
- dev_err(par->info->device,
- "%s: could not allocate memory for backlight
operations.\n",
- __func__);
- return;
- }
-
- bl_ops->update_status = backlight_chip_update_status;
bl_props.type = BACKLIGHT_RAW;
bl_props.power = FB_BLANK_POWERDOWN;
bl_props.max_brightness = 100;
bl_props.brightness = DEFAULT_BRIGHTNESS;
bd = backlight_device_register(dev_driver_string(par->info->device),
- par->info->device, par, bl_ops, _props);
+ par->info->device, par, _ops, _props);
if (IS_ERR(bd)) {
dev_err(par->info->device,
"cannot register backlight device (%ld)\n",
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] staging: fbtft: some checpatch.pl cleanups
Hi, These patches slightly refactor the code to reduce amount of checkpath.pl warnings v2 changes: * add elaborate changelog to the first pacth in the series (staging: fbtft: remove unused bl_ops from fbtft_unregister_backlight) Mike Rapoport (5): staging: fbtft: remove unused bl_ops from fbtft_unregister_backlight staging: fbtft: fbtft-core: define backlight_ops statically staging: fbtft: fbtft_request_gpios: reduce nesting staging: fbtft: fb_ssd1351: define backlight_ops statically staging: fbtft: fb_watterott: define backlight_ops statically drivers/staging/fbtft/fb_ssd1351.c | 13 +++ drivers/staging/fbtft/fb_watterott.c | 17 +++-- drivers/staging/fbtft/fbtft-core.c | 69 +--- 3 files changed, 42 insertions(+), 57 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] staging: fbtft: remove unused bl_ops from fbtft_unregister_backlight
The only usage of bl_ops variable in fbtft_unregister_backlight function
was assigment of a value to that variable, therefore the assignment and
the variable itself can be safely removed
Signed-off-by: Mike Rapoport
---
drivers/staging/fbtft/fbtft-core.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 23392eb..bbc394a 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -270,14 +270,11 @@ static int fbtft_backlight_get_brightness(struct
backlight_device *bd)
void fbtft_unregister_backlight(struct fbtft_par *par)
{
- const struct backlight_ops *bl_ops;
-
fbtft_par_dbg(DEBUG_BACKLIGHT, par, "%s()\n", __func__);
if (par->info->bl_dev) {
par->info->bl_dev->props.power = FB_BLANK_POWERDOWN;
backlight_update_status(par->info->bl_dev);
- bl_ops = par->info->bl_dev->ops;
backlight_device_unregister(par->info->bl_dev);
par->info->bl_dev = NULL;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
On 03.09.2015 12:57, Anand Moon wrote: > From: Anand Moon > > Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, > LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for > Odroid-XU3/XU4 board. > > Signed-off-by: Anand Moon > > --- > Changes from last version > dropped following option. > CONFIG_LEDS_CLASS_FLASH > CONFIG_TRIGGER_ONESHOT > CONFIG_TRIGGER_GPIO Thank you. The patch looks good, commit message... almost. Now the "From" address does not match "Signed-off-by". Please fix and resubmit :) . BR, Krzysztof > --- > arch/arm/configs/exynos_defconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 9504e77..aaf7aa4 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_IDMAC=y > CONFIG_MMC_DW_EXYNOS=y > +CONFIG_NEW_LEDS=y > +CONFIG_LEDS_CLASS=y > +CONFIG_LEDS_GPIO=y > +CONFIG_LEDS_PWM=y > +CONFIG_LEDS_TRIGGERS=y > +CONFIG_LEDS_TRIGGER_TIMER=y > +CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_RTC_CLASS=y > CONFIG_RTC_DRV_MAX77686=y > CONFIG_RTC_DRV_MAX77802=y > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: fix bug which lowmem size is limited to 760MB
default value of VMALLOC_START was set 0xf000 for ARM by commit
0536bdf3. It leads lowmem end address 0xef80 not 0xf000.
VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff00 - 0x0f00 - 0x0080 = 0xef80
In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 8000-afff to -af7f (vmalloc region overlap)."
Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.
Signed-off-by: Yongtaek Lee
---
arch/arm/mm/mmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
#endif
static void * __initdata vmalloc_min =
- (void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+ (void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
/*
* vmalloc=size forces the vmalloc area to be exactly 'size'
* bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
*/
static int __init early_vmalloc(char *arg)
{
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 01/16] drm: exynos/dp: fix code style
On 03.09.2015 14:04, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 09/03/2015 08:21 AM, Krzysztof Kozlowski 写道:
>> On 01.09.2015 14:46, Yakir Yang wrote:
>>> After run "checkpatch.pl -f --subjective" command, I see there
>>> are lots of alignment problem in exynos_dp driver, so let just
>>> fix them.
>> Hi,
>>
>> Warnings from checkpatch are not a reason for a commit. Reason for a
>> commit could be for example an unreadable code, violation of
>> coding-style leading to decrease in code maintainability or just
>> improving the code readability so it will be easier to review and
>> maintain it.
>>
>> You do not make commits because some tool tells you that. We do not
>> listen to machines :) ... If that would be the case, the commit could be
>> made automatically, without human interaction. Such automated commit
>> could be even easily tested by the machine by comparing object files.
>>
>> Especially that you enabled "subjective" rule. This is not a valid
>> motivation for a commit.
>>
>> Please rephrase this to sensible reason and convince that change is
>> worth the effort.
>
> Oh, nice, thanks for your remind. I would rephrase the commit.
>
>>> - Take Romain suggest, rebase on linux-next branch
>> That comment seems unrelated to the commit. Please remove it.
>
> Done,
>
>>
>>> Signed-off-by: Yakir Yang
>>> ---
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2:
>>> - Take Joe Preches advise, improved commit message more readable, and
>>>avoid using some uncommon style like bellow:
>>>- retval = exynos_dp_read_bytes_from_i2c(...
>>> ...)
>>>+ retval =
>>>+ exynos_dp_read_bytes_from_i2c(..);
>>>
>>> drivers/gpu/drm/exynos/exynos_dp_core.c | 226
>>>
>>> drivers/gpu/drm/exynos/exynos_dp_core.h | 54
>>> drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
>>> 3 files changed, 188 insertions(+), 198 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> index d66ade0..266f7f7 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> @@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> /* Read Extension Flag, Number of 128-byte EDID extension
>>> blocks */
>>> retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
>>> -EDID_EXTENSION_FLAG,
>>> -_block);
>>> + EDID_EXTENSION_FLAG,
>>> + _block);
>>> if (retval)
>>> return retval;
>>> @@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> dev_dbg(dp->dev, "EDID data includes a single extension!\n");
>>> /* Read EDID data */
>>> -retval = exynos_dp_read_bytes_from_i2c(dp,
>>> I2C_EDID_DEVICE_ADDR,
>>> -EDID_HEADER_PATTERN,
>>> -EDID_BLOCK_LENGTH,
>>> -[EDID_HEADER_PATTERN]);
>>> +retval = exynos_dp_read_bytes_from_i2c(
>>> +dp, I2C_EDID_DEVICE_ADDR,
>>> +EDID_HEADER_PATTERN,
>>> +EDID_BLOCK_LENGTH,
>>> +[EDID_HEADER_PATTERN]);
>>> if (retval != 0) {
>>> dev_err(dp->dev, "EDID Read failed!\n");
>>> return -EIO;
>>> @@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> }
>>> /* Read additional EDID data */
>>> -retval = exynos_dp_read_bytes_from_i2c(dp,
>>> -I2C_EDID_DEVICE_ADDR,
>>> -EDID_BLOCK_LENGTH,
>>> -EDID_BLOCK_LENGTH,
>>> -[EDID_BLOCK_LENGTH]);
>>> +retval = exynos_dp_read_bytes_from_i2c(
>>> +dp, I2C_EDID_DEVICE_ADDR,
>>> +EDID_BLOCK_LENGTH,
>>> +EDID_BLOCK_LENGTH,
>>> +[EDID_BLOCK_LENGTH]);
>>> if (retval != 0) {
>>> dev_err(dp->dev, "EDID Read failed!\n");
>>> return -EIO;
>>> @@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct
>>> exynos_dp_device *dp)
>>> }
>>> exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
>>> -_vector);
>>> + _vector);
>>> if (test_vector & DP_TEST_LINK_EDID_READ) {
>>> -exynos_dp_write_byte_to_dpcd(dp,
>>> -DP_TEST_EDID_CHECKSUM,
>>> +exynos_dp_write_byte_to_dpcd(
>>> +dp, DP_TEST_EDID_CHECKSUM,
>>> edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
>>> -exynos_dp_write_byte_to_dpcd(dp,
>>> -DP_TEST_RESPONSE,
>>> +exynos_dp_write_byte_to_dpcd(
>>> +dp, DP_TEST_RESPONSE,
>>> DP_TEST_EDID_CHECKSUM_WRITE);
>> To me,
linux-next: Tree for Sep 3
Hi all, There will be no linux-next releases on Friday (tomorrow) or Monday. Please do not add material for v4.4 until after v4.3-rc1 is out. Changes since 20150902: I used the h8300 tree from next-20150828 since the current tree has been rebased onto something very old :-( The drm-misc tree gained a build failure so I used the version from next-20150902. The rcu tree lost its build failure. Non-merge commits (relative to Linus' tree): 6610 5986 files changed, 364366 insertions(+), 170374 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 225 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (d975f309a8b2 Merge branch 'for-4.3/sg' of git://git.kernel.dk/linux-block) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (3939f3345050 ARM: 8418/1: add boot image dependencies to not generate invalid images) Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather than duplicating its implementation) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (4d9aac397a5d powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (f892a84cc890 net/smsc911x: Fix deferred probe for interrupt) Merging ipsec/master (158cd4af8ded packet: missing dev_put() in packet_do_bind()) Merging sound-current/for-linus (6869de380e8c ALSA: hda - Fix missing inline for dummy snd_hdac_set_codec_wakeup()) Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses on PA-RISC) Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module parameter for MSI interrupts) Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging tty.current/tty-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() call to error pathway) Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module) Merging staging.current/staging-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging input-current/for-linus (e51e38494a8e Input: synaptics - fix handling of disabling gesture mode) Merging crypto-current/master (bf433416e675 crypto: algif_aead - fix for multiple operations on AF_ALG sockets) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix futex_cmp_requeue_pi() error handling) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e bac
Re: [PATCH v4 01/16] drm: exynos/dp: fix code style
Hi Krzysztof,
在 09/03/2015 08:21 AM, Krzysztof Kozlowski 写道:
On 01.09.2015 14:46, Yakir Yang wrote:
After run "checkpatch.pl -f --subjective" command, I see there
are lots of alignment problem in exynos_dp driver, so let just
fix them.
Hi,
Warnings from checkpatch are not a reason for a commit. Reason for a
commit could be for example an unreadable code, violation of
coding-style leading to decrease in code maintainability or just
improving the code readability so it will be easier to review and
maintain it.
You do not make commits because some tool tells you that. We do not
listen to machines :) ... If that would be the case, the commit could be
made automatically, without human interaction. Such automated commit
could be even easily tested by the machine by comparing object files.
Especially that you enabled "subjective" rule. This is not a valid
motivation for a commit.
Please rephrase this to sensible reason and convince that change is
worth the effort.
Oh, nice, thanks for your remind. I would rephrase the commit.
- Take Romain suggest, rebase on linux-next branch
That comment seems unrelated to the commit. Please remove it.
Done,
Signed-off-by: Yakir Yang
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
avoid using some uncommon style like bellow:
- retval = exynos_dp_read_bytes_from_i2c(...
...)
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/exynos/exynos_dp_core.c | 226
drivers/gpu/drm/exynos/exynos_dp_core.h | 54
drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
3 files changed, 188 insertions(+), 198 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..266f7f7 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct exynos_dp_device *dp)
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_EXTENSION_FLAG,
- _block);
+ EDID_EXTENSION_FLAG,
+ _block);
if (retval)
return retval;
@@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device *dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
- retval = exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- [EDID_HEADER_PATTERN]);
+ retval = exynos_dp_read_bytes_from_i2c(
+ dp, I2C_EDID_DEVICE_ADDR,
+ EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH,
+ [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
*dp)
}
/* Read additional EDID data */
- retval = exynos_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_BLOCK_LENGTH,
- EDID_BLOCK_LENGTH,
- [EDID_BLOCK_LENGTH]);
+ retval = exynos_dp_read_bytes_from_i2c(
+ dp, I2C_EDID_DEVICE_ADDR,
+ EDID_BLOCK_LENGTH,
+ EDID_BLOCK_LENGTH,
+ [EDID_BLOCK_LENGTH]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct exynos_dp_device
*dp)
}
exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
- _vector);
+ _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
- exynos_dp_write_byte_to_dpcd(dp,
- DP_TEST_EDID_CHECKSUM,
+ exynos_dp_write_byte_to_dpcd(
+ dp, DP_TEST_EDID_CHECKSUM,
edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
- exynos_dp_write_byte_to_dpcd(dp,
-
Re: [PATCH] ARM: exynos_defconfig: Make S3C2410_WATCHDOG as loadable module
On 03.09.2015 13:10, Anand Moon wrote: > S3C2410_WATCHDOG watchdog drivers should not be loaded automatically, > but only if a watchdog daemon is installed. First of all: why? Secondly: even as a module driver could be loaded automatically to match enabled device (it has MODULE_DEVICE_TABLE). In the same time loading it does not hurt - watchdog should be inactive: s3c2410-wdt 1006.watchdog: watchdog inactive, reset disabled, irq disabled Best regards, Krzysztof > > Signed-off-by: Anand Moon > --- > arch/arm/configs/exynos_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index aaf7aa4..b5d382e 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -101,7 +101,7 @@ CONFIG_CPU_THERMAL=y > CONFIG_THERMAL_EMULATION=y > CONFIG_EXYNOS_THERMAL=y > CONFIG_WATCHDOG=y > -CONFIG_S3C2410_WATCHDOG=y > +CONFIG_S3C2410_WATCHDOG=m > CONFIG_MFD_CROS_EC=y > CONFIG_MFD_CROS_EC_I2C=y > CONFIG_MFD_CROS_EC_SPI=y > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: pass policy to ->get() driver callback
On 31-07-15, 16:14, Viresh Kumar wrote: > CPUFreq drivers today support ->get(cpu) callback, which returns current > clock rate of the CPU. The problem with ->get() is that it takes cpu > number as parameter and this unnecessarily makes things complex. > > Firstly the core gets the cpu number by doing operation 'policy->cpu' on > the policy and then many drivers need to get the policy back and so do > cpufreq_cpu_get(cpu) on the cpu passed as argument to ->get(). > > It would be better if we pass them 'policy' directly and drivers can use > policy->cpu if that's all they need. > > Signed-off-by: Viresh Kumar Is this getting moved to 4.4? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] drivers/misc/sgi-gru: remove unused variable
On Wed, Sep 02, 2015 at 09:42:04AM -0500, Dimitri Sivanich wrote: > On Wed, Sep 02, 2015 at 04:54:55PM +0530, Sudip Mukherjee wrote: > > These variables were only assigned some value and were never used. > > > > Signed-off-by: Sudip Mukherjee > > --- > > > > + int i; > + > + if ((GRU_NUM_TFM * GRU_CACHE_LINE_BYTES) > (ubufend - ubuf)) > + return -EFBIG; Just a minor (or major) doubt. The function returns GRU_NUM_TFM * GRU_CACHE_LINE_BYTES and the for loop is also running till GRU_NUM_TFM so I am assuming that the function can handle buffer till size of GRU_NUM_TFM * GRU_CACHE_LINE_BYTES. So the error -EFBIG should occur when the buffer is more than this. Then shouldn't it be: if ((GRU_NUM_TFM * GRU_CACHE_LINE_BYTES) < (ubufend - ubuf)) return -EFBIG; or i am wrong in interpreting it? regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 5/7] extcon: Export OF module alias information in missing drivers
On 2015년 08월 25일 15:31, Javier Martinez Canillas wrote: > The I2C core always reports the MODALIAS uevent as "i2c:" > regardless of the mechanism that was used to register the device > (i.e: OF or board code) and the table that is used later to match > the driver with the device (i.e: I2C id table or OF match table). > > So drivers needs to export the I2C id table and this be built into > the module or udev won't have the necessary information to autoload > the needed driver module when the device is added. > > But this means that OF-only drivers needs to have both OF and I2C id > tables that have to be kept in sync and also the dev node compatible > manufacturer prefix is stripped when reporting the MODALIAS. Which can > lead to issues if two vendors use the same I2C device name for example. > > To avoid the above, the I2C core behavior may be changed in the future > to not require an SPI device table for OF-only drivers and report the > OF module alias. So, it's better to also export the OF table even when > is unused now to prevent breaking module loading when the core changes. > > Signed-off-by: Javier Martinez Canillas > > --- > > drivers/extcon/extcon-rt8973a.c | 1 + > drivers/extcon/extcon-sm5502.c | 1 + > 2 files changed, 2 insertions(+) Applied it. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] SG changes for 4.3
On Wed, Sep 2, 2015 at 3:50 PM, Jens Axboe wrote: > On 09/02/2015 04:41 PM, Jens Axboe wrote: >> >> On 09/02/2015 04:34 PM, Linus Torvalds wrote: >>> >>> Jens, >>> >>> On Wed, Sep 2, 2015 at 9:58 AM, Jens Axboe wrote: This pull request contains a set of scatter-gather related changes/fixes for 4.3. It contains: >>> >>> >>> This results in several new and annoying warnings. They may all be ok >>> code, but they are very distracting. Please stop introducing new >>> warnings to the build, because by now most of the warnings I see come >>> from the block layer. >>> >>> block/blk-merge.c: In function ‘blk_queue_split’: >>> include/linux/blkdev.h:1368:21: warning: ‘bvprv.bv_offset’ may be >>> used uninitialized in this function [-Wmaybe-uninitialized] >>> ((bprv->bv_offset + bprv->bv_len) & queue_virt_boundary(q)); >>> >>> (it gives this for bv_len too). The reason seems to be that disgusting >>> situation where "bvprv" is uninitiatlized unless "split" is true, and >>> the code looks like it is correct, but the compiler clearly has a hard >>> time seeing it. It took me a while too, so I can't really blame it. >>> >>> Either initialize bvprv to something explicit, or make the code clear >>> enough that the compiler can see that it is never used uninitialized. >>> Because those compiler warnings are sometimes real, and we can't just >>> ignore them. >>> >>> There was another type-based warning introduced by your core block >>> pull (size_t vs unsigned int). >> >> >> I think it's a repeat offender that got reintroduced. I'll fix it up. > > > This seems to make it happier. Will go out later in the merge window. > > http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=5014c311baa2b21384321fa4a9f617a92e3e56f0 Thanks Jens. I didn't see these warnings with gcc 4.8.4. What gcc version did you use or need to turn on some config option to see the warning? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Hi Rob, 在 09/03/2015 04:17 AM, Rob Herring 写道: On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: Some edp screen do not have hpd signal, so we can't just return failed when hpd plug in detect failed. This is a property of the panel (or connector perhaps), so this property should be located there. At least, it is a common issue and not specific to this chip. We could have an HDMI connector and failed to hook up HPD for example. A connector node is also where hpd-gpios should be located instead (and are already defined by ../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector binding, too. Yep, I agree with your front point, it is a property of panel, not specific to eDP controller, so this code should handle in connector logic. But another question, if we just leave this property to connector, then we would need to parse this property in analogix_dp-rockchip.c, and then make an hook in analogix_dp_core.c driver. This is not nice, and if there are some coming platform which alse want to use analogix_dp code and meet this "no-hpd" situation, then they would need duplicate to parse this property and fill the hook in analogix_dp_core.c driver. So it's little bit conflict :-) Beside I can not understand your example very well. Do you mean that there are some HDMI monitor which also do not have HPD signal (just like some eDP panel do not have hpd too), and then the "hpd-gpios" ? Hmm... I don't know how the "hpd-gpios" want to help in this case, would you mind show some sample code :-D Are there any eDP panels which don't have EDID and need panel details in DT? Oh, I think you want to collect some info that belong to panel property but no indicate in panel EDID message, so those can be collect in eDP connector binding, is it right ? As for me, I just meet this "no-hpd" special situation. - Yakir Rob This is an hardware property, so we need add a devicetree property "analogix,need-force-hpd" to indicate this sutiation. Signed-off-by: Yakir Yang --- Changes in v4: None Changes in v3: - Add "analogix,need-force-hpd" to indicate whether driver need foce hpd when hpd detect failed. Changes in v2: None .../devicetree/bindings/drm/bridge/analogix_dp.txt | 4 ++- .../bindings/video/analogix_dp-rockchip.txt| 1 + .../devicetree/bindings/video/exynos_dp.txt| 1 + drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 +++--- drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++ drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++ 6 files changed, 47 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt index f54dc3e..c310367 100644 --- a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt @@ -22,6 +22,9 @@ Required properties for dp-controller: from general PHY binding: Should be "dp". Optional properties for dp-controller: + -analogix,need-force-hpd: + Indicate driver need force hpd when hpd detect failed, this + is used for some eDP screen which don't have hpd signal. -hpd-gpios: Hotplug detect GPIO. Indicates which GPIO should be used for hotplug detection @@ -31,7 +34,6 @@ Optional properties for dp-controller: * Documentation/devicetree/bindings/video/exynos_dp.txt * Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt - [1]: Documentation/devicetree/bindings/media/video-interfaces.txt --- diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt index 502483e..8b9ed7d 100644 --- a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt +++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt @@ -28,6 +28,7 @@ For the below properties, please refer to Analogix DP binding document: - phys (required) - phy-names (required) - hpd-gpios (optional) +- analogix,need-force-hpd (optional) --- Example: diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index ea03b3a..4f06e80 100644 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding document: -phys (required) -phy-names (required) -hpd-gpios (optional) + -analogix,need-force-hpd (optional) -video interfaces (optional) Deprecated properties for DisplayPort: diff --git
平时最多也就联系了三千家，全球还有十几万客户在哪里？
您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ2821117472给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kfree a pointer "from the middle" causing protection faults
On Wed, Sep 2, 2015 at 9:39 PM, Jeff Epler wrote: > On Wed, Sep 02, 2015 at 08:32:15PM +0530, Muni Sekhar wrote: >> [ Please keep me in CC as I'm not subscribed to the list] >> >> Hello, >> >> >> I am getting protection faults in different kernel modules if I try to >> free a pointer "from the middle" for example, look at the following >> code: > [..] > > Most memory allocators require the pointer eventually passed to the > freeing function is the same pointer as the one returned from the > allocating function. This is true for libc malloc/free, for instance. > As far as I know, it is true for the Linux allocators such as kzalloc. > The bug lies in whatever part of linux makes the invalid kfree call. > > I have not found any documentation that kernel kzalloc/kfree allow > passing a pointer "from the middle". For instance, > These routines are used to dynamically request pointer-aligned chunks of > memory, like malloc and free do in userspace > https://www.kernel.org/doc/htmldocs/kernel-hacking/routines-kmalloc.html > > If the faulty code that you allude to is in the Linux source then please > say what it is so that developers can fix it. If it's an out of source > module or kernel patch then contact the supplier of that code. The faulty code mentioned above is not in the Linux source, I noticed this behaviour during testing our own module. Thanks for the clarification Jeff. > > Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/mmap.c: Remove redundent 'get_area' function pointer in get_unmapped_area()
From: Chen Gang
Call the function pointer directly, then let code a bit simpler.
Signed-off-by: Chen Gang
---
mm/mmap.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 4db7cf0..39fd727 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2012,10 +2012,8 @@ unsigned long
get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
unsigned long pgoff, unsigned long flags)
{
- unsigned long (*get_area)(struct file *, unsigned long,
- unsigned long, unsigned long, unsigned long);
-
unsigned long error = arch_mmap_check(addr, len, flags);
+
if (error)
return error;
@@ -2023,10 +2021,12 @@ get_unmapped_area(struct file *file, unsigned long
addr, unsigned long len,
if (len > TASK_SIZE)
return -ENOMEM;
- get_area = current->mm->get_unmapped_area;
if (file && file->f_op->get_unmapped_area)
- get_area = file->f_op->get_unmapped_area;
- addr = get_area(file, addr, len, pgoff, flags);
+ addr = file->f_op->get_unmapped_area(file, addr, len,
+ pgoff, flags);
+ else
+ addr = current->mm->get_unmapped_area(file, addr, len,
+ pgoff, flags);
if (IS_ERR_VALUE(addr))
return addr;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: exynos_defconfig: Make S3C2410_WATCHDOG as loadable module
S3C2410_WATCHDOG watchdog drivers should not be loaded automatically, but only if a watchdog daemon is installed. Signed-off-by: Anand Moon --- arch/arm/configs/exynos_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index aaf7aa4..b5d382e 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -101,7 +101,7 @@ CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y CONFIG_EXYNOS_THERMAL=y CONFIG_WATCHDOG=y -CONFIG_S3C2410_WATCHDOG=y +CONFIG_S3C2410_WATCHDOG=m CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_I2C=y CONFIG_MFD_CROS_EC_SPI=y -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mmap.c: Remove useless statement "vma = NULL" in find_vma()
Hello all:
I also want to consult: the comments of find_vma() says:
"Look up the first VMA which satisfies addr < vm_end, ..."
Is it OK? (why not "vm_start <= addr < vm_end"), need we let "vma = tmp"
in "if (tmp->vm_start <= addr)"? -- it looks the comments is not match
the implementation, precisely (maybe not 1st VMA).
Thanks.
On 9/3/15 11:52, gang.chen.5...@gmail.com wrote:
> From: Chen Gang
>
> Before the main looping, vma is already is NULL, so need not set it to
> NULL, again.
>
> Signed-off-by: Chen Gang
> ---
> mm/mmap.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index df6d5f0..4db7cf0 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2054,7 +2054,6 @@ struct vm_area_struct *find_vma(struct mm_struct *mm,
> unsigned long addr)
> return vma;
>
> rb_node = mm->mm_rb.rb_node;
> - vma = NULL;
>
> while (rb_node) {
> struct vm_area_struct *tmp;
>
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5] ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
From: Anand Moon Enable config option NEW_LEDS, LEDS_CLASS, LEDS_GPIO, LEDS_PWM, LEDS_TRIGGERS, LEDS_TRIGGER_TIMER, LEDS_TRIGGER_HEARTBEAT for Odroid-XU3/XU4 board. Signed-off-by: Anand Moon --- Changes from last version dropped following option. CONFIG_LEDS_CLASS_FLASH CONFIG_TRIGGER_ONESHOT CONFIG_TRIGGER_GPIO --- arch/arm/configs/exynos_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 9504e77..aaf7aa4 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -163,6 +163,13 @@ CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_MAX77802=y -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Hi Emil, 在 09/02/2015 10:50 PM, Emil Velikov 写道: [Dropping the CC list] Hmm...Don't understand what this means. If you can explain, that would be better, so I would not miss your suggest. :-) Hi Yakir Yang, On 1 September 2015 at 06:49, Yakir Yang wrote: Split the dp core driver from exynos directory to bridge directory, and rename the core driver to analogix_dp_*, leave the platform code to analogix_dp-exynos. Signed-off-by: Yakir Yang --- Changes in v4: - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery. - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to "exynos_dp.c" - Take Archit suggest, create a separate folder for analogix code in bridge/ "Take X suggest", is grammatically incorrect. You should use "suggestion(s)" or alternatively use the following approach. - Create a separate folder for analogix code in bridge/ (Archit) Thanks for your correct. I prefer to take the last one ;) Cheers, Emil P.S. Why do you resend the whole series (some 10+ patches) when only a few patches have been changed ? Are all the patches changed whist missing that information (vX: rebase on top of A) Yes, those 10+ patches do base on the previous changes, specially when I rebase my series on the latest linux-next branch. Besides, I don't know that how to send parts of this series, and keep the unrelated patches no send. For example if the [v4 03/16] ~ [v4 10/16] need update to v5, and [v4 11/16] ~ [v4 16/16] keep in v4. So should I only send the [v5 03/16] ~ [v5 10/16], no need to send and update [v4 11/16] ~ [v4 16/16] to v5 ? If so I think it would be difficult for guys to comment, cause they can't see the whole series in one reply list . ;) Thanks, - Yakir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/mmap.c: Remove useless statement "vma = NULL" in find_vma()
From: Chen Gang
Before the main looping, vma is already is NULL, so need not set it to
NULL, again.
Signed-off-by: Chen Gang
---
mm/mmap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index df6d5f0..4db7cf0 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2054,7 +2054,6 @@ struct vm_area_struct *find_vma(struct mm_struct *mm,
unsigned long addr)
return vma;
rb_node = mm->mm_rb.rb_node;
- vma = NULL;
while (rb_node) {
struct vm_area_struct *tmp;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY
Hi Rob,
在 09/02/2015 09:27 PM, Rob Herring 写道:
On Tue, Sep 1, 2015 at 1:04 AM, Yakir Yang wrote:
This phy driver would control the Rockchip DisplayPort module
phy clock and phy power, it is relate to analogix_dp-rockchip
dp driver. If you want DP works rightly on rockchip platform,
then you should select both of them.
Signed-off-by: Yakir Yang
---
Changes in v4:
- Take Kishon suggest, add commit message, and remove the redundant
rockchip_dp_phy_init() function, move those code to probe() method.
And remove driver .owner number.
Changes in v3:
- Take Heiko suggest, add rockchip dp phy driver,
collect the phy clocks and power control.
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 26
It is preferred that you split binding doc's from driver changes.
Okay, done.
drivers/phy/Kconfig| 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 166 +
4 files changed, 200 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..5de1088
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,26 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+
+- reg : a list of registers used by phy driver
Please state the size of the list and order of what each entry if more than one.
Just like Heiko remind, I don't need the reg number anymore,
"rockchip,grf" is enough for this driver.
Anyway thanks :-)
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "sclk_dp" "sclk_dp_24m"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
I have no idea what GRF means.
GRF is an module of our IC chip, the full name is General Register Files.
I would rather to pick some words from our TRM.
The general register file will be used to do static set by software, which
is composed of many registers for system control.
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: phy@ff770274 {
+ compatilble = "rockchip,rk3288-dp-phy";
+ reg = <0xff770274 4>;
+ rockchip,grf = <>;
+ clocks = < SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+}
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..8f2bc4f 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..e281f35 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..e9a726e
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,166 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_SOC_CON12 0x0274
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+
+#define DP_PHY_SIDDQ_WRITE_EN BIT(21)
+#define DP_PHY_SIDDQ_ON 0
+#define DP_PHY_SIDDQ_OFFBIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ void
[PATCH V3 2/2] watchdog: Read device status through sysfs attributes
This patch adds following attributes to watchdog device's sysfs interface
to read its different status.
* state - reads whether device is active or not
* identity - reads Watchdog device's identity string.
* timeout - reads current timeout.
* timeleft - reads timeleft before watchdog generates a reset
* bootstatus - reads status of the watchdog device at boot
* status - reads watchdog device's internal status bits
* nowayout - reads whether nowayout feature was set or not
Testing with iTCO_wdt:
# cd /sys/class/watchdog/watchdog1/
# ls
bootstatus dev device identity nowayout power state
subsystem timeleft timeout uevent
# cat identity
iTCO_wdt
# cat timeout
30
# cat state
inactive
# echo > /dev/watchdog1
# cat timeleft
26
# cat state
active
# cat bootstatus
0
# cat nowayout
0
Signed-off-by: Pratyush Anand
---
Documentation/ABI/testing/sysfs-class-watchdog | 51
drivers/watchdog/watchdog_core.c | 2 +-
drivers/watchdog/watchdog_dev.c| 110 +
3 files changed, 162 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-watchdog
diff --git a/Documentation/ABI/testing/sysfs-class-watchdog
b/Documentation/ABI/testing/sysfs-class-watchdog
new file mode 100644
index ..736046b33040
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-watchdog
@@ -0,0 +1,51 @@
+What: /sys/class/watchdog/watchdogn/bootstatus
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains status of the watchdog
+ device at boot. It is equivalent to WDIOC_GETBOOTSTATUS of
+ ioctl interface.
+
+What: /sys/class/watchdog/watchdogn/identity
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains identity string of
+ watchdog device.
+
+What: /sys/class/watchdog/watchdogn/nowayout
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. While reading, it gives '1' if that
+ device supports nowayout feature else, it gives '0'.
+
+What: /sys/class/watchdog/watchdogn/state
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It gives active/inactive status of
+ watchdog device.
+
+What: /sys/class/watchdog/watchdogn/status
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains watchdog device's
+ internal status bits. It is equivalent to WDIOC_GETSTATUS
+ of ioctl interface.
+
+What: /sys/class/watchdog/watchdogn/timeleft
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It contains value of time left for
+ reset generation. It is equivalent to WDIOC_GETTIMELEFT of
+ ioctl interface.
+
+What: /sys/class/watchdog/watchdogn/timeout
+Date: August 2015
+Contact: Wim Van Sebroeck
+Description:
+ It is a read only file. It is read to know about current
+ value of timeout programmed.
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 47d38c5c3f9a..62666f021762 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -183,7 +183,7 @@ static int __watchdog_register_device(struct
watchdog_device *wdd)
devno = wdd->cdev.dev;
wdd->dev = device_create(watchdog_class, wdd->parent, devno,
- NULL, "watchdog%d", wdd->id);
+ wdd, "watchdog%d", wdd->id);
if (IS_ERR(wdd->dev)) {
watchdog_dev_unregister(wdd);
ida_simple_remove(_ida, id);
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 986282d44b90..cbac8f88f390 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -248,6 +248,115 @@ out_timeleft:
return err;
}
+static ssize_t nowayout_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct watchdog_device *wdd = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", !!test_bit(WDOG_NO_WAY_OUT, >status));
+}
+static DEVICE_ATTR_RO(nowayout);
+
+static ssize_t status_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct watchdog_device *wdd = dev_get_drvdata(dev);
+ ssize_t status;
+ unsigned int val;
+
+ status = watchdog_get_status(wdd, );
+ if (!status)
+ status = sprintf(buf, "%u\n", val);
+
+ return status;
+}
+static DEVICE_ATTR_RO(status);
+
+static
[PATCH V3 1/2] watchdog: Use static struct class watchdog_class in stead of pointer
We need few sysfs attributes to know different status of a watchdog device.
To do that, we need to associate .dev_groups with watchdog_class. So
convert it from pointer to static.
Putting this static struct in watchdog_dev.c, so that static device
attributes defined in that file can be attached to it.
Signed-off-by: Pratyush Anand
Suggested-by: Guenter Roeck
---
drivers/watchdog/watchdog_core.c | 15 ++-
drivers/watchdog/watchdog_core.h | 2 +-
drivers/watchdog/watchdog_dev.c | 26 ++
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 1a8059455413..47d38c5c3f9a 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -274,19 +274,9 @@ static int __init watchdog_deferred_registration(void)
static int __init watchdog_init(void)
{
- int err;
-
- watchdog_class = class_create(THIS_MODULE, "watchdog");
- if (IS_ERR(watchdog_class)) {
- pr_err("couldn't create class\n");
+ watchdog_class = watchdog_dev_init();
+ if (IS_ERR(watchdog_class))
return PTR_ERR(watchdog_class);
- }
-
- err = watchdog_dev_init();
- if (err < 0) {
- class_destroy(watchdog_class);
- return err;
- }
watchdog_deferred_registration();
return 0;
@@ -295,7 +285,6 @@ static int __init watchdog_init(void)
static void __exit watchdog_exit(void)
{
watchdog_dev_exit();
- class_destroy(watchdog_class);
ida_destroy(_ida);
}
diff --git a/drivers/watchdog/watchdog_core.h b/drivers/watchdog/watchdog_core.h
index 6c951418fca7..1c8d6b0e68c7 100644
--- a/drivers/watchdog/watchdog_core.h
+++ b/drivers/watchdog/watchdog_core.h
@@ -33,5 +33,5 @@
*/
extern int watchdog_dev_register(struct watchdog_device *);
extern int watchdog_dev_unregister(struct watchdog_device *);
-extern int __init watchdog_dev_init(void);
+extern struct class * __init watchdog_dev_init(void);
extern void __exit watchdog_dev_exit(void);
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefbad303e..986282d44b90 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -578,18 +578,35 @@ int watchdog_dev_unregister(struct watchdog_device
*watchdog)
return 0;
}
+static struct class watchdog_class = {
+ .name = "watchdog",
+ .owner =THIS_MODULE,
+};
+
/*
* watchdog_dev_init: init dev part of watchdog core
*
* Allocate a range of chardev nodes to use for watchdog devices
*/
-int __init watchdog_dev_init(void)
+struct class * __init watchdog_dev_init(void)
{
- int err = alloc_chrdev_region(_devt, 0, MAX_DOGS, "watchdog");
- if (err < 0)
+ int err;
+
+ err = class_register(_class);
+ if (err < 0) {
+ pr_err("couldn't register class\n");
+ return ERR_PTR(err);
+ }
+
+ err = alloc_chrdev_region(_devt, 0, MAX_DOGS, "watchdog");
+ if (err < 0) {
pr_err("watchdog: unable to allocate char dev region\n");
- return err;
+ class_unregister(_class);
+ return ERR_PTR(err);
+ }
+
+ return _class;
}
/*
@@ -601,4 +618,5 @@ int __init watchdog_dev_init(void)
void __exit watchdog_dev_exit(void)
{
unregister_chrdev_region(watchdog_devt, MAX_DOGS);
+ class_unregister(_class);
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Adi-buildroot-devel] [Consult] blackfin: About one building break issue for STACKTRACE
On 4/17/15 22:02, Chen Gang wrote: > On 4/17/15 11:02, Zhang, Sonic wrote: >> Hi Gang, >> >> Please only use the GCC for Blackfin 2013R1 or 2014R1 from >> https://sourceforge.net/projects/adi-buildroot/files/ . Upstream GCC5 isn't >> ported to Blackfin properly. >> I shall try to merge the 2014R1 to the latest gcc upstream to support the related feature in my free time. I hope I can finish within 2 months (although I am not quite sure -- maybe need 3 months or more). Welcome any related ideas, suggestions and completions. Thanks. > > OK, thank you very much for your reply. :-) > > > For me, I want to let gcc5 support Blackfin properly, but sorry, at > present I can not. > > - In honest, I am still not quite familiar with gcc (although I am >trying and improving). > > - This year, I have no enough time resource for it (I am mainly for >upstream qemu this year). > > But if next year, upstream gcc is still not ported to Blackfin properly, > I shall try. > > However, there are still several another issues for upstream blackfin > gcc5 (they are all coredumps), I should still try to analyze them and > find root causes, hope I can finish within this month. > > > Thanks. > -- Chen Gang (陈刚) Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Firmware Signing
On Thu, 2015-09-03 at 02:29 +0200, Luis R. Rodriguez wrote: > On Wed, Sep 02, 2015 at 08:05:36PM -0400, Mimi Zohar wrote: > > On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote: > > > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote: > > > We want something that is not only useful for IMA but any other LSM, > > > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon > > > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might > > > be broad, perhaps its best we define then a generic set of enums to > > > which IMA can map them to then and let it decide. This would ensure > > > that the kernel defines each use caes for file inspection carefully, > > > documents and defines them and if an LSM wants to bunch a set together > > > it can do so easily with a switch statement to map set of generic > > > file checks in kernel to a group it already handles. > > > > The names are based on the calling security hook. For a description of > > each of these security hooks refer to include/linux/lsm_hooks.h. > > I see, thanks, ok so BPRM_CHECK = for binary loading, are you folks > really wanting to unify LSM hooks for firmware, modules, and binary > data ? You're asking me?! From my point of view that it is already unified. The same mechanism used for appraising files in general could be used for appraising those mentioned. :) The main issue is having the file data and metadata (eg. signatures) distributed together. Thanks to Fionnula and Florian support for including file signatures in rpm packages was released today - http://lists.rpm.org/pipermail/rpm-maint/2015-September/003962.html. > POST_SETATTR seems to be for inode_post_setxattr, so that as well? No. The IMA policy rules can be defined in terms of file metadata (eg. uid). Changing the file metadata might result in files that previously weren't appraised, now need to be appraised. The EVM security xattr is an hmac of the file metadata. So that needs to be updated to reflect the change. > POLICY_CHECK seems broad, not sure what to relate that to exactly. > Is this just SELinux polify files? Or is this something more broad? This hook is currently limited to verifying the IMA policy signature, but could be the basis for a more generalized hook. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] cpufreq-dt: add suspend frequency support
On 02-09-15, 11:03, Stephen Boyd wrote: > On 09/02/2015 09:47 AM, Bartlomiej Zolnierkiewicz wrote: > > Add suspend frequency support and set it to the boot frequency, > > this matches what the old exynos-cpufreq driver has been doing. > > > > This patch fixes suspend/resume support on Exynos4412 based > > Trats2 board and reboot hang on Exynos4412 based Odroid U3 > > board. > > > > Cc: Viresh Kumar > > Cc: Thomas Abraham > > Cc: Javier Martinez Canillas > > Cc: Krzysztof Kozlowski > > Cc: Marek Szyprowski > > Cc: Tobias Jakobi > > Signed-off-by: Bartlomiej Zolnierkiewicz > > --- > > This patch supersedes "[PATCH] ARM: dts: exynos4412-odroid-*: add > > workaround for CPUfreq/reboot issue" one from yesterday. > > What do we do about cpufreq-dt users that don't want to change frequency > during suspend? Again, this should be done via opp-v2 suspend-opp feature instead. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: hid-lg: Add USBID for Logitech G29 Wheel
> I do not have this wheel to test with, but this should at least get it
> working in emulation mode.
>
> Note: There is probably more work required for adjust HID descriptor and
> handle switching between emulation and native modes.
I was able to get some more information, but as yet have not been able to
get time on the real hardware. Attached is a 2nd patch which should
improve the support, I'll formally submit it next week But if anyone
can test it first that would be great.
There's a pre-built Debian/Ubuntu kernel here:
https://dl.dropboxusercontent.com/u/34518077/linux-headers-4.2.0-g29%2B_20150831_i386.deb
https://dl.dropboxusercontent.com/u/34518077/linux-image-4.2.0-g29%2B_20150831_i386.deb
The wheel will need to be in PS3 mode set with switch behind LEDs, and
should connect first as a DF-EX (220' turn) and then automatically
reconnect as G29 (900' turn).
The mode should be selectable something like
--
root@retrobox:/home/simon# cd /sys/bus/hid/devices/0003\:046D\:C29B.0002
root@retrobox:/sys/bus/hid/devices/0003:046D:C29B.0002# ls
alternate_modes country driver hidraw input leds modalias power
range real_id report_descriptor subsystem uevent
root@retrobox:/sys/bus/hid/devices/0003:046D:C29B.0002# cat alternate_modes
native: G27 Racing Wheel *
DF-EX: Driving Force / Formula EX
DFP: Driving Force Pro
G25: G25 Racing Wheel
G27: G27 Racing Wheel *
root@retrobox:/sys/bus/hid/devices/0003:046D:C29B.0002# echo G25 >
alternate_modes
--
The LEDs should also work
--
root@retrobox:/home/simon/linux-git# cd /sys/class/leds/
root@retrobox:/sys/class/leds# ls
0003:046D:C29B.0005::RPM1 0003:046D:C29B.0005::RPM4 input3::numlock
tpacpi::power tpacpi::thinkvantage
0003:046D:C29B.0005::RPM2 0003:046D:C29B.0005::RPM5 input3::scrolllock
tpacpi::standby
0003:046D:C29B.0005::RPM3 input3::capslock phy0-led
tpacpi::thinklight
root@retrobox:/sys/class/leds# echo 1 >
0003\:046D\:C29B.0005\:\:RPM1/brightness
--
Cheers,
Simondiff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e6fce23..2e9c706 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1874,6 +1874,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD2_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G29_WHEEL) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WINGMAN_F3D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_WINGMAN_FFG ) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_FORCE3D_PRO) },
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 02cec83..d0c3da5 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -45,7 +45,8 @@
#define LG4FF_MODE_G25_IDX 3
#define LG4FF_MODE_DFGT_IDX 4
#define LG4FF_MODE_G27_IDX 5
-#define LG4FF_MODE_MAX_IDX 6
+#define LG4FF_MODE_G29_IDX 6
+#define LG4FF_MODE_MAX_IDX 7
#define LG4FF_MODE_NATIVE BIT(LG4FF_MODE_NATIVE_IDX)
#define LG4FF_MODE_DFEX BIT(LG4FF_MODE_DFEX_IDX)
@@ -53,6 +54,7 @@
#define LG4FF_MODE_G25 BIT(LG4FF_MODE_G25_IDX)
#define LG4FF_MODE_DFGT BIT(LG4FF_MODE_DFGT_IDX)
#define LG4FF_MODE_G27 BIT(LG4FF_MODE_G27_IDX)
+#define LG4FF_MODE_G29 BIT(LG4FF_MODE_G29_IDX)
#define LG4FF_DFEX_TAG "DF-EX"
#define LG4FF_DFEX_NAME "Driving Force / Formula EX"
@@ -62,6 +64,8 @@
#define LG4FF_G25_NAME "G25 Racing Wheel"
#define LG4FF_G27_TAG "G27"
#define LG4FF_G27_NAME "G27 Racing Wheel"
+#define LG4FF_G29_TAG "G29"
+#define LG4FF_G29_NAME "G29 Racing Wheel"
#define LG4FF_DFGT_TAG "DFGT"
#define LG4FF_DFGT_NAME "Driving Force GT"
@@ -144,6 +148,7 @@ static const struct lg4ff_wheel lg4ff_devices[] = {
{USB_DEVICE_ID_LOGITECH_G25_WHEEL, lg4ff_wheel_effects, 40, 900, lg4ff_set_range_g25},
{USB_DEVICE_ID_LOGITECH_DFGT_WHEEL, lg4ff_wheel_effects, 40, 900, lg4ff_set_range_g25},
{USB_DEVICE_ID_LOGITECH_G27_WHEEL, lg4ff_wheel_effects, 40, 900, lg4ff_set_range_g25},
+ {USB_DEVICE_ID_LOGITECH_G29_WHEEL, lg4ff_wheel_effects, 40, 900, lg4ff_set_range_g25},
{USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2, lg4ff_wheel_effects, 40, 270, NULL},
{USB_DEVICE_ID_LOGITECH_WII_WHEEL, lg4ff_wheel_effects, 40, 270, NULL}
};
@@ -161,6 +166,9 @@ static const struct lg4ff_multimode_wheel lg4ff_multimode_wheels[] = {
{USB_DEVICE_ID_LOGITECH_G27_WHEEL,
LG4FF_MODE_NATIVE | LG4FF_MODE_G27 | LG4FF_MODE_G25 | LG4FF_MODE_DFP | LG4FF_MODE_DFEX,
LG4FF_G27_TAG, LG4FF_G27_NAME},
+ {USB_DEVICE_ID_LOGITECH_G29_WHEEL,
+ LG4FF_MODE_NATIVE | LG4FF_MODE_G29 | LG4FF_MODE_DFGT | LG4FF_MODE_DFP,
+ LG4FF_G29_TAG, LG4FF_G29_NAME},
};
static const struct lg4ff_alternate_mode lg4ff_alternate_modes[] = {
@@ -169,7 +177,8 @@ static const struct lg4ff_alternate_mode
Re: [PATCH] cpufreq-dt: add suspend frequency support
On 02-09-15, 18:42, Bartlomiej Zolnierkiewicz wrote: > Add suspend frequency support and set it to the boot frequency, > this matches what the old exynos-cpufreq driver has been doing. > > This patch fixes suspend/resume support on Exynos4412 based > Trats2 board and reboot hang on Exynos4412 based Odroid U3 > board. > > Cc: Viresh Kumar > Cc: Thomas Abraham > Cc: Javier Martinez Canillas > Cc: Krzysztof Kozlowski > Cc: Marek Szyprowski > Cc: Tobias Jakobi > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > This patch supersedes "[PATCH] ARM: dts: exynos4412-odroid-*: add > workaround for CPUfreq/reboot issue" one from yesterday. > > drivers/cpufreq/cpufreq-dt.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c > index c3583cd..c9138c7 100644 > --- a/drivers/cpufreq/cpufreq-dt.c > +++ b/drivers/cpufreq/cpufreq-dt.c > @@ -329,6 +329,10 @@ static int cpufreq_init(struct cpufreq_policy *policy) > policy->driver_data = priv; > > policy->clk = cpu_clk; > + > + /* capture boot frequency */ > + policy->suspend_freq = clk_get_rate(cpu_clk) / 1000;; We should be using opp-v2's suspend-opp thing for this now.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup
On Mon, Aug 31, 2015 at 11:05:33AM -0500, Stuart Hayes wrote: > Increase the range of chunk sizes tried in mtrr_cleanup() so it is able > to map large memory configs into MTRRs. > > Currently, mtrr_cleanup() will fail with large memory configurations, > because it limits chunk_size to 2GB, which means that each MTRR can only > cover 2GB of memory. With a memory size of, say, 256GB, and ten variable > MTRRs (such as some recent Intel CPUs have), it is not possible to set up > the MTRRs to cover all of memory. Linux drivers no longer use MTRR so why is the cleanup needed, ie, what would happen if the cleanup is just skipped in your case ? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Re: [PATCH 14/31] perf tools: Suppress probing messages when probing by BPF loading
> From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim
>
> On Sat, Aug 29, 2015 at 04:21:48AM +, Wang Nan wrote:
> > This patch suppresses message output by add_perf_probe_events() and
> > del_perf_probe_events() if they are triggered by BPF loading. Before
> > this patch, when using 'perf record' with BPF object/source as event
> > selector, following message will be output:
> >
> > Added new event:
> >perf_bpf_probe:lock_page_ret (on __lock_page%return)
> > You can now use it in all perf tools, such as:
> > perf record -e perf_bpf_probe:lock_page_ret -aR sleep 1
> > ...
> > Removed event: perf_bpf_probe:lock_page_ret
> >
> > Which is misleading, especially 'use it in all perf tools' because they
> > will be removed after 'pref record' exit.
> >
> > In this patch, a 'silent' field is appended into probe_conf to control
> > output. bpf__{,un}probe() set it to true when calling
> > {add,del}_perf_probe_events().
>
> I think that printing those messages should be done in cmd_probe()
> rather than add/del_perf_probe_events()..
Well... try to cleanup the messages.
Thanks!
>
[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
default value of vmalloc_min was set 0xf000 for ARM by commit
0536bdf3. But actually vmalloc_min is 0xef80 not 0xf000.
VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff00 - 0x0f00 - 0x0080 = 0xef80
In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 8000-afff to -af7f (vmalloc region overlap)."
Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.
Signed-off-by: Yongtaek Lee
---
arch/arm/mm/mmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
#endif
static void * __initdata vmalloc_min =
- (void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+ (void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
/*
* vmalloc=size forces the vmalloc area to be exactly 'size'
* bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
*/
static int __init early_vmalloc(char *arg)
{
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf: bug, kernel ignores the buffer size on large read
On Thu, 3 Sep 2015, Peter Zijlstra wrote: > I think we should try and just ban events with a read_size > 64k; that's > one _large_ group -- there's other issues with that as well I imagine. yes, I don't really have a use case for this, I just noticed the problem because Debian apparently bumped the default file descriptor limit from 1k to 64k and suddenly some of my perf_event_test suite started failing in interesting ways. The limit for read() would come down to about 4k events per group assuming you also have ID enabled. The complication is that header_size is calculated similarly and lots of other things get added in, and a lot of it is done with u16 math. So I have no idea if there's a possibility for creating sampled events that can corrupt the mmap buffer. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcieport AER error spam on Intel Skylake
On 09/02/2015 03:53 PM, Bjorn Helgaas wrote: On Wed, Sep 2, 2015 at 5:01 PM, Daniel Drake wrote: Hi, Working with a sample for a new laptop based on Intel Skylake, the kernel logs are full of these messages: pcieport :00:1c.5: AER: Corrected error received: id=00e5 pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e5(Receiver ID) pcieport :00:1c.5: device [8086:9d15] error status/mask=0001/2000 pcieport :00:1c.5:[ 0] Receiver Error (First) pcieport :00:1c.5: AER: Corrected error received: id=00e5 pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e5(Receiver ID) pcieport :00:1c.5: device [8086:9d15] error status/mask=0001/2000 pcieport :00:1c.5:[ 0] Receiver Error (First) pcieport :00:1c.5: AER: Corrected error received: id=00e5 pcieport :00:1c.5: can't find device of ID00e5 Reproduced on 4.2 and on linus master as of today, using x86_64_defconfig. Apart from the log spam, there is no user-visible effect that I'm aware of. Booting with pci=nomsi makes the messages go away. Any thoughts, is this something worth looking into in more detail? full dmesg: https://gist.github.com/dsd/1d7f738e917465edf2ae lspci dump: https://gist.github.com/dsd/dc2481d64aadd520b0b3 Thanks, Daniel, this is indeed really annoying and worth looking into. Do you happen to know whether it's a regression? We haven't changed much in AER recently, but it's possible we broke something. Even if it's not a regression, the output seems a bit wordy and redundant. Bjorn Since it is correctable errors it is likely some sort of signalling issue. Could we get the output of something like an lspci -vt? Then you would be able to tell what the device is on the other side of the link from 00:1c.5 and then we could probably check to see if there has been any changes for the device driver on the other end of the link. My suspicion since this is a laptop is that something like a power management change might be responsible if this is a regression as I have seen messages like this pop up as a result of ASPM being enabled before. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] scsi:stex.c Add S3/S4 support
From 7d98f8c500de452277e2700a950b23bf4685ed64 Mon Sep 17 00:00:00 2001
From: Charles
Date: Wed, 2 Sep 2015 20:54:45 +0800
Subject: [PATCH 3/3] scsi:stex.c Add S3/S4 support
Add S3/S4 support, add .suspend and .resume function in pci_driver.
In .suspend handler, driver send S3/S4 signal to the device.
Signed-off-by: Charles Chiou
---
drivers/scsi/stex.c | 65
++---
1 file changed, 62 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 6578f3d..45482d5 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -166,6 +166,13 @@ enum {
ST_ADDITIONAL_MEM = 0x20,
ST_ADDITIONAL_MEM_MIN = 0x8,
+ PMIC_SHUTDOWN = 0x0D,
+ PMIC_REUMSE = 0x10,
+ ST_IGNORED = -1,
+ ST_S3 = 3,
+ ST_S4 = 4,
+ ST_S5 = 5,
+ ST_S6 = 6,
};
struct st_sgitem {
@@ -360,6 +367,8 @@ static const char console_inq_page[] =
0x0C,0x20,0x20,0x20,0x20,0x20,0x20,0x20
};
+
+
MODULE_AUTHOR("Ed Lin");
MODULE_DESCRIPTION("Promise Technology SuperTrak EX Controllers");
MODULE_LICENSE("GPL");
@@ -1359,6 +1368,9 @@ static void stex_reset_work(struct work_struct *work)
stex_do_reset(hba);
}
+
+
+
static int stex_biosparam(struct scsi_device *sdev,
struct block_device *bdev, sector_t capacity, int geom[])
{
@@ -1736,7 +1748,7 @@ out_disable:
return err;
}
-static void stex_hba_stop(struct st_hba *hba)
+static void stex_hba_stop(struct st_hba *hba, int st_sleep_mic)
{
struct req_msg *req;
struct st_msg_header *msg_h;
@@ -1752,11 +1764,18 @@ static void stex_hba_stop(struct st_hba *hba)
} else
memset(req, 0, hba->rq_size);
- if (hba->cardtype == st_yosemite || hba->cardtype == st_yel) {
+ if ((hba->cardtype == st_yosemite || hba->cardtype == st_yel)
+ && st_sleep_mic == ST_IGNORED) {
req->cdb[0] = MGT_CMD;
req->cdb[1] = MGT_CMD_SIGNATURE;
req->cdb[2] = CTLR_CONFIG_CMD;
req->cdb[3] = CTLR_SHUTDOWN;
+ } else if (hba->cardtype == st_yel && st_sleep_mic != ST_IGNORED) {
+ req->cdb[0] = MGT_CMD;
+ req->cdb[1] = MGT_CMD_SIGNATURE;
+ req->cdb[2] = CTLR_CONFIG_CMD;
+ req->cdb[3] = PMIC_SHUTDOWN;
+ req->cdb[4] = st_sleep_mic;
} else {
req->cdb[0] = CONTROLLER_CMD;
req->cdb[1] = CTLR_POWER_STATE_CHANGE;
@@ -1776,10 +1795,12 @@ static void stex_hba_stop(struct st_hba *hba)
while (hba->ccb[tag].req_type & PASSTHRU_REQ_TYPE) {
if (time_after(jiffies, before + ST_INTERNAL_TIMEOUT * HZ)) {
hba->ccb[tag].req_type = 0;
+ hba->mu_status = MU_STATE_STOP;
return;
}
msleep(1);
}
+ hba->mu_status = MU_STATE_STOP;
}
static void stex_hba_free(struct st_hba *hba)
@@ -1819,9 +1840,45 @@ static void stex_shutdown(struct pci_dev *pdev)
{
struct st_hba *hba = pci_get_drvdata(pdev);
- stex_hba_stop(hba);
+ if (hba->supports_pm == 0)
+ stex_hba_stop(hba, ST_IGNORED);
+ else
+ stex_hba_stop(hba, ST_S5);
+}
+
+static int stex_choice_sleep_mic(pm_message_t state)
+{
+ switch (state.event) {
+ case PM_EVENT_SUSPEND:
+ return ST_S3;
+ case PM_EVENT_FREEZE:
+ case PM_EVENT_HIBERNATE:
+ return ST_S4;
+ default:
+ return ST_S4;
+ }
+}
+
+static int stex_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct st_hba *hba = pci_get_drvdata(pdev);
+
+ if (hba->cardtype == st_yel && hba->supports_pm == 1)
+ stex_hba_stop(hba, stex_choice_sleep_mic(state));
+ else
+ stex_hba_stop(hba, ST_IGNORED);
+ return 0;
}
+
+static int stex_resume(struct pci_dev *pdev)
+{
+ struct st_hba *hba = pci_get_drvdata(pdev);
+
+ hba->mu_status = MU_STATE_STARTING;
+ stex_handshake(hba);
+ return 0;
+}
MODULE_DEVICE_TABLE(pci, stex_pci_tbl);
static struct pci_driver stex_pci_driver = {
@@ -1830,6 +1887,8 @@ static struct pci_driver stex_pci_driver = {
.probe = stex_probe,
.remove = stex_remove,
.shutdown = stex_shutdown,
+ .suspend= stex_suspend,
+ .resume = stex_resume,
};
static int __init stex_init(void)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH 2/4] scsi:stex.c Add hotplug support
From 9f6cf26367419ed746c6c0f4e80fad6066b99d06 Mon Sep 17 00:00:00 2001
From: Charles
Date: Wed, 2 Sep 2015 20:48:55 +0800
Subject: [PATCH 2/3] scsi:stex.c Add hotplug support
1. Add hotplug support. Pegasus support surprise removal. To this end, I
use return_abnormal_state function to return DID_NO_CONNECT for all
commands which sent to driver.
2. Remove stex_hba_stop in stex_remove because we cannot send command to
device after hotplug.
3. Add new device status: MU_STATE_STOP, MU_STATE_NOCONNECT,
MU_STATE_STOP. MU_STATE_STOP is currently not referenced.
MU_STATE_NOCONNECT represent that device is plugged out from the host.
4. Use return_abnormal_function() to substitute part of code in
stex_do_reset.
Signed-off-by: Charles Chiou
---
drivers/scsi/stex.c | 53
++---
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 657e3ae..6578f3d 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -83,6 +83,8 @@ enum {
MU_STATE_STARTED= 2,
MU_STATE_RESETTING = 3,
MU_STATE_FAILED = 4,
+ MU_STATE_STOP = 5,
+ MU_STATE_NOCONNECT = 6,
MU_MAX_DELAY= 120,
MU_HANDSHAKE_SIGNATURE = 0x5555,
@@ -544,6 +546,27 @@ stex_ss_send_cmd(struct st_hba *hba, struct req_msg
*req, u16 tag)
readl(hba->mmio_base + YH2I_REQ); /* flush */
}
+static void return_abnormal_state(struct st_hba *hba, int status)
+{
+ struct st_ccb *ccb;
+ unsigned long flags;
+ u16 tag;
+
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ for (tag = 0; tag < hba->host->can_queue; tag++) {
+ ccb = >ccb[tag];
+ if (ccb->req == NULL)
+ continue;
+ ccb->req = NULL;
+ if (ccb->cmd) {
+ scsi_dma_unmap(ccb->cmd);
+ ccb->cmd->result = status << 16;
+ ccb->cmd->scsi_done(ccb->cmd);
+ ccb->cmd = NULL;
+ }
+ }
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+}
static int
stex_slave_config(struct scsi_device *sdev)
{
@@ -567,8 +590,12 @@ stex_queuecommand_lck(struct scsi_cmnd *cmd, void
(*done)(struct scsi_cmnd *))
id = cmd->device->id;
lun = cmd->device->lun;
hba = (struct st_hba *) >hostdata[0];
-
- if (unlikely(hba->mu_status == MU_STATE_RESETTING))
+ if (hba->mu_status == MU_STATE_NOCONNECT) {
+ cmd->result = DID_NO_CONNECT;
+ done(cmd);
+ return 0;
+ }
+ if (unlikely(hba->mu_status != MU_STATE_STARTED))
return SCSI_MLQUEUE_HOST_BUSY;
switch (cmd->cmnd[0]) {
@@ -1267,10 +1294,8 @@ static void stex_ss_reset(struct st_hba *hba)
static int stex_do_reset(struct st_hba *hba)
{
- struct st_ccb *ccb;
unsigned long flags;
unsigned int mu_status = MU_STATE_RESETTING;
- u16 tag;
spin_lock_irqsave(hba->host->host_lock, flags);
if (hba->mu_status == MU_STATE_STARTING) {
@@ -1304,20 +1329,8 @@ static int stex_do_reset(struct st_hba *hba)
else if (hba->cardtype == st_yel)
stex_ss_reset(hba);
- spin_lock_irqsave(hba->host->host_lock, flags);
- for (tag = 0; tag < hba->host->can_queue; tag++) {
- ccb = >ccb[tag];
- if (ccb->req == NULL)
- continue;
- ccb->req = NULL;
- if (ccb->cmd) {
- scsi_dma_unmap(ccb->cmd);
- ccb->cmd->result = DID_RESET << 16;
- ccb->cmd->scsi_done(ccb->cmd);
- ccb->cmd = NULL;
- }
- }
- spin_unlock_irqrestore(hba->host->host_lock, flags);
+
+ return_abnormal_state(hba, DID_RESET);
if (stex_handshake(hba) == 0)
return 0;
@@ -1789,9 +1802,11 @@ static void stex_remove(struct pci_dev *pdev)
{
struct st_hba *hba = pci_get_drvdata(pdev);
+ hba->mu_status = MU_STATE_NOCONNECT;
+ return_abnormal_state(hba, DID_NO_CONNECT);
scsi_remove_host(hba->host);
- stex_hba_stop(hba);
+ scsi_block_requests(hba->host);
stex_hba_free(hba);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit
On Wed, Sep 2, 2015 at 6:44 PM, Luis R. Rodriguez wrote: >> I don't think we really need to spell it out here. s390 PCI is different >> from everybody else's in a lot of ways, so a simple 'depends on PCI && >> !S390' for CONFIG_PCI_IOMAP seems simpler and more intuitive. > > Sure that would work as well. But on second thought it still would leave us reactive to S390, this solution would get folks extending this asm-generic stuff to also have something in place for S390, even if its just returning NULL. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The tick when exit idle for nohz_full cpu
Hi, Frederic
I noticed currently the tick_nohz_idle_exit() will always restart the
sched_tick, even when it's on the nohz_full cpu. I'm not sure if we can keep
the sched_tick stopped if it's on a nohz_full_cpu. The sched tick will be
enabled on tick_nohz_task_switch() if needed. Is it ok to keep the sched tick
off in the scheduling process?
Something like followed patch (just to show the idea).
Thanks
--jyh
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3319e16..7519a0f 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -909,8 +909,9 @@ void tick_nohz_idle_exit(void)
tick_nohz_stop_idle(ts, now);
if (ts->tick_stopped) {
- tick_nohz_restart_sched_tick(ts, now);
tick_nohz_account_idle_ticks(ts);
+ if (!tick_nohz_full_cpu(smp_processor_id()))
+ tick_nohz_restart_sched_tick(ts, now);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] scsi:stex.c Support to Pegasus series.
From 63f806abc43237285a918f559ce6e5e410d90d85 Mon Sep 17 00:00:00 2001
From: Charles
Date: Wed, 2 Sep 2015 20:41:56 +0800
Subject: [PATCH 1/3] scsi:stex.c Support to Pegasus series.
Pegasus is a high performace hardware RAID solution designed to unleash
the raw power of Thunderbolt technology.
1. Add code to distinct SuperTrack and Pegasus series by sub device ID.
It should support backward compatibility.
2. Change the driver version.
Signed-off-by: Charles Chiou
---
drivers/scsi/stex.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 98a62bc..657e3ae 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1,7 +1,7 @@
/*
* SuperTrak EX Series Storage Controller driver for Linux
*
- * Copyright (C) 2005-2009 Promise Technology Inc.
+ * Copyright (C) 2005-2015 Promise Technology Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -37,11 +37,11 @@
#include
#define DRV_NAME "stex"
-#define ST_DRIVER_VERSION "4.6..4"
-#define ST_VER_MAJOR 4
-#define ST_VER_MINOR 6
-#define ST_OEM 0
-#define ST_BUILD_VER 4
+#define ST_DRIVER_VERSION "5.00..01"
+#define ST_VER_MAJOR 5
+#define ST_VER_MINOR 00
+#define ST_OEM
+#define ST_BUILD_VER 01
enum {
/* MU register offset */
@@ -327,6 +327,7 @@ struct st_hba {
u16 rq_count;
u16 rq_size;
u16 sts_count;
+ u8 supports_pm;
};
struct st_card_info {
@@ -1566,8 +1567,30 @@ static int stex_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
goto out_iounmap;
}
+
+
+
hba->cardtype = (unsigned int) id->driver_data;
ci = _card_info[hba->cardtype];
+ switch (id->subdevice) {
+ case 0x4221:
+ case 0x4222:
+ case 0x4223:
+ case 0x4224:
+ case 0x4225:
+ case 0x4226:
+ case 0x4227:
+ case 0x4261:
+ case 0x4262:
+ case 0x4263:
+ case 0x4264:
+ case 0x4265:
+ break;
+ default:
+ if (hba->cardtype == st_yel)
+ hba->supports_pm = 1;
+ }
+
sts_offset = scratch_offset = (ci->rq_count+1) * ci->rq_size;
if (hba->cardtype == st_yel)
sts_offset += (ci->sts_count+1) * sizeof(u32);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit
On Sat, Aug 29, 2015 at 08:25:05AM -0700, Christoph Hellwig wrote: > On Fri, Aug 28, 2015 at 05:17:27PM -0700, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" > > > > The S390 architecture requires a custom pci_iomap() implementation > > as the asm-generic implementation assumes there are disjunctions > > between PCI BARs, and on S390 PCI BAR are not disjunctive, S390 requires > > the bar parameter in order to find the corresponding device and create > > the mapping cookie. > > > > This clash with the asm-generic pci_iomap() implementation is implicit, > > there are no current semantics to make this incompatability explicit. > > Make the S390 PCI BAR non-disjunction incompatibility explicit, and > > also pave the way for alternative incompatibilities to be defined. > > > > While at it, as with the ioremap*() variants, since we have no clear > > semantics yet well defined provide a solution for them that returns > > NULL. This allows architectures to move forward by defining pci_ioremap*() > > variants without requiring immediate changes to all architectures. Each > > architecture then can implement their own solution as needed and > > when they get to it. > > Now that you have the config symbol available why not move the S390 > implementation to generic code based on that can kill of > asm/pci_iomap.h? Seems like we're really not dealing with something > inherent to the architecture, but two possible implementations based > on architecture constraints. That would be the other approach to take too, but perhaps that can wait until yet another architecture with similar requirement pops up. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit
On Sun, Aug 30, 2015 at 09:30:26PM +0200, Arnd Bergmann wrote: > On Friday 28 August 2015 17:17:27 Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" > > > > The S390 architecture requires a custom pci_iomap() implementation > > as the asm-generic implementation assumes there are disjunctions > > between PCI BARs, and on S390 PCI BAR are not disjunctive, S390 requires > > the bar parameter in order to find the corresponding device and create > > the mapping cookie. > > > > This clash with the asm-generic pci_iomap() implementation is implicit, > > there are no current semantics to make this incompatability explicit. > > Make the S390 PCI BAR non-disjunction incompatibility explicit, and > > also pave the way for alternative incompatibilities to be defined. > > I don't think we really need to spell it out here. s390 PCI is different > from everybody else's in a lot of ways, so a simple 'depends on PCI && > !S390' for CONFIG_PCI_IOMAP seems simpler and more intuitive. Sure that would work as well. > > While at it, as with the ioremap*() variants, since we have no clear > > semantics yet well defined provide a solution for them that returns > > NULL. This allows architectures to move forward by defining pci_ioremap*() > > variants without requiring immediate changes to all architectures. Each > > architecture then can implement their own solution as needed and > > when they get to it. > > Which architectures are you thinking about here? Really only S390 would benefit from this now. > > Build tested with allyesconfig on: > > > > * S390 > > * x86_64 > > > > Signed-off-by: Luis R. Rodriguez > > It's not really clear to me what the purpose of the patch is, is this > meant as a cleanup, or are you trying to avoid some real-life bugs > you ran into? Upon adding a new helper into CONFIG_PCI_IOMAP it was only through 0-day build testing that I found that I needed to add something for S390. This means we fix S390 reactively. With the asm-generic stuff in place to return NULL we don't need to do anything but a respective return NULL static inline, the moment that is done the author would know some architectures may not get support for the functionality they are adding. Without this we only find out reactively. > > This came up as an idea after noting that S390 has no way to be > > explicit about its requirements, this also means we don't have a > > quick easy way to ensure that other architectures might have a > > conflict as well. This provides an easy way to do that by having > > the architectures define their incompatibilities and allowing those > > then to negate GENERIC_PCI_IOMAP on lib/Kconfig. > > PCI_IOMAP seems much simpler than ioport_map here, as a lot of > architectures can have overlapping port numbers across PCI host > bridges. Sure, agreed. > > I think a next cleanup could be the move of the pci_iounmap() out to > > pci_iomap.h to avoid having each arch having to declare it. That's > > a separate atomic change though so should go in separately. > > pci_iounmap() is rather tricky, and I think some architectures currently > get it wrong Whoops. > and will actually unmap parts of the I/O port ranges from > the PCI host controller mapping. It might be rare enough that it never > caused problems (that got reported), but it might be nice to actually > provide an implementation that has a chance of working. Sure. > The version from lib/iomap.c seems correct for uses of CONFIG_GENERIC_IOMAP, > but most architectures can do better without that option. By do better do you mean a more optimized solution ? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] firmware: annotate thou shalt not request fw on init or probe
On Tue, Sep 01, 2015 at 01:28:27PM -0400, Josh Boyer wrote: > On Fri, Aug 28, 2015 at 9:18 PM, Luis R. Rodriguez > wrote: > > From: "Luis R. Rodriguez" > > > > We are phasing out the usermode helper from the kernel, > > systemd already ripped support for this a while ago, the > > only remaining valid user is the Dell rbu driver. The > > Actually, I don't think that is accurate any longer. The Dell rbu > driver certainly requires this, but it seems that the following > drivers select FW_LOADER_USER_HELPER_FALLBACK as well: > > CONFIG_DRM_STI > CONFIG_LEDS_LP55XX_COMMON > > Why they do that, I have no idea. It's kind of disappointing. What The Flying-hipster-typewriters! Indeed. With more reason to put the user mode helper to sleep sooner rather than later. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] staging/wilc1000: Use %pM format specifier to print mac address
On Thu, Aug 27, 2015 at 07:10:48PM +0600, Alexander Kuleshov wrote:
> printk() supports %pM format specifier for printing 6-byte MAC/FDDI
> addresses in hex notation small buffers, let's use it intead of %x:%x...
>
> Signed-off-by: Alexander Kuleshov
> ---
> drivers/staging/wilc1000/host_interface.c | 6 +++---
> drivers/staging/wilc1000/linux_mon.c | 2 +-
> drivers/staging/wilc1000/linux_wlan.c | 3 +--
> 3 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c
> index 6b10bbb..48ee908 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -854,7 +854,7 @@ static s32 Handle_SetMacAddress(void *drvHandler,
> tstrHostIfSetMacAddress *pstrH
> strWID.enuWIDtype = WID_STR;
> strWID.ps8WidVal = mac_buf;
> strWID.s32ValueSize = ETH_ALEN;
> - PRINT_D(GENERIC_DBG, "mac addr = :%x:%x:%x:%x:%x:%x\n",
> strWID.ps8WidVal[0], strWID.ps8WidVal[1], strWID.ps8WidVal[2],
> strWID.ps8WidVal[3], strWID.ps8WidVal[4], strWID.ps8WidVal[5]);
> + PRINT_D(GENERIC_DBG, "mac addr = :%pM\n", strWID.ps8WidVal);
> /*Sending Cfg*/
> s32Error = SendConfigPkt(SET_CFG, , 1, true, (u32)pstrWFIDrv);
> if (s32Error) {
> @@ -1965,8 +1965,8 @@ static s32 Handle_Connect(void *drvHandler,
> tstrHostIFconnectAttr *pstrHostIFcon
> if (pstrHostIFconnectAttr->pu8bssid != NULL) {
> WILC_memcpy(u8ConnectedSSID, pstrHostIFconnectAttr->pu8bssid,
> ETH_ALEN);
>
> - PRINT_D(GENERIC_DBG, "save Bssid = %x:%x:%x:%x:%x:%x\n",
> (pstrHostIFconnectAttr->pu8bssid[0]), (pstrHostIFconnectAttr->pu8bssid[1]),
> (pstrHostIFconnectAttr->pu8bssid[2]), (pstrHostIFconnectAttr->pu8bssid[3]),
> (pstrHostIFconnectAttr->pu8bssid[4]), (pstrHostIFconnectAttr->pu8bssid[5]));
> - PRINT_D(GENERIC_DBG, "save bssid = %x:%x:%x:%x:%x:%x\n",
> (u8ConnectedSSID[0]), (u8ConnectedSSID[1]), (u8ConnectedSSID[2]),
> (u8ConnectedSSID[3]), (u8ConnectedSSID[4]), (u8ConnectedSSID[5]));
> + PRINT_D(GENERIC_DBG, "save Bssid = %pM\n",
> pstrHostIFconnectAttr->pu8bssid);
> + PRINT_D(GENERIC_DBG, "save bssid = %pM\n", u8ConnectedSSID);
> }
>
> s32Error = SendConfigPkt(SET_CFG, strWIDList, u32WidsCount, false,
> (u32)pstrWFIDrv);
> diff --git a/drivers/staging/wilc1000/linux_mon.c
> b/drivers/staging/wilc1000/linux_mon.c
> index f5296f5..c039898 100644
> --- a/drivers/staging/wilc1000/linux_mon.c
> +++ b/drivers/staging/wilc1000/linux_mon.c
> @@ -336,7 +336,7 @@ static netdev_tx_t WILC_WFI_mon_xmit(struct sk_buff *skb,
> skb_pull(skb, rtap_len);
>
> if (skb->data[0] == 0xc0)
> - PRINT_INFO(HOSTAPD_DBG, "%x:%x:%x:%x:%x%x\n", skb->data[4],
> skb->data[5], skb->data[6], skb->data[7], skb->data[8], skb->data[9]);
> + PRINT_INFO(HOSTAPD_DBG, "%pM\n", skb->data[4]);
This conversion isn't correct :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] csiostor:Fix locking issues in the function csio_scsim_cleanup_io_lnode
> -Original Message- > From: Nicholas Krause [mailto:xerofo...@gmail.com] > Sent: Wednesday, September 2, 2015 10:36 AM > To: jbottom...@odin.com > Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net; Anish > Bhatt; Hariprasad S; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] csiostor:Fix locking issues in the function > csio_scsim_cleanup_io_lnode > > This fixes locking issues in the function csio_scsim_cleanup_io_lnode by > locking around the call to the function csio_csci_gather_active_ios with the > function pair spin_lock_irq/spin_unlock_irq as any function calling this > particular function must do in order to avoid concurrent threads of execution > on the passed structure pointer of type csio_hw as this structure pointer can > be shared across mutliple threads in the kernel. > > Signed-off-by: Nicholas Krause > --- > drivers/scsi/csiostor/csio_scsi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/scsi/csiostor/csio_scsi.c > b/drivers/scsi/csiostor/csio_scsi.c > index 2c4562d..c318855 100644 > --- a/drivers/scsi/csiostor/csio_scsi.c > +++ b/drivers/scsi/csiostor/csio_scsi.c > @@ -1327,7 +1327,9 @@ csio_scsim_cleanup_io_lnode(struct csio_scsim > *scm, struct csio_lnode *ln) > sld.level = CSIO_LEV_LNODE; > sld.lnode = ln; > INIT_LIST_HEAD(>cmpl_q); > + spin_lock_irq(>lock); > csio_scsi_gather_active_ios(scm, , >cmpl_q); > + spin_unlock_irq(>lock); > > /* No I/Os pending on this lnode */ > if (list_empty(>cmpl_q)) > -- > 2.1.4 Acked-By: Anish Bhatt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] firmware: annotate thou shalt not request fw on init or probe
On Sat, Aug 29, 2015 at 06:18:20PM +0200, Julia Lawall wrote:
> > +@ defines_module_init exists @
> > +declarer name module_init;
> > +identifier init;
> > +@@
> > +
> > +module_init(init);
> > +
> > +@ has_probe depends on defines_module_init @
> > +identifier drv_calls, drv_probe;
> > +type bus_driver;
> > +identifier probe_op =~ "(probe)";
> > +@@
> > +
> > +bus_driver drv_calls = {
> > + .probe_op = drv_probe,
> > +};
>
> I'm not sure that this is enough. For example, there is the macro
> platform_driver_probe that initializes probe fields. There is likewise
> module_platform_driver, which is a top-level declaration that encapsulates
> the module_init and the definition of the module_init function, which in
> turn calls platform_driver_probe. There is also module_platform_driver,
> which encapsulates the module_init, but not the initialization of the probe
> field. Are you concerned with any of these cases?
Yes, and also it would seem this would only capture simple one level of
routine indirection, for instance if probe called bar() and it was within
bar() that the driver code called a fw request call, that would not be picked
up, correct?
If true then the hunt is yet even more complex. The discussion that prompted me
to send this is still unfolding though [0] and it seems we may want to allow
for these type of calls within probe in the end but in order to vet for drivers
that fw is available through the direct filesystem lookup we may need help from
userspace. As that discussion unfolds it will be good to keep in mind what
effort we'd need to hunt all users down for now.
[0]
http://lkml.kernel.org/r/CAB=NE6UBRa0K7=PomJzKxsoj4GzAqkYrkp=o+ufvvu2fwm2...@mail.gmail.com
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] nohz: Affine unpinned timers to housekeepers
On Wed, 2015-09-02 at 12:16 -0400, Chris Metcalf wrote: > On 09/02/2015 05:38 AM, Mike Galbraith wrote: > > IMHO, nohz_full -> cpu_isolated_map removal really wants to happen. > > NO_HZ_FULL_ALL currently means "Woohoo, next stop NR_CPUS=0". > > Yeah, the problem seems to be folks who use it as a kind of > "hey, maybe this gives me some optimization boost somewhere" > kind of setting. Did we ever hear actual use cases for people who > benefited from running nohz_full on cpus with an active scheduler, > i.e. no isolcpus for that core? I find it hard to imagine, but, maybe...? The only sane usage atm is my entire box (small, big likely won't boot) is a dedicated specialist. Previously, you could also have had the feature is valuable enough that I'm willing to pay the quite high price to have this feature available for whenever I feel like using it. > If we don't have such use cases, what should we do here? I'm > slightly sympathetic to these folks who are going "Gee, my machine > suddenly got way slower", but only in the same sense as people > who shoot themselves in the foot and then say "Gee, my foot is > bleeding". But maybe I'm being too hard core :-) I think it's bloody stupid to declare nohz_full cpus dead when they can in fact do generic work. There's no reason to do so... unless maybe we really do need to hold the hand of poor ole Aunt Tilly... the hapless HPC administrator who can't figure out how to use cpusets or such. When the overhead goes away, dynamic usage will become a lot more _practical_, but you can do it in the here and now modulo the cost and that bogus death certificate. They ain't dead, two patches combined to bury the poor things alive. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 1/2] staging: wilc1000: remove FREE_WILC_BUFFER()
On Tue, Aug 18, 2015 at 11:14:49PM -0400, Raphaël Beamonte wrote: > It was just a wrapper around kfree(), so call that instead. > > Signed-off-by: Raphaël Beamonte > --- > drivers/staging/wilc1000/wilc_exported_buf.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) Turns out this file is never even built, you should just remove it :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] usb: dwc2: refactor common low-level hw code to platform.c
On 8/21/2015 5:39 AM, Marek Szyprowski wrote:
> DWC2 module on some platforms needs three additional hardware
> resources: phy controller, clock and power supply. All of them must be
> enabled/activated to properly initialize and operate. This was initially
> handled in s3c-hsotg driver, which has been converted to 'gadget' part
> of dwc2 driver. Unfortunately, not all of this code got moved to common
> platform code, what resulted in accessing DWC2 registers without
> enabling low-level hardware resources. This fails for example on Exynos
> SoCs. This patch moves all the code for managing those resources to
> common platform.c file and provides convenient wrappers for controlling
> them.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/usb/dwc2/core.h | 4 +-
> drivers/usb/dwc2/gadget.c | 188 +---
> drivers/usb/dwc2/platform.c | 207
>
> 3 files changed, 195 insertions(+), 204 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 0ed87620941b..ec820bdf98c0 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -690,6 +690,7 @@ struct dwc2_hsotg {
> enum usb_dr_mode dr_mode;
> unsigned int hcd_enabled:1;
> unsigned int gadget_enabled:1;
> + unsigned int ll_hw_enabled:1;
It seems like this flag is used to restore the state of the
lowlevel_hw on suspend/resume?
I think it is clearer to put the setting/clearing of the flag
inside the ll_hw_enable/disable and then check and adjust on
suspend/resume. That way you don't have to manage this flag
everywhere you call enable/disable().
John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: fbtft: Removed a space
On Fri, Aug 21, 2015 at 06:31:33PM +0530, Aparna Karuthodi wrote: > I fetched it yesterday using git fetch origin master. So, I thought I am in > the recent kernel tree. That's a horrible changelog text :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] staging: fbtft: remove unused bl_ops from fbtft_unregister_backlight
On Sun, Aug 16, 2015 at 11:36:33PM +0300, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport I can't take a patch without some kind of changelog text, sorry. Please fix up and resend this series. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 3/5] mtd: nand: vf610_nfc: add device tree bindings
Signed-off-by: Bill Pringlemeir
Acked-by: Shawn Guo
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/mtd/vf610-nfc.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..6be4871
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,59 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc".
+- reg: address range of the NFC.
+- interrupts: interrupt of the NFC.
+- #address-cells: shall be set to 1. Encode the nand CS.
+- #size-cells : shall be set to 0.
+- assigned-clocks: main clock from the SoC, for Vybrid < VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions.
+
+Required children nodes:
+Children nodes represent the available nand chips. Currently the driver can
+only handle one NAND chip.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc-cs".
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+- nand-on-flash-bbt: see nand.txt
+
+Example:
+
+ nfc: nand@400e {
+ compatible = "fsl,vf610-nfc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400e 0x4000>;
+ interrupts = ;
+ clocks = < VF610_CLK_NFC>;
+ clock-names = "nfc";
+ assigned-clocks = < VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+
+ nand@0 {
+ compatible = "fsl,vf610-nfc-nandcs";
+ reg = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
+ };
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.
Signed-off-by: Bill Pringlemeir
Reviewed-by: Brian Norris
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf610-twr.dts | 47 +
arch/arm/boot/dts/vfxxx.dtsi| 10 +
2 files changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..64d1696 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ VF610_PAD_PTD31__NF_IO150x28df
+ VF610_PAD_PTD30__NF_IO140x28df
+ VF610_PAD_PTD29__NF_IO130x28df
+ VF610_PAD_PTD28__NF_IO120x28df
+ VF610_PAD_PTD27__NF_IO110x28df
+ VF610_PAD_PTD26__NF_IO100x28df
+ VF610_PAD_PTD25__NF_IO9 0x28df
+ VF610_PAD_PTD24__NF_IO8 0x28df
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,26 @@
};
};
+ {
+ assigned-clocks = < VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_nfc>;
+ status = "okay";
+
+ nand@0 {
+ compatible = "fsl,vf610-nfc-nandcs";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-bus-width = <16>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <24>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..17066a2 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,16 @@
status = "disabled";
};
+ nfc: nand@400e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-nfc";
+ reg = <0x400e 0x4000>;
+ interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_NFC>;
+ clock-names = "nfc";
+ status = "disabled";
+ };
};
};
};
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] cpuidle/coupled: Add sanity check for safe_state_index
On Monday, August 31, 2015 11:34:05 AM Xunlei Pang wrote:
> From: Xunlei Pang
>
> Since we are using cpuidle_driver::safe_state_index directly as the
> target state index, it is better to add the sanity check at the point
> of registering the driver.
>
> Signed-off-by: Xunlei Pang
I'm queuing this one up for the next PM pull request, thanks!
> ---
> v2->v3:
> Move the code to a new cpuidle_coupled_state_verify() depending on
> CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED, to avoid using #ifdef in function
> bodies. Thanks Rafael's comments on this.
>
> drivers/cpuidle/coupled.c | 22 ++
> drivers/cpuidle/cpuidle.h | 6 ++
> drivers/cpuidle/driver.c | 4
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> index 1523e2d..344058f 100644
> --- a/drivers/cpuidle/coupled.c
> +++ b/drivers/cpuidle/coupled.c
> @@ -187,6 +187,28 @@ bool cpuidle_state_is_coupled(struct cpuidle_driver
> *drv, int state)
> }
>
> /**
> + * cpuidle_coupled_state_verify - check if the coupled states are correctly
> set.
> + * @drv: struct cpuidle_driver for the platform
> + *
> + * Returns 0 for valid state values, a negative error code otherwise:
> + * * -EINVAL if any coupled state(safe_state_index) is wrongly set.
> + */
> +int cpuidle_coupled_state_verify(struct cpuidle_driver *drv)
> +{
> + int i;
> +
> + for (i = drv->state_count - 1; i >= 0; i--) {
> + if (cpuidle_state_is_coupled(drv, i) &&
> + (drv->safe_state_index == i ||
> + drv->safe_state_index < 0 ||
> + drv->safe_state_index >= drv->state_count))
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +/**
> * cpuidle_coupled_set_ready - mark a cpu as ready
> * @coupled: the struct coupled that contains the current cpu
> */
> diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
> index 178c5ad..f87f399 100644
> --- a/drivers/cpuidle/cpuidle.h
> +++ b/drivers/cpuidle/cpuidle.h
> @@ -35,6 +35,7 @@ extern void cpuidle_remove_sysfs(struct cpuidle_device
> *dev);
>
> #ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> bool cpuidle_state_is_coupled(struct cpuidle_driver *drv, int state);
> +int cpuidle_coupled_state_verify(struct cpuidle_driver *drv);
> int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int next_state);
> int cpuidle_coupled_register_device(struct cpuidle_device *dev);
> @@ -46,6 +47,11 @@ bool cpuidle_state_is_coupled(struct cpuidle_driver *drv,
> int state)
> return false;
> }
>
> +static inline int cpuidle_coupled_state_verify(struct cpuidle_driver *drv)
> +{
> + return 0;
> +}
> +
> static inline int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int next_state)
> {
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index 5db1478..389ade4 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -227,6 +227,10 @@ static int __cpuidle_register_driver(struct
> cpuidle_driver *drv)
> if (!drv || !drv->state_count)
> return -EINVAL;
>
> + ret = cpuidle_coupled_state_verify(drv);
> + if (ret)
> + return ret;
> +
> if (cpuidle_disabled())
> return -ENODEV;
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 5/5] ARM: dts: vf-colibri: enable NAND flash controller
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.
Reviewed-by: Brian Norris
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf-colibri.dtsi | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..e5949b9 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,26 @@
pinctrl-0 = <_i2c0>;
};
+ {
+ assigned-clocks = < VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_nfc>;
+ status = "okay";
+
+ nand@0 {
+ compatible = "fsl,vf610-nfc-nandcs";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pwm0>;
@@ -156,6 +176,25 @@
>;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
This driver supports Freescale NFC (NAND flash controller) found on Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has been tested using 8-bit and 16-bit NAND interface on the ARM based Vybrid SoC VF500 and VF610 platform. parameter page reading. Limitations: - Untested on MPC5125 and M54418. - DMA and pipelining not used. - 2K pages or less. - No chip select, one NAND chip per controller. - No hardware ECC. Some paths have been hand-optimized and evaluated by measurements made using mtd_speedtest.ko on a 100MB MTD partition. Colibri VF50 eb write % eb read % page write % page read % rel/opt 5175 115374560 11039 opt 5164 -0.21 11420 -1.01 4737 +3.88 10918 -1.10 none5113 -1.20 11352 -1.60 4490 -1.54 10865 -1.58 Colibri VF61 eb write % eb read % page write % page read % rel/opt 5766 130965459 12846 opt 5883 +2.03 13064 -0.24 5561 +1.87 12802 -0.34 none5701 -1.13 12980 -0.89 5488 +0.53 12735 -0.86 rel = using readl_relaxed/writel_relaxed in optimized paths opt = hand-optimized by combining multiple accesses into one read/write The measurements have not been statistically verfied, hence use them with care. The author came to the conclusion that using the relaxed variants of readl/writel are not worth the additional code. Signed-off-by: Bill Pringlemeir Tested-by: Albert ARIBAUD Signed-off-by: Stefan Agner --- MAINTAINERS | 6 + drivers/mtd/nand/Kconfig | 9 + drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 686 +++ 4 files changed, 702 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/MAINTAINERS b/MAINTAINERS index 9567329..59975c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10835,6 +10835,12 @@ S: Maintained F: Documentation/fb/uvesafb.txt F: drivers/video/fbdev/uvesafb.* +VF610 NAND DRIVER +M: Stefan Agner +L: linux-...@lists.infradead.org +S: Supported +F: drivers/mtd/nand/vf610_nfc.c + VFAT/FAT/MSDOS FILESYSTEM M: OGAWA Hirofumi S: Maintained diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 3324281..9f9736c 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -460,6 +460,15 @@ config MTD_NAND_MPC5121_NFC This enables the driver for the NAND flash controller on the MPC5121 SoC. +config MTD_NAND_VF610_NFC + tristate "Support for Freescale NFC for VF610/MPC5125" + depends on (SOC_VF610 || COMPILE_TEST) + help + Enables support for NAND Flash Controller on some Freescale + processors like the VF610, MPC5125, MCF54418 or Kinetis K70. + The driver supports a maximum 2k page size. The driver + currently does not support hardware ECC. + config MTD_NAND_MXC tristate "MXC NAND support" depends on ARCH_MXC diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 1f897ec..a490af8 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES) += socrates_nand.o obj-$(CONFIG_MTD_NAND_TXX9NDFMC) += txx9ndfmc.o obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_MTD_NAND_RICOH) += r852.o obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..0d76b3d1247 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,686 @@ +/* + * Copyright 2009-2015 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Jason ported to M54418TWR and MVFA5 (VF610). + * Authors: Stefan Agner + * Bill Pringlemeir + * Shaohui Xie + * Jason Jin + * + * Based on original driver mpc5121_nfc.c. + * + * This 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. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA and pipelining not used. + * - 2K pages or less. + * - No chip select, one NAND chip per controller. + * - No hardware ECC. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineDRV_NAME"vf610_nfc" + +/* Register Offsets */ +#define NFC_FLASH_CMD1
[PATCH v12 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610
This v12 fixes a race condition which sometimes has been lead to corrupted reads. This has been observed while continously rebooting or in the io_paral ubi-test, see also: http://thread.gmane.org/gmane.linux.drivers.mtd/59955 Since the 11th revision the driver rereads the OOB area in case hardware ECC fails. This allows to count the flipped bits accross the whole page reliably. Also the device tree bindings have been updated: NAND chips can be specified using sub-nodes, the ECC properties are part of those chip nodes. Note however that the driver currently only supports one NAND chip. The driver has been verified again using the MTD tests. More information and the full test log of earlier patchset version can be found in the cover letter of the last revision v6: http://thread.gmane.org/gmane.linux.kernel/1979868 Changes since v11: - Unconditionally wait for idle interrupt. This avoids an race condition: The interrupt may fire between setting and checking the idle bit. So the IRQ handler will increment the completion struct (cmd_done), but won't be doing the corresponding decrement via wait_for_completion(). The subsequent wait_for_completion() will immediately succeed, the upper layers then read out the old page buffer (again). - Return amount of bitflips when counting stuck at zero bits in a empty page - Use a common order of function calls in vf610_nfc_command Changes since v10: - Rebased onto l2-mtd/master - Use children nodes for NAND chips in device tree bindings - Support exactly one NAND chip using the new device tree bindings - Reread page OOB on ECC error in order to reliable determine the amount of bit flips on a erased page - Use ECC strength/2 as the only bit flip threshold - Rely on endianness aware word read to read the ECC status - Introduce vf610_nfc_variant which reflects the variant according to the device tree compatible string - Use variant to determine chip select implementation - Use enum for alternate buffer indication - Renamed page_sz variable in struct vf610_nfc as well as in the function vf610_nfc_command to more specific names - Some smaller code cleanup (altered ECC_SRAM_ADDR, introduce OOB_MAX) Changes since v9: - Remove inline of vf610_nfc_done - Add __iomem to src argument of vf610_nfc_memcpy - Handle return value of mtd_device_parse_register correctly - Count bits in OOB too (only non-ECC bits) - Return bitflips in ecc.read_page callback vf610_nfc_read_page - Fall-through ALT_BUF_ONFI - Use BIT macros Changes since v8: - Fix 16-Bit NAND flash support by splitting up initialization (introduce vf610_nfc_preinit_controller) - Updated comments in initialziation functions Changes since v7: - vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node and sort new nfc node behind the existing iomuxc node as well. - vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes Changes since v6: - Rebased ontop of l2-mtd/master (v4.2-rc1 based) - Removed HAVE_NAND_VF610_NFC and use depends on. This made "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary Changes since v5: - Removed fsl,mpc5125-nfc compatible string - Removed readl/writel_relaxed - Change interface of vf610_nfc_transfer_size to match other accessors Changes since v4: - Rebased ontop of l2-mtd/master (v4.1-rc4 based) - Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does not support sub-page writes anyway (improves write performance) - Support ONFI by enabling READID command with offset and parameter page reads (CMD_PARAM) - Change to dedicated read_page/write_page function, enables raw writes - Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements - Eliminated vf610_nfc_probe_dt in favor of common DT init code - Use wait_for_completion_timeout - Some style fixes (spaces, etc.) Changes since v3: - Make the driver selectable when COMPILE_TEST is set - Fix compile error due to superfluous ECC_STATUS configuration in initial patch (without ECC correction ECC_STATUS does not need to be configured) - Remove custom BBT pattern and switch to in-band BBT in the initial patch - Include two bug fixes, for details see the corresponding U-Boot patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802 Changes since v2: - Updated binding documentation Changes since v1: - Nest nfc_config struct within the main nfc struct - Use assigned clock binding to specify NFC clock - Rebased ontop of MSCM IR patchset (driver parts have been merged) - Split out arch Kconfig in a separate config - Fix module license - Updated MAINTAINERS Changes since RFC (Bill Pringlemeir): - Renamed driver from fsl_nfc to vf610_nfc - Use readl/writel for all register in accessor functions - Optimized field accessor functions - Implemented PM (suspend/resume) functions - Implemented basic support for ECC strength/ECC step size from dt - Improved performance of count_written_bits by using hweight32 - Support ECC with 60-bytes to correct up to 32 bit errors -
[PATCH v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages).
Limitations:
- HW ECC: Only 2K page with 64+ OOB.
- HW ECC: Only 24 and 32-bit error correction implemented.
Raw writes have been tested using the generic nand_write_page_raw
implementation. However, raw reads are currently not possible
because the controller need to know whether we are going to use
the ECC mode already at NAND_CMD_READ0 command time. At this point
we do not have the information whether it is a raw read or a
regular read at driver level...
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
drivers/mtd/nand/Kconfig | 6 +-
drivers/mtd/nand/vf610_nfc.c | 203 ++-
2 files changed, 205 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 9f9736c..ccd1158 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -466,8 +466,10 @@ config MTD_NAND_VF610_NFC
help
Enables support for NAND Flash Controller on some Freescale
processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 0d76b3d1247..4513b08 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,8 +19,8 @@
* - Untested on MPC5125 and M54418.
* - DMA and pipelining not used.
* - 2K pages or less.
- * - No chip select, one NAND chip per controller.
- * - No hardware ECC.
+ * - HW ECC: Only 2K page with 64+ OOB.
+ * - HW ECC: Only 24 and 32-bit error correction implemented.
*/
#include
@@ -77,6 +77,8 @@
/* NFC ECC mode define */
#define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
/*** Register Mask and bit definitions */
@@ -129,6 +131,18 @@
#define CMD_DONE_CLEAR_BIT BIT(18)
#define IDLE_CLEAR_BIT BIT(17)
+/*
+ * ECC status - seems to consume 8 bytes (double word). The documented
+ * status byte is located in the lowest byte of the second word (which is
+ * the 4th or 7th byte depending on endianness).
+ * Calculate an offset to store the ECC status at the end of the buffer.
+ */
+#define ECC_SRAM_ADDR (PAGE_2K + OOB_MAX - 8)
+
+#define ECC_STATUS 0x4
+#define ECC_STATUS_MASK0x80
+#define ECC_STATUS_ERR_COUNT 0x3F
+
enum vf610_nfc_alt_buf {
ALT_BUF_DATA = 0,
ALT_BUF_ID = 1,
@@ -152,10 +166,40 @@ struct vf610_nfc {
enum vf610_nfc_alt_buf alt_buf;
enum vf610_nfc_variant variant;
struct clk *clk;
+ bool use_hw_ecc;
+ u32 ecc_mode;
};
#define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+ .eccbytes = 45,
+ .eccpos = {19, 20, 21, 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 32, 33, 34, 35, 36, 37, 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 48, 49, 50, 51, 52, 53, 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63},
+ .oobfree = {
+ {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+ .eccbytes = 60,
+ .eccpos = { 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, 32, 33, 34, 35,
+ 36, 37, 38, 39, 40, 41, 42, 43,
+ 44, 45, 46, 47, 48, 49, 50, 51,
+ 52, 53, 54, 55, 56, 57, 58, 59,
+ 60, 61, 62, 63 },
+ .oobfree = {
+ {.offset = 2,
+.length = 2} }
+};
+
static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
{
return readl(nfc->regs + reg);
@@ -297,6 +341,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc,
int column, int page)
ROW_ADDR_SHIFT, page);
}
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+ vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+ CONFIG_ECC_MODE_MASK,
+ CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
{
Re: [PATCH 0/8] fix drivers/staging/android several coding style issues
On Wed, Aug 26, 2015 at 11:52:09AM +0800, Peng Sun wrote: > patches based on linux-next next-20150825 > Corrections based on checkpatch.pl with --strict > > Peng Sun (8): > fix staging:android style issue:spaces preferred around that '-' > fix staging:android style issue:No space is necessary after a cast > fix staging:android style issue:Alignment should match open > parenthesis > fix staging:android style issue:Prefer kernel type 'u32' over > 'uint32_t' > fix staging:android style issue:Please use a blank line after > function/struct/union/enum declarations > fix staging:android style issue:Comparison to NULL could be written > fix staging:android style issue:definition without comment > fix staging:android style issue:Please don't use multiple blank lines You sent out 3 different series, and I don't know which should be applied. So please fix up and resend just the one you want applied. Note, the "style issue:" shouldn't be in the subject, look at how other commits are titled. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: android: fix typo
On Thu, Aug 20, 2015 at 08:29:12AM +0900, Junesung Lee wrote: > Fix typo. What typo? Be specific please. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers:staging:vt6655: Fix coding style issues
On Fri, Aug 28, 2015 at 01:51:44PM +0300, lysanovser...@gmail.com wrote:
> From: Sergey Lysanov
>
> This patch fixes the following issues reported by checkpatch.pl:
> - code indent should use tabs where possible
> - space prohibited before that ','
>
> Signed-off-by: Sergey Lysanov
> ---
> drivers/staging/vt6655/rxtx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
> index 5875d65..64957de 100644
> --- a/drivers/staging/vt6655/rxtx.c
> +++ b/drivers/staging/vt6655/rxtx.c
> @@ -64,8 +64,8 @@
> /*- Static Functions --*/
>
> /*- Static Definitions -*/
> -#define CRITICAL_PACKET_LEN 256/* if packet size < 256 -> in-direct
> send
> -packet size >= 256 -> direct
> send */
> +#define CRITICAL_PACKET_LEN 256 /* if packet size < 256 -> in-direct send
> + packet size >= 256 -> direct send */
>
> static const unsigned short wTimeStampOff[2][MAX_RATE] = {
> {384, 288, 226, 209, 54, 43, 37, 31, 28, 25, 24, 23}, /* Long Preamble
> */
> @@ -78,7 +78,7 @@ static const unsigned short wFB_Opt0[2][5] = {
> };
> static const unsigned short wFB_Opt1[2][5] = {
> {RATE_12M, RATE_18M, RATE_24M, RATE_24M, RATE_36M}, /* fallback_rate0 */
> - {RATE_6M , RATE_6M, RATE_12M, RATE_12M, RATE_18M}, /* fallback_rate1 */
> + {RATE_6M, RATE_6M, RATE_12M, RATE_12M, RATE_18M}, /* fallback_rate1 */
The goal was to keep these aligned, which you broke the formatting for
:(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
On 01.09.2015 14:49, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge
> directory, and rename the core driver to analogix_dp_*,
> leave the platform code to analogix_dp-exynos.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4:
> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery.
> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
> "exynos_dp.c"
> - Take Archit suggest, create a separate folder for analogix code in bridge/
>
> Changes in v3:
> - Take Thierry Reding suggest, move exynos's video_timing code
> to analogix_dp-exynos platform driver, add get_modes method
> to struct analogix_dp_plat_data.
> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
>
> Changes in v2:
> - Take Jingoo Han suggest, remove new copyright
> - Fix compiled failed dut to analogix_dp_device misspell
>
> drivers/gpu/drm/bridge/Kconfig |2 +
> drivers/gpu/drm/bridge/Makefile|1 +
> drivers/gpu/drm/bridge/analogix/Kconfig|4 +
> drivers/gpu/drm/bridge/analogix/Makefile |1 +
> .../analogix/analogix_dp_core.c} | 817 ++---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 283 +
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1265
>
> .../analogix/analogix_dp_reg.h}| 258 ++--
> drivers/gpu/drm/exynos/Kconfig |3 +-
> drivers/gpu/drm/exynos/Makefile|2 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 306 +
> drivers/gpu/drm/exynos/exynos_dp_core.h| 282 -
> drivers/gpu/drm/exynos/exynos_dp_reg.c | 1259 ---
> include/drm/bridge/analogix_dp.h | 24 +
> 14 files changed, 2357 insertions(+), 2150 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
> rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
> bridge/analogix/analogix_dp_core.c} (50%)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
> bridge/analogix/analogix_dp_reg.h} (64%)
> create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
> delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
> create mode 100644 include/drm/bridge/analogix_dp.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 2de52a5..7b5b77a 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
> ---help---
> Parade eDP-LVDS bridge chip driver.
>
> +source "drivers/gpu/drm/bridge/analogix/Kconfig"
> +
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index e2eef1c..5366c6b 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
> obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> new file mode 100644
> index 000..5ff6551
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -0,0 +1,4 @@
> +config DRM_ANALOGIX_DP
> + tristate
> + depends on DRM
> + select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> new file mode 100644
> index 000..9107b86
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> similarity index 50%
> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index bed0252..7d62f22 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1,14 +1,14 @@
> /*
> - * Samsung SoC DP (Display Port) interface driver.
> - *
> - * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> - * Author: Jingoo Han
> - *
> - * 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.
> - */
> +* Analogix DP (Display Port) core interface driver.
> +*
> +* Copyright (C) 2012 Samsung Electronics Co., Ltd.
> +* Author:
Re: [PATCH] dax, pmem: add support for msync
On Wed, Sep 02, 2015 at 12:13:21PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 02, 2015 at 08:49:22AM +1000, Dave Chinner wrote:
> > On Tue, Sep 01, 2015 at 01:08:04PM +0300, Kirill A. Shutemov wrote:
> > > On Tue, Sep 01, 2015 at 09:38:03AM +1000, Dave Chinner wrote:
> > > > On Mon, Aug 31, 2015 at 12:59:44PM -0600, Ross Zwisler wrote:
> > > > Even for DAX, msync has to call vfs_fsync_range() for the filesystem to
> > > > commit
> > > > the backing store allocations to stable storage, so there's not
> > > > getting around the fact msync is the wrong place to be flushing
> > > > DAX mappings to persistent storage.
> > >
> > > Why?
> > > IIUC, msync() doesn't have any requirements wrt metadata, right?
> >
> > Of course it does. If the backing store allocation has not been
> > committed, then after a crash there will be a hole in file and
> > so it will read as zeroes regardless of what data was written and
> > flushed.
>
> Any reason why backing store allocation cannot be committed on *_mkwrite?
Oh, I could change that if you want, it'll just be ridiculously
slow because it requires journal flushes on every page fault that
needs to change the filesytsem block map (i.e. every allocation and/or
every unwritten extent conversion).
Sycnhronous journalling requires flushing the log on every
transaction commit. That involves switching to a work queue, copying
the changes into a log buffer, issuing IO to flush the journal,
waiting for that to complete, etc. i.e. synchronous journalling
incurs a minimum overhead of 4 context switches per page fault that
needs to allocate/convert backing store, along with all the CPU time
needed to process the journal commit.
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 3f78bceefe5a..f2e29a541e14 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1645,6 +1645,15 @@ unsigned long mmap_region(struct file *file, unsigned
> long addr,
> vma->vm_ops = _ops;
> }
>
> + /*
> +* Make sure that for VM_MIXEDMAP VMA has both
> +* vm_ops->page_mkwrite and vm_ops->pfn_mkwrite or has none.
> +*/
> + if ((vma->vm_ops->page_mkwrite || vma->vm_ops->pfn_mkwrite) &&
> + vma->vm_flags & VM_MIXEDMAP) {
> + VM_BUG_ON_VMA(!vma->vm_ops->page_mkwrite, vma);
> + VM_BUG_ON_VMA(!vma->vm_ops->pfn_mkwrite, vma);
> + }
Doesn't really help developers that don't use CONFIG_DEBUG_VM. i.e
it's the FS developers that you need to warn, not VM developers -
in this case a "WARN_ON_ONCE" is probably more appropriate.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] PM / Domains: Remove cpuidle attach
On Tuesday, September 01, 2015 08:37:49 PM Daniel Lezcano wrote:
> The power domains code allows to tie a cpuidle state with a power domain.
>
> Preventing the cpuidle framework to enter a specific idle state by disabling
> from the power domain framework is a good idea. Unfortunately, the current
> implementation has some gaps with a SMP system and a complex cpuidle
> implementation. Enabling a power domain wakes up all the cpus even if a cpu
> does not belong to the power domain.
>
> There is some work to do a logical representation with the power domains of
> the hardware dependencies (eg. a cpu belongs to a power domains, these power
> domains belong to a higher power domain for a cluster, etc ...). A new code
> relying on the genpd hierarchy to disable the idle states would make more
> sense.
>
> As the unique user of this code has been removed, let's wipe out this code
> to prevent new user and to have a clean place to put a new implementation.
>
> Signed-off-by: Daniel Lezcano
What tree is this supposed to apply to?
> ---
> drivers/base/power/domain.c | 154
>
> include/linux/pm_domain.h | 27
> 2 files changed, 181 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 0ee43c1..f468627 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -171,19 +171,6 @@ static void genpd_set_active(struct generic_pm_domain
> *genpd)
> genpd->status = GPD_STATE_ACTIVE;
> }
>
> -static void genpd_recalc_cpu_exit_latency(struct generic_pm_domain *genpd)
> -{
> - s64 usecs64;
> -
> - if (!genpd->cpuidle_data)
> - return;
> -
> - usecs64 = genpd->power_on_latency_ns;
> - do_div(usecs64, NSEC_PER_USEC);
> - usecs64 += genpd->cpuidle_data->saved_exit_latency;
> - genpd->cpuidle_data->idle_state->exit_latency = usecs64;
> -}
> -
> static int genpd_power_on(struct generic_pm_domain *genpd, bool timed)
> {
> ktime_t time_start;
> @@ -207,7 +194,6 @@ static int genpd_power_on(struct generic_pm_domain
> *genpd, bool timed)
>
> genpd->power_on_latency_ns = elapsed_ns;
> genpd->max_off_time_changed = true;
> - genpd_recalc_cpu_exit_latency(genpd);
> pr_debug("%s: Power-%s latency exceeded, new value %lld ns\n",
>genpd->name, "on", elapsed_ns);
>
> @@ -280,13 +266,6 @@ static int __pm_genpd_poweron(struct generic_pm_domain
> *genpd)
> return 0;
> }
>
> - if (genpd->cpuidle_data) {
> - cpuidle_pause_and_lock();
> - genpd->cpuidle_data->idle_state->disabled = true;
> - cpuidle_resume_and_unlock();
> - goto out;
> - }
> -
> /*
>* The list is guaranteed not to change while the loop below is being
>* executed, unless one of the masters' .power_on() callbacks fiddles
> @@ -595,21 +574,6 @@ static int pm_genpd_poweroff(struct generic_pm_domain
> *genpd)
> }
> }
>
> - if (genpd->cpuidle_data) {
> - /*
> - * If cpuidle_data is set, cpuidle should turn the domain off
> - * when the CPU in it is idle. In that case we don't decrement
> - * the subdomain counts of the master domains, so that power is
> - * not removed from the current domain prematurely as a result
> - * of cutting off the masters' power.
> - */
> - genpd->status = GPD_STATE_POWER_OFF;
> - cpuidle_pause_and_lock();
> - genpd->cpuidle_data->idle_state->disabled = false;
> - cpuidle_resume_and_unlock();
> - goto out;
> - }
> -
> if (genpd->power_off) {
> if (atomic_read(>sd_count) > 0) {
> ret = -EBUSY;
> @@ -1725,124 +1689,6 @@ int pm_genpd_remove_subdomain(struct
> generic_pm_domain *genpd,
> return ret;
> }
>
> -/**
> - * pm_genpd_attach_cpuidle - Connect the given PM domain with cpuidle.
> - * @genpd: PM domain to be connected with cpuidle.
> - * @state: cpuidle state this domain can disable/enable.
> - *
> - * Make a PM domain behave as though it contained a CPU core, that is,
> instead
> - * of calling its power down routine it will enable the given cpuidle state
> so
> - * that the cpuidle subsystem can power it down (if possible and desirable).
> - */
> -int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state)
> -{
> - struct cpuidle_driver *cpuidle_drv;
> - struct gpd_cpuidle_data *cpuidle_data;
> - struct cpuidle_state *idle_state;
> - int ret = 0;
> -
> - if (IS_ERR_OR_NULL(genpd) || state < 0)
> - return -EINVAL;
> -
> - genpd_acquire_lock(genpd);
> -
> - if (genpd->cpuidle_data) {
> - ret = -EEXIST;
> - goto out;
> - }
> - cpuidle_data = kzalloc(sizeof(*cpuidle_data), GFP_KERNEL);
> - if
Re: [PATCH] [v3] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map
On Wednesday, September 02, 2015 08:06:28 PM Chen Yu wrote:
> On some platforms, there is occasional panic triggered when trying to
> resume from hibernation, a typical panic looks like:
>
> BUG: unable to handle kernel paging request at 880085894000
> IP: [] load_image_lzo+0x8c2/0xe70
>
> This is because e820 map has been changed by BIOS before/after
> hibernation, and one of the page frames from first kernel
> is right located in second kernel's unmapped region, so panic
> comes out when accessing unmapped kernel address.
>
> Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved
> regions") was once introduced to fix this problem: to warn on the change
> on BIOS e820 and deny the resuming process, thus avoid the panic
> afterwards. However, this patch makes resuming from hibernation on Lenovo
> x230 failed, and the reason for it is that, this patch can not deal with
> unaligned E820_RESERVED_KERN regions and fails to resume from hibernation:
> https://bugzilla.kernel.org/show_bug.cgi?id=96111
> As a result, this patch is reverted.
>
> To solve this hibernation panic issue fundamentally, we need to get rid of
> the impact of E820_RESERVED_KERN, so Yinghai,Lu proposes a patch to kill
> E820_RESERVED_KERN and based on his patch we can re-apply
> Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved
> regions"), and stress testing has been performed on problematic platform
> with above two patches applied, it works as expected, no panic anymore.
>
> However, there is still one thing left, hibernation might fail even after
> above two patches applied, with the following warnning in log:
>
> PM: Image mismatch: memory size
>
> This is also because BIOS provides different e820 memory map before/after
> hibernation, thus different memory pages, and linux regards different
> number of memory pages as invalid process and refuses to resume, in order
> to protect against data corruption. However, this check might be too
> strict, consider the following scenario:
> The hibernating system has a smaller memory capacity than the resuming
> system, and the former memory region is a subset of the latter, it should
> be allowed to resume. Here is a case for this situation:
>
> before hibernation:
>
> BIOS-e820: [mem 0x2020-0x77517fff] usable
> BIOS-e820: [mem 0x77518000-0x77567fff] reserved
> Memory: 3871356K/4058428K available (7595K kernel code, 1202K rwdata,
> 3492K rodata, 1400K init, 1308K bss, 187072K reserved, 0K cma-reserved)
>
> after hibernation:
> BIOS-e820: [mem 0x2020-0x7753] usable
> BIOS-e820: [mem 0x7754-0x77567fff] reserved
> Memory: 3871516K/4058588K available (7595K kernel code, 1202K rwdata,
> 3492K rodata, 1400K init, 1308K bss, 187072K reserved, 0K cma-reserved)
>
> According to above data, the number of present_pages has increased by
> 40(thus 160K), linux will terminate the resuming process. But since
> [0x2020-0x77517fff] is a subset of
> [0x2020-0x7753], we should let system resume.
>
> Since above two patches can not deal with the hibernation failor, another
> solution to fix both hibernation panic and hibernation failor is proposed
> as follows:
> We simply check that, if each non-highmem page frame to be restored is a
> valid mapped kernel page(by checking if this page is in pfn_mapped
> array in arch/x86/mm/init.c), if it is, resuming process will continue.
> In this way we do not have to touch E820_RESERVED_KERN, and we can:
> 1.prevent the hibernation panic caused by unmapped-page address
> accessing
> 2.remove the code that requires the same memory size before/after
> hibernation.
>
> Note: for point 2, this patch only works on x86_64 platforms
> (with no highmem), because the highmem page frames on x86_32
> are not directly-mapped by kernel, which is out of the scope
> of pfn_mapped, this patch will not guarantee that whether the
> higmem region is legal for restore. A further work might include
> a logic to check if each page frame to be restored is in E820_RAM
> region, but it might require quite neat checkings in the code.
> For now, just solve the problem reported on x86_64.
>
> After this patch applied, the panic will be replaced with the warning:
>
> PM: Loading and decompressing image data (96092 pages)...
> PM: Image loading progress: 0%
> PM: Image loading progress: 10%
> PM: Image loading progress: 20%
> PM: Image loading progress: 30%
> PM: Image loading progress: 40%
> PM: 0x849dd000 to restored not in valid memory region
>
> Signed-off-by: Chen Yu
Well, looks like an improvement, but I wouldn't be comfortable with
pushing it to Linus before it spent a fair amount of time in linux-next.
For this reason, I can queue it up for the next merge window when 4.3-rc1
is out.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH] tty: fix data race in flush_to_ldisc
On 09/02/2015 01:53 PM, Dmitry Vyukov wrote: > The data race is found with KernelThreadSanitizer (on rev 21bdb584af8c): > > ThreadSanitizer: data-race in release_tty > Write of size 8 by thread T325 (K2579): > release_tty+0xf3/0x1c0 drivers/tty/tty_io.c:1688 > tty_release+0x698/0x7c0 drivers/tty/tty_io.c:1920 > __fput+0x15f/0x310 fs/file_table.c:207 > fput+0x1d/0x30 fs/file_table.c:243 > task_work_run+0x115/0x130 kernel/task_work.c:123 > do_notify_resume+0x73/0x80 > tracehook_notify_resume include/linux/tracehook.h:190 > do_notify_resume+0x73/0x80 arch/x86/kernel/signal.c:757 > int_signal+0x12/0x17 arch/x86/entry/entry_64.S:326 > Previous read of size 8 by thread T19 (K16): > flush_to_ldisc+0x29/0x300 drivers/tty/tty_buffer.c:472 > process_one_work+0x47e/0x930 kernel/workqueue.c:2036 > worker_thread+0xb0/0x900 kernel/workqueue.c:2170 > kthread+0x150/0x170 kernel/kthread.c:207 The stack traces are not really helpful in describing how the race occurs; I would leave it out of the changelog. > flush_to_ldisc reads port->itty and checks that it is not NULL, > concurrently release_tty sets port->itty to NULL. It is possible > that flush_to_ldisc loads port->itty once, ensures that it is > not NULL, but then reloads it again and uses. The second load > can already return NULL, which will cause a crash. > > Use READ_ONCE/WRITE_ONCE to read/update port->itty. See below. > Signed-off-by: Dmitry Vyukov > --- > drivers/tty/tty_buffer.c | 2 +- > drivers/tty/tty_io.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c > index 4cf263d..1f1031d 100644 > --- a/drivers/tty/tty_buffer.c > +++ b/drivers/tty/tty_buffer.c > @@ -469,7 +469,7 @@ static void flush_to_ldisc(struct work_struct *work) > struct tty_struct *tty; > struct tty_ldisc *disc; > > - tty = port->itty; > + tty = READ_ONCE(port->itty); This is fine. > if (tty == NULL) > return; > > diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c > index 57fc6ee..aad47df 100644 > --- a/drivers/tty/tty_io.c > +++ b/drivers/tty/tty_io.c > @@ -1685,7 +1685,7 @@ static void release_tty(struct tty_struct *tty, int idx) > tty_driver_remove_tty(tty->driver, tty); > tty->port->itty = NULL; > if (tty->link) > - tty->link->port->itty = NULL; > + WRITE_ONCE(tty->link->port->itty, NULL); This isn't doing anything useful. 1. The compiler can't push the store past the cancel_work_sync() (because the compiler has no visibility into cancel_work_sync()), and, 2. There's no effect if the compiler hoists the store higher in the release_tty() because the line discipline has already been closed and killed (so the tty_ldisc_ref() in flush_to_ldisc() returns NULL anyway). Regards, Peter Hurley > cancel_work_sync(>port->buf.work); > > tty_kref_put(tty->link); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_cleanup_fb':
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:272:26: error: 'fb' redeclared as
different kind of symbol
struct drm_framebuffer *fb = old_state->fb;
^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:267:27: note: previous definition of
'fb' was here
struct drm_framebuffer *fb,
^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: At top level:
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: initialization from
incompatible pointer type
.cleanup_fb = mdp5_plane_cleanup_fb,
^
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:383:3: warning: (near initialization
for 'mdp5_plane_helper_funcs.cleanup_fb')
Caused by commit
a317290af0db ("drm/atomic: Make prepare_fb/cleanup_fb only take state, v3")
Well, that was clearly never build tested :-(
I have used the drm-misc tree from next-20150902 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] staging: lustre: fix whitespace errors reported by checkpatch.pl
On Sat, Aug 22, 2015 at 05:17:19PM +0300, Mike Rapoport wrote: > Added/removed spaces and replaced '+1' with '1' in several places to > eliminate SPACING and POINTER_LOCATION errors reported by checkpatch.pl > > Signed-off-by: Mike Rapoport Does not apply to my tree :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cputime: fix invalid gtime
From: Hiroshi Shimamoto
/proc/stats shows invalid gtime when the thread is running in guest.
When vtime accounting is not enabled, we cannot get a valid delta.
Just return gtime when vtime accounting is not enabled in task_gtime().
Before
10987 (qemu-kvm) S 1 10923 10923 0 -1 138428608 7521 0 90 0 3776 460 0 0 20 0
24 0 11960 8090398720 151288 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 3554 0 0 0 0 0 0 0 0 0
10987 (qemu-kvm) S 1 10923 10923 0 -1 138428608 7521 0 90 0 3776 460 0 0 20 0
17 0 11960 8031649792 150268 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 3554 0 0 0 0 0 0 0 0 0
10987 (qemu-kvm) R 1 10923 10923 0 -1 138428624 7521 0 90 0 3843 460 0 0 20 0
17 0 11960 8031649792 150268 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 21415 0 0 0 0 0 0 0 0 0
10987 (qemu-kvm) R 1 10923 10923 0 -1 138428624 7521 0 90 0 3943 460 0 0 20 0
17 0 11960 8031649792 150268 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 21616 0 0 0 0 0 0 0 0 0
10987 (qemu-kvm) R 1 10923 10923 0 -1 138428624 7521 0 90 0 4044 460 0 0 20 0
17 0 11960 8031649792 150268 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 21816 0 0 0 0 0 0 0 0 0
10987 (qemu-kvm) R 1 10923 10923 0 -1 138428624 7521 0 90 0 4144 460 0 0 20 0
17 0 11960 8031649792 150268 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 22017 0 0 0 0 0 0 0 0 0
10987 (qemu-kvm) R 1 10923 10923 0 -1 138428624 7521 0 90 0 4245 460 0 0 20 0
11 0 11960 7981293568 149758 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 22218 0 0 0 0 0 0 0 0 0
10987 (qemu-kvm) S 1 10923 10923 0 -1 138428608 7521 0 90 0 4308 460 0 0 20 0
11 0 11960 7981293568 149758 18446744073709551615 1 1 0 0 0 0 2147220671 4096
25155 18446744073709551615 0 0 -1 9 0 0 0 4084 0 0 0 0 0 0 0 0 0
After
10845 (qemu-kvm) S 1 10792 10792 0 -1 138428608 202 0 0 0 2858 30 0 0 20 0 29 0
7676 8511279104 148187 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 2874 0 0 0 0 0 0 0 0 0
10845 (qemu-kvm) S 1 10792 10792 0 -1 138428608 202 0 0 0 2858 30 0 0 20 0 29 0
7676 8511279104 148187 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 2874 0 0 0 0 0 0 0 0 0
10845 (qemu-kvm) R 1 10792 10792 0 -1 138428624 203 0 0 0 2936 30 0 0 20 0 29 0
7676 8511279104 148187 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 2952 0 0 0 0 0 0 0 0 0
10845 (qemu-kvm) R 1 10792 10792 0 -1 138428624 203 0 0 0 3037 30 0 0 20 0 29 0
7676 8511279104 152184 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 3052 0 0 0 0 0 0 0 0 0
10845 (qemu-kvm) R 1 10792 10792 0 -1 138428624 203 0 0 0 3137 30 0 0 20 0 29 0
7676 8511279104 152184 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 3152 0 0 0 0 0 0 0 0 0
10845 (qemu-kvm) R 1 10792 10792 0 -1 138428624 203 0 0 0 3237 30 0 0 20 0 27 0
7676 8511279104 152188 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 3252 0 0 0 0 0 0 0 0 0
10845 (qemu-kvm) S 1 10792 10792 0 -1 138428608 203 0 0 0 3262 31 0 0 20 0 11 0
7676 8393781248 151156 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 3277 0 0 0 0 0 0 0 0 0
10845 (qemu-kvm) S 1 10792 10792 0 -1 138428608 203 0 0 0 3262 31 0 0 20 0 11 0
7676 8393781248 151156 18446744073709551615 1 1 0 0 0 0 2147220671 4096 25155
18446744073709551615 0 0 -1 3 0 0 0 3277 0 0 0 0 0 0 0 0 0
Signed-off-by: Hiroshi Shimamoto
---
kernel/sched/cputime.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 8cbc3db..f614ee9 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -786,6 +786,9 @@ cputime_t task_gtime(struct task_struct *t)
unsigned int seq;
cputime_t gtime;
+ if (!vtime_accounting_enabled())
+ return t->gtime;
+
do {
seq = read_seqbegin(>vtime_seqlock);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/31] perf tools: Introduce dummy evsel
发自我的 iPhone
> 在 2015年9月3日，上午8:11，Namhyung Kim 写道：
>
> Hi,
>
>> On Sat, Aug 29, 2015 at 04:21:37AM +, Wang Nan wrote:
>> This patch allows linking dummy evsel onto evlist as a placeholder. It
>> is for following patch which allows passing BPF object using '--event
>> object.o'.
>>
>> Doesn't link other event selectors, if passing a BPF object file to
>> '--event', nothing is linked onto evlist. Instead, events described in
>> BPF object file are probed and linked in a delayed manner because we
>> want do all probing work together. Therefore, evsel for events in BPF
>> object would be linked at the end of evlist. Which causes a small
>> problem that, if passing '--filter' setting after object file, the
>> filter option won't be correctly applied to those events.
>>
>> This patch links dummy onto evlist, so following --filter can be
>> collected by the dummy evsel. For this reason dummy evsels are set to
>> PERF_TYPE_TRACEPOINT.
>
> I understand the need of the dummy event. But we already have dummy
> event so it's confusing to have similar event IMHO. So what about
> using existing dummy event instead? You can save a link to a bpf
> object in the dummy evsel (to check it later) and change to allow
> setting filter on dummy events IMHO.
>
Yes, in my working-in-progress implement I use existing dummy event. Connect it
to the object by setting its name to the name of object.
Thank you.
>>
>> Due to the possibility of existance of dummy evsel,
>> perf_evlist__purge_dummy() must be called right after parse_options().
>> This patch adds it to record, top, trace and stat builtin commands.
>> Further patch moves it down after real BPF events are processed with.
>
> IMHO it'd be better to do this kind of job in a single place -
> e.g. perf_evlist__config() ? - so that other commands get benefits
> from it easily.
>
> Thanks,
> Namhyung
>
>
>>
>> Signed-off-by: Wang Nan
>> Cc: Arnaldo Carvalho de Melo
>> Cc: Alexei Starovoitov
>> Cc: Brendan Gregg
>> Cc: Daniel Borkmann
>> Cc: David Ahern
>> Cc: He Kuang
>> Cc: Jiri Olsa
>> Cc: Kaixu Xia
>> Cc: Masami Hiramatsu
>> Cc: Namhyung Kim
>> Cc: Peter Zijlstra
>> Cc: Zefan Li
>> Cc: pi3or...@163.com
>> Link:
>> http://lkml.kernel.org/r/1440742821-44548-4-git-send-email-wangn...@huawei.com
>> ---
>> tools/perf/builtin-record.c| 2 ++
>> tools/perf/builtin-stat.c | 1 +
>> tools/perf/builtin-top.c | 1 +
>> tools/perf/builtin-trace.c | 1 +
>> tools/perf/util/evlist.c | 19 +++
>> tools/perf/util/evlist.h | 1 +
>> tools/perf/util/evsel.c| 32
>> tools/perf/util/evsel.h| 6 ++
>> tools/perf/util/parse-events.c | 25 +
>> 9 files changed, 84 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index a660022..81829de 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -1112,6 +1112,8 @@ int cmd_record(int argc, const char **argv, const char
>> *prefix __maybe_unused)
>>
>>argc = parse_options(argc, argv, record_options, record_usage,
>>PARSE_OPT_STOP_AT_NON_OPTION);
>> +perf_evlist__purge_dummy(rec->evlist);
>> +
>>if (!argc && target__none(>opts.target))
>>usage_with_options(record_usage, record_options);
>>
>> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
>> index 7aa039b..99b62f1 100644
>> --- a/tools/perf/builtin-stat.c
>> +++ b/tools/perf/builtin-stat.c
>> @@ -1208,6 +1208,7 @@ int cmd_stat(int argc, const char **argv, const char
>> *prefix __maybe_unused)
>>
>>argc = parse_options(argc, argv, options, stat_usage,
>>PARSE_OPT_STOP_AT_NON_OPTION);
>> +perf_evlist__purge_dummy(evsel_list);
>>
>>interval = stat_config.interval;
>>
>> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
>> index 8c465c8..246203b 100644
>> --- a/tools/perf/builtin-top.c
>> +++ b/tools/perf/builtin-top.c
>> @@ -1198,6 +1198,7 @@ int cmd_top(int argc, const char **argv, const char
>> *prefix __maybe_unused)
>>perf_config(perf_top_config, );
>>
>>argc = parse_options(argc, argv, options, top_usage, 0);
>> +perf_evlist__purge_dummy(top.evlist);
>>if (argc)
>>usage_with_options(top_usage, options);
>>
>> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
>> index 4e3abba..57712b9 100644
>> --- a/tools/perf/builtin-trace.c
>> +++ b/tools/perf/builtin-trace.c
>> @@ -3099,6 +3099,7 @@ int cmd_trace(int argc, const char **argv, const char
>> *prefix __maybe_unused)
>>
>>argc = parse_options_subcommand(argc, argv, trace_options,
>> trace_subcommands,
>> trace_usage, PARSE_OPT_STOP_AT_NON_OPTION);
>> +perf_evlist__purge_dummy(trace.evlist);
>>
>>if (trace.trace_pgfaults) {
>>trace.opts.sample_address = true;
>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>>
Re: [PATCH 14/31] perf tools: Suppress probing messages when probing by BPF loading
On Sat, Aug 29, 2015 at 04:21:48AM +, Wang Nan wrote:
> This patch suppresses message output by add_perf_probe_events() and
> del_perf_probe_events() if they are triggered by BPF loading. Before
> this patch, when using 'perf record' with BPF object/source as event
> selector, following message will be output:
>
> Added new event:
>perf_bpf_probe:lock_page_ret (on __lock_page%return)
> You can now use it in all perf tools, such as:
> perf record -e perf_bpf_probe:lock_page_ret -aR sleep 1
> ...
> Removed event: perf_bpf_probe:lock_page_ret
>
> Which is misleading, especially 'use it in all perf tools' because they
> will be removed after 'pref record' exit.
>
> In this patch, a 'silent' field is appended into probe_conf to control
> output. bpf__{,un}probe() set it to true when calling
> {add,del}_perf_probe_events().
I think that printing those messages should be done in cmd_probe()
rather than add/del_perf_probe_events()..
Thanks,
Namhyung
>
> Signed-off-by: Wang Nan
> Cc: Arnaldo Carvalho de Melo
> Cc: Alexei Starovoitov
> Cc: Brendan Gregg
> Cc: Daniel Borkmann
> Cc: David Ahern
> Cc: He Kuang
> Cc: Jiri Olsa
> Cc: Kaixu Xia
> Cc: Masami Hiramatsu
> Cc: Namhyung Kim
> Cc: Peter Zijlstra
> Cc: Zefan Li
> Cc: pi3or...@163.com
> Link:
> http://lkml.kernel.org/n/1440151770-129878-12-git-send-email-wangn...@huawei.com
> ---
> tools/perf/util/bpf-loader.c | 6 ++
> tools/perf/util/probe-event.c | 17 -
> tools/perf/util/probe-event.h | 1 +
> tools/perf/util/probe-file.c | 5 -
> 4 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
> index c3bc0a8..77eeb99 100644
> --- a/tools/perf/util/bpf-loader.c
> +++ b/tools/perf/util/bpf-loader.c
> @@ -188,6 +188,7 @@ static bool is_probed;
> int bpf__unprobe(void)
> {
> struct strfilter *delfilter;
> + bool old_silent = probe_conf.silent;
> int ret;
>
> if (!is_probed)
> @@ -199,7 +200,9 @@ int bpf__unprobe(void)
> return -ENOMEM;
> }
>
> + probe_conf.silent = true;
> ret = del_perf_probe_events(delfilter);
> + probe_conf.silent = old_silent;
> strfilter__delete(delfilter);
> if (ret < 0 && is_probed)
> pr_debug("Error: failed to delete events: %s\n",
> @@ -215,6 +218,7 @@ int bpf__probe(void)
> struct bpf_object *obj, *tmp;
> struct bpf_program *prog;
> struct perf_probe_event *pevs;
> + bool old_silent = probe_conf.silent;
>
> pevs = calloc(MAX_PROBES, sizeof(pevs[0]));
> if (!pevs)
> @@ -235,9 +239,11 @@ int bpf__probe(void)
> }
> }
>
> + probe_conf.silent = true;
> probe_conf.max_probes = MAX_PROBES;
> /* Let add_perf_probe_events generates probe_trace_event (tevs) */
> err = add_perf_probe_events(pevs, nr_events, false);
> + probe_conf.silent = old_silent;
>
> /* add_perf_probe_events return negative when fail */
> if (err < 0) {
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 57a7bae..e720913 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -52,7 +52,9 @@
> #define PERFPROBE_GROUP "probe"
>
> bool probe_event_dry_run;/* Dry run flag */
> -struct probe_conf probe_conf;
> +struct probe_conf probe_conf = {
> + .silent = false,
> +};
>
> #define semantic_error(msg ...) pr_err("Semantic error :" msg)
>
> @@ -2192,10 +2194,12 @@ static int show_perf_probe_event(const char *group,
> const char *event,
>
> ret = perf_probe_event__sprintf(group, event, pev, module, );
> if (ret >= 0) {
> - if (use_stdout)
> + if (use_stdout && !probe_conf.silent)
> printf("%s\n", buf.buf);
> - else
> + else if (!probe_conf.silent)
> pr_info("%s\n", buf.buf);
> + else
> + pr_debug("%s\n", buf.buf);
> }
> strbuf_release();
>
> @@ -2418,7 +2422,10 @@ static int __add_probe_trace_events(struct
> perf_probe_event *pev,
> }
>
> ret = 0;
> - pr_info("Added new event%s\n", (ntevs > 1) ? "s:" : ":");
> + if (!probe_conf.silent)
> + pr_info("Added new event%s\n", (ntevs > 1) ? "s:" : ":");
> + else
> + pr_debug("Added new event%s\n", (ntevs > 1) ? "s:" : ":");
> for (i = 0; i < ntevs; i++) {
> tev = [i];
> /* Skip if the symbol is out of .text or blacklisted */
> @@ -2454,7 +2461,7 @@ static int __add_probe_trace_events(struct
> perf_probe_event *pev,
> warn_uprobe_event_compat(tev);
>
> /* Note that it is possible to skip all events because of blacklist */
> - if (ret >= 0 && event) {
> + if (ret >= 0 && event && !probe_conf.silent) {
> /* Show how to use the
[GIT PULL] ext4 changes for 4.3
The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus for you to fetch changes up to bdfe0cbd746aa9b2509c2f6d6be17193cf7facd7: Revert "ext4: remove block_device_ejected" (2015-08-16 10:03:57 -0400) Pretty much all bug fixes and clean ups for 4.3, after a lot of features and other churn going into 4.2. Carlos Maiolino (1): ext4: reject journal options for ext2 mounts Daeho Jeong (1): ext4, jbd2: add REQ_FUA flag when recording an error in the superblock Dan Carpenter (2): ext4: simplify some code in read_mmp_block() ext4: silence a format string false positive Eric Sandeen (1): ext4: don't manipulate recovery flag when freezing no-journal fs Eryu Guan (1): ext4: update c/mtime on truncate up Jan Kara (2): jbd2: speedup jbd2_journal_dirty_metadata() jbd2: avoid infinite loop when destroying aborted journal Laurent Navet (2): ext4 crypto: exit cleanly if ext4_derive_key_aes() fails ext4 crypto: fix spelling typo in comment Lukas Czerner (1): jbd2: limit number of reserved credits Tejun Heo (2): ext4: replace ext4_io_submit->io_op with ->io_wbc ext4: implement cgroup writeback support Theodore Ts'o (4): ext4 crypto: use a jbd2 transaction when adding a crypto policy ext4 crypto: check for too-short encrypted file names ext4: ratelimit the file system mounted message Revert "ext4: remove block_device_ejected" zilong.liu (1): ext4 crypto: remove duplicate header file fs/ext4/crypto_fname.c | 5 +++- fs/ext4/crypto_key.c| 4 ++- fs/ext4/crypto_policy.c | 17 ++-- fs/ext4/ext4.h | 2 +- fs/ext4/inode.c | 8 ++ fs/ext4/mmp.c | 48 ++--- fs/ext4/page-io.c | 8 -- fs/ext4/super.c | 50 +- fs/jbd2/checkpoint.c| 39 ++- fs/jbd2/commit.c| 2 +- fs/jbd2/journal.c | 13 +++-- fs/jbd2/transaction.c | 74 --- include/linux/jbd2.h| 3 ++- 13 files changed, 207 insertions(+), 66 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/cpu_pm: fix cpu_cluster_pm_exit comment
On Wednesday, September 02, 2015 04:18:57 PM Lina Iyer wrote: > cpu_cluster_pm_exit() must be sent after cpu_cluster_pm_enter() has been > sent for the cluster and before any cpu_pm_exit() notifications are sent > for any CPU. > > Cc: Nicolas Pitre > Acked-by: Kevin Hilman > Signed-off-by: Lina Iyer OK, I'll queue this one up for the next PM pull request. Thanks! > --- > kernel/cpu_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c > index 9656a3c..009cc9a 100644 > --- a/kernel/cpu_pm.c > +++ b/kernel/cpu_pm.c > @@ -180,7 +180,7 @@ EXPORT_SYMBOL_GPL(cpu_cluster_pm_enter); > * low power state that may have caused some blocks in the same power domain > * to reset. > * > - * Must be called after cpu_pm_exit has been called on all cpus in the power > + * Must be called after cpu_cluster_pm_enter has been called for the power > * domain, and before cpu_pm_exit has been called on any cpu in the power > * domain. Notified drivers can include VFP co-processor, interrupt > controller > * and its PM extensions, local CPU timers context save/restore which > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] PCI: Add support for Enhanced Allocation devices
On Wed, Sep 02, 2015 at 04:21:59PM -0500, Bjorn Helgaas wrote: > On Wed, Sep 02, 2015 at 01:01:27PM -0700, Sean O. Stalley wrote: > > On Wed, Sep 02, 2015 at 02:25:50PM -0500, Bjorn Helgaas wrote: > > > On Wed, Sep 2, 2015 at 12:46 PM, Sean O. Stalley > > > wrote: > > > > > > > Would it be better to modify pci_claim_resource() to support EA instead > > > > of adding pci_ea_claim_resource()? > > > > That way, EA entries would be claimed at the same time as traditional > > > > BARs. > > > > > > Yes, I think so. > > > > Ok, I'll make it work this way in the next patchset. > > > > > Why wouldn't pci_claim_resource() work as-is for EA? I see that > > > pci_ea_get_parent_resource() defaults to iomem_resource or > > > ioport_resource if we don't find a parent, but I don't understand why > > > that's necessary. > > > > EA resources may (or may not) be in the parent's range[1]. > > If the parent doesn't describe this range, we want to default to the > > top-level resource. > > Other than that case, I think pci_claim_resource would work as-is. > > > > -Sean > > > > [1] From the EA ECN: > > For a bridge function that is permitted to implement EA based on the rules > > above, it is > > permitted, but not required, for the bridge function to use EA mechanisms > > to indicate > > resource ranges that are located behind the bridge Function (see Section > > 6.9.1.2). > > [BTW, in EA ECN 23_Oct_2014_Final, this text is in sec 6.9, not 6.9.1.2] > > I agree that it implies EA resources need not be in the parent's *EA* > range. But I would read it as saying "a bridge can use either the > usual window registers or EA to indicate resources forwarded > downstream." > > What happens in the following case? > > 00:00.0: PCI bridge to [bus 01] > 00:00.0: bridge window [mem 0x8000-0x8fff] > 01:00.0: EA 0: [mem 0x9000-0x9000] > > The 00:00.0 bridge knows nothing about EA. The 01:00.0 EA device has > a fixed region at 0x9000. The ECN says: > > System firmware/software must comprehend that such bridge functions > [those that are permitted to implement EA] are not required to > indicate inclusively all resources behind the bridge, and as a > result system firmware/software must make a complete search of all > functions behind the bridge to comprehend the resources used by > those functions. > The intention of this line was to indicate that EA regions are not required to be inside of the Base+Limit window. If an EA device is connected below a bridge, that bridge must be aware of EA. It is assumed that the bridge is aware of the fixed EA regions below it, so system software doesn't need to program the window to include them. This is part of the reason why EA devices must be permanently connected (to make sure it doesn't end up behind an old bridge). Re-reading the spec, I can see that this requirement isn't explicitly stated. > A bridge was never required to indicate, e.g., via its window > registers, anything about the resources behind it. Software always > had to search behind the bridge and look at all the downstream BARs. > What's new here is that software now has to look for downstream EA > entries in addition to BARs, and the EA entries are at fixed > addresses. > > My question is what the implication is for address routing performed > by the bridge. The EA ECN doesn't mention any changes there, so I > assume it is software's responsibility to reprogram the 00:00.0 mem > window so it includes [mem 0x9000-0x9000]. The Base+Limit window is not required to include EA regions. In the example shown in in Figure 6-1, the bridge above Bus N [...] is permitted to not indicate the resources used by the two functions in “Si component C” Before, all the BAR regions would be inside the window range. The Base+Limit "indicated" the Range of all the BARs behind the bridge. Once the window was set, system software could avoid an address collision with every device on the bus by avoiding the window. BAR-equivalent EA regions aren't required to be inside the Base+Limit window, which is why System firmware/software must search all the functions behind a bus to avoid address collisions. > If software does have to reprogram that window, the normal > pci_claim_resource() should work. If it doesn't have to reprogram the > window, and there's some magical way for 01:00.0 to work even though > we don't route address space to it, I suspect we'll need significantly > more changes than just pci_ea_claim_resource(), because then 00:00.0 > is really not a PCI bridge any more. > > Bjorn -Sean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible deadlock related to CPU hotplug and kernfs
On Wednesday, September 02, 2015 12:14:45 PM Tejun Heo wrote: > On Tue, Sep 01, 2015 at 03:12:34PM +0800, Jiang Liu wrote: > > Hi Rafael and Tejun, > > When running CPU hotplug tests, it triggers an lockdep warning > > as follow. The two possible deadlock paths are: > > 1) echo x > /sys/devices/system/cpu/cpux/online > >->kernfs_fop_write() > > ->kernfs_get_active() > > 1.a) ->rwsem_acquire_read(>dep_map, 0, 1, _RET_IP_); > > ->cpu_up() > > 1.b) ->cpu_hotplug_begin()[lock_map_acquire(_hotplug.dep_map)] > > 2) hardware triggers hotplug evetns > >->acpi_device_hotplug() > > ->acpi_processor_remove() > > 2.a) ->cpu_hotplug_begin()[lock_map_acquire(_hotplug.dep_map)] > > ->unregister_cpu() > >->device_del() > > ->kernfs_remove_by_name_ns() > >->__kernfs_remove() > > ->kernfs_drain() > > 2.b) ->rwsem_acquire(>dep_map, 0, 0, _RET_IP_) > > > > So there is a possible deadlock scenario among 1.a, 1.b, 2.a and 2.b. > > I'm not familiar with kernfs, so could you please help to comment: > > 1) whether is a real deadlock issue? > > Yes, it seems to be. It's highly unlikely but still possible. Hmm. So acpi_device_hotplug() calls lock_device_hotplug() which simply acquires device_hotplug_lock. It is held throughout the entire hot-add/hot-remove code path. Witing anything to /sys/devices/system/cpu/cpux/online goes through online_store() in drivers/base/core.c and that does lock_device_hotplug_sysfs() which then attempts to acquire device_hotplug_lock using mutex_trylock(). And it only calls either device_online() or device_offline() if it ends up with the lock held. Quite frankly, I don't see how these particular two code paths can deadlock in any way. So either a third code path is involved which is not executed under device_hotplug_lock, or lockdep needs to be told to actually take device_hotplug_lock into account in this case IMO. > > 2) any recommended way to get it fixed? > > This usually happens with "delete" files and it's worked around by > performing special self-removal on the file before actually removing > the device. I suppose on/offline files would need to turn off > active_protection with kernfs_[un]break_active_protection() which > should probably grow sysfs and device layer wrappers. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Firmware Signing
On Wed, Sep 02, 2015 at 08:05:36PM -0400, Mimi Zohar wrote:
> On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > > OK great, I think that instead of passing the actual routine name we
> > > > should
> > > > instead pass an enum type for to the LSM, that'd be easier to parse and
> > > > we'd
> > > > then have each case well documented. Each LSM then could add its own
> > > > documetnation for this and can switch on it. If we went with a name
> > > > we'd have
> > > > to to use something like __func__ and then parse that, its not clear if
> > > > we need
> > > > to get that specific.
> > >
> > > Agreed. IMA already defines an enumeration.
> > >
> > > /* IMA policy related functions */
> > > enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> > > FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> > >
> >
> > We want something that is not only useful for IMA but any other LSM,
> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > be broad, perhaps its best we define then a generic set of enums to
> > which IMA can map them to then and let it decide. This would ensure
> > that the kernel defines each use caes for file inspection carefully,
> > documents and defines them and if an LSM wants to bunch a set together
> > it can do so easily with a switch statement to map set of generic
> > file checks in kernel to a group it already handles.
>
> The names are based on the calling security hook. For a description of
> each of these security hooks refer to include/linux/lsm_hooks.h.
I see, thanks, ok so BPRM_CHECK = for binary loading, are you folks
really wanting to unify LSM hooks for firmware, modules, and binary
data ?
POST_SETATTR seems to be for inode_post_setxattr, so that as well?
POLICY_CHECK seems broad, not sure what to relate that to exactly.
Is this just SELinux polify files? Or is this something more broad?
> > For instance at least in the short term we'd try to unify:
> >
> > security_kernel_fw_from_file()
> > security_kernel_module_from_file()
> >
> > to perhaps:
> >
> > security_kernel_from_file()
> >
> > As far, as far as I can tell, the only ones we'd be ready to start
> > grouping immediately or with small amount of work rather soon:
> >
> > /**
> > *
> > * enum security_filecheck - known kernel security file checks types
> > *
> > * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> > * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel
> > module
> > * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a
> > firmware
> > * file or a system data file read from /lib/firmware/* by firmware_class
> > * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel
> > file
> > * used by kexec
> > * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an
> > initramfs
> > * used by kexec
> >
> > * The kernel reads files directly from the filesystem for a series of
> > * operations. The list of files the kernel reads from the filesystem are
> > * limited and each type of file consumed may have a different format and
> > * security vetting procedures. The kernel enables LSMs to vet for these
> > files
> > * through a shared LSM hook prior to consumption. This list documents the
> > * different special kernel file types read by the kernel, it enables LSMs
> > * to vet for each differently if needed.
> > enum security_filecheck {
> > SECURITY_FILECHECK_UNSPEC,
> > SECURITY_FILECHECK_MODULE,
> > SECURITY_FILECHECK_SYSDATA,
> > SECURITY_FILECHECK_KEXEC_KERNEL,
> > SECURITY_FILECHECK_KEXEC_INITRAMFS,
> > };
> >
> > Provided the MOK thing or alternative gets addressed we could also soon add
> > something for SELinux policy files but that needs to be discussed further
> > it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> > this would likely need further discussion, its why I didn't list it above.
>
> Oh, I'm really confused as to why MOK would be a separate hook. I
> thought the discussion was about using a key in the UEFI MOK DB for
> verifying locally signed files.
That's correct, and no I was not thinking of a separate hook but rather
a type that lets the LSM know that MOK was used to sign the file consumed.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/31] perf tools: Introduce dummy evsel
Hi,
On Sat, Aug 29, 2015 at 04:21:37AM +, Wang Nan wrote:
> This patch allows linking dummy evsel onto evlist as a placeholder. It
> is for following patch which allows passing BPF object using '--event
> object.o'.
>
> Doesn't link other event selectors, if passing a BPF object file to
> '--event', nothing is linked onto evlist. Instead, events described in
> BPF object file are probed and linked in a delayed manner because we
> want do all probing work together. Therefore, evsel for events in BPF
> object would be linked at the end of evlist. Which causes a small
> problem that, if passing '--filter' setting after object file, the
> filter option won't be correctly applied to those events.
>
> This patch links dummy onto evlist, so following --filter can be
> collected by the dummy evsel. For this reason dummy evsels are set to
> PERF_TYPE_TRACEPOINT.
I understand the need of the dummy event. But we already have dummy
event so it's confusing to have similar event IMHO. So what about
using existing dummy event instead? You can save a link to a bpf
object in the dummy evsel (to check it later) and change to allow
setting filter on dummy events IMHO.
>
> Due to the possibility of existance of dummy evsel,
> perf_evlist__purge_dummy() must be called right after parse_options().
> This patch adds it to record, top, trace and stat builtin commands.
> Further patch moves it down after real BPF events are processed with.
IMHO it'd be better to do this kind of job in a single place -
e.g. perf_evlist__config() ? - so that other commands get benefits
from it easily.
Thanks,
Namhyung
>
> Signed-off-by: Wang Nan
> Cc: Arnaldo Carvalho de Melo
> Cc: Alexei Starovoitov
> Cc: Brendan Gregg
> Cc: Daniel Borkmann
> Cc: David Ahern
> Cc: He Kuang
> Cc: Jiri Olsa
> Cc: Kaixu Xia
> Cc: Masami Hiramatsu
> Cc: Namhyung Kim
> Cc: Peter Zijlstra
> Cc: Zefan Li
> Cc: pi3or...@163.com
> Link:
> http://lkml.kernel.org/r/1440742821-44548-4-git-send-email-wangn...@huawei.com
> ---
> tools/perf/builtin-record.c| 2 ++
> tools/perf/builtin-stat.c | 1 +
> tools/perf/builtin-top.c | 1 +
> tools/perf/builtin-trace.c | 1 +
> tools/perf/util/evlist.c | 19 +++
> tools/perf/util/evlist.h | 1 +
> tools/perf/util/evsel.c| 32
> tools/perf/util/evsel.h| 6 ++
> tools/perf/util/parse-events.c | 25 +
> 9 files changed, 84 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index a660022..81829de 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -1112,6 +1112,8 @@ int cmd_record(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> argc = parse_options(argc, argv, record_options, record_usage,
> PARSE_OPT_STOP_AT_NON_OPTION);
> + perf_evlist__purge_dummy(rec->evlist);
> +
> if (!argc && target__none(>opts.target))
> usage_with_options(record_usage, record_options);
>
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 7aa039b..99b62f1 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -1208,6 +1208,7 @@ int cmd_stat(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> argc = parse_options(argc, argv, options, stat_usage,
> PARSE_OPT_STOP_AT_NON_OPTION);
> + perf_evlist__purge_dummy(evsel_list);
>
> interval = stat_config.interval;
>
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index 8c465c8..246203b 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -1198,6 +1198,7 @@ int cmd_top(int argc, const char **argv, const char
> *prefix __maybe_unused)
> perf_config(perf_top_config, );
>
> argc = parse_options(argc, argv, options, top_usage, 0);
> + perf_evlist__purge_dummy(top.evlist);
> if (argc)
> usage_with_options(top_usage, options);
>
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index 4e3abba..57712b9 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -3099,6 +3099,7 @@ int cmd_trace(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> argc = parse_options_subcommand(argc, argv, trace_options,
> trace_subcommands,
>trace_usage, PARSE_OPT_STOP_AT_NON_OPTION);
> + perf_evlist__purge_dummy(trace.evlist);
>
> if (trace.trace_pgfaults) {
> trace.opts.sample_address = true;
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 8d00039..8a4e64d 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -1696,3 +1696,22 @@ void perf_evlist__set_tracking_event(struct
> perf_evlist *evlist,
>
> tracking_evsel->tracking = true;
> }
> +
>
Re: [PATCH] ARM: dts: Add ddc i2c reference to veyron
Rob, On Wed, Sep 2, 2015 at 5:13 PM, Rob Herring wrote: > On Wed, Sep 2, 2015 at 4:25 PM, Douglas Anderson > wrote: >> The ddc-i2c-bus property was missing from the veyron dtsi file since >> downstream the ddc-i2c-bus was still being specified in rk3288.dtsi and >> nobody noticed when the veyron dtsi was sent upstream. Add it. >> >> Signed-off-by: Douglas Anderson >> --- >> Note: I noticed that this was wrong but I don't currently have >> graphics up and running on upstream on veyron. Posting this anyway >> since it's pretty clear that it's needed. If someone else wants to >> try it out that'd be nice, otherwise I'll put it on my list to figure >> out how to get myself setup for graphics upstream. ;) > > Based on your other patch, this is temporary, right? Yes, though since I'm not personally working on the other patch series upstream I can't say for how long the "temporary" is.. I mostly posted the 2nd patch because it was clearly correct to add some pinmuxing states and could land any time, so I thought I'd be helpful. You're right that in the Chrome OS tree I turned right around and effectively removed the "ddc-i2c-bus", but having it land first adds a much better logical progression (make it the same as everyone else and _then_ change it). It also provides a revert path if something goes wrong. :) > I've been looking at DRM a lot lately. I think specifying the i2c bus > in the hdmi chip or IP block node is wrong. If the I2C host is > separate from the HDMI block, then it's only connection is to the HDMI > connector. So the I2C host to the connector relationship is what the > DT should describe. HPD gpio is similar. Now if the HDMI bridge > controls DDC and HPD directly, then we don't need to describe those > connections. I will say that I know very very little about DRM. Mostly I just visit it when there's some bug I'm running into that I can't find a better suited owner for. ;) I'm not sure I followed your whole paragraph. Could you give a fragment of DTS for how you'd imagine this ought to work? Also: the patch I submitted does match the current bindings if I understand it right. ...as is typical with device tree, if we want to change the bindings we've got to have a really good reason because we'd either need to figure out how to deal with existing DTBs in the field that need to run with newer kernels (if those exist). -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 01/16] drm: exynos/dp: fix code style
On 01.09.2015 14:46, Yakir Yang wrote:
> After run "checkpatch.pl -f --subjective" command, I see there
> are lots of alignment problem in exynos_dp driver, so let just
> fix them.
Hi,
Warnings from checkpatch are not a reason for a commit. Reason for a
commit could be for example an unreadable code, violation of
coding-style leading to decrease in code maintainability or just
improving the code readability so it will be easier to review and
maintain it.
You do not make commits because some tool tells you that. We do not
listen to machines :) ... If that would be the case, the commit could be
made automatically, without human interaction. Such automated commit
could be even easily tested by the machine by comparing object files.
Especially that you enabled "subjective" rule. This is not a valid
motivation for a commit.
Please rephrase this to sensible reason and convince that change is
worth the effort.
>
> - Take Romain suggest, rebase on linux-next branch
That comment seems unrelated to the commit. Please remove it.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Take Joe Preches advise, improved commit message more readable, and
> avoid using some uncommon style like bellow:
> - retval = exynos_dp_read_bytes_from_i2c(...
> ...)
> + retval =
> + exynos_dp_read_bytes_from_i2c(..);
>
> drivers/gpu/drm/exynos/exynos_dp_core.c | 226
>
> drivers/gpu/drm/exynos/exynos_dp_core.h | 54
> drivers/gpu/drm/exynos/exynos_dp_reg.c | 106 +++
> 3 files changed, 188 insertions(+), 198 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index d66ade0..266f7f7 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -115,8 +115,8 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
>
> /* Read Extension Flag, Number of 128-byte EDID extension blocks */
> retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
> - EDID_EXTENSION_FLAG,
> - _block);
> + EDID_EXTENSION_FLAG,
> + _block);
> if (retval)
> return retval;
>
> @@ -124,10 +124,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
> dev_dbg(dp->dev, "EDID data includes a single extension!\n");
>
> /* Read EDID data */
> - retval = exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
> - EDID_HEADER_PATTERN,
> - EDID_BLOCK_LENGTH,
> - [EDID_HEADER_PATTERN]);
> + retval = exynos_dp_read_bytes_from_i2c(
> + dp, I2C_EDID_DEVICE_ADDR,
> + EDID_HEADER_PATTERN,
> + EDID_BLOCK_LENGTH,
> + [EDID_HEADER_PATTERN]);
> if (retval != 0) {
> dev_err(dp->dev, "EDID Read failed!\n");
> return -EIO;
> @@ -139,11 +140,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
> }
>
> /* Read additional EDID data */
> - retval = exynos_dp_read_bytes_from_i2c(dp,
> - I2C_EDID_DEVICE_ADDR,
> - EDID_BLOCK_LENGTH,
> - EDID_BLOCK_LENGTH,
> - [EDID_BLOCK_LENGTH]);
> + retval = exynos_dp_read_bytes_from_i2c(
> + dp, I2C_EDID_DEVICE_ADDR,
> + EDID_BLOCK_LENGTH,
> + EDID_BLOCK_LENGTH,
> + [EDID_BLOCK_LENGTH]);
> if (retval != 0) {
> dev_err(dp->dev, "EDID Read failed!\n");
> return -EIO;
> @@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct exynos_dp_device
> *dp)
> }
>
> exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
> - _vector);
> + _vector);
> if (test_vector & DP_TEST_LINK_EDID_READ) {
> - exynos_dp_write_byte_to_dpcd(dp,
> - DP_TEST_EDID_CHECKSUM,
> + exynos_dp_write_byte_to_dpcd(
> + dp, DP_TEST_EDID_CHECKSUM,
> edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
> - exynos_dp_write_byte_to_dpcd(dp,
> - DP_TEST_RESPONSE,
> +
Re: Linux Firmware Signing
On Wed, Sep 02, 2015 at 07:54:13PM -0400, Mimi Zohar wrote: > On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote: > > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: > > > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote: > > > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote: > > > > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote: > > > Right so there are different solutions to this problem, it will depend on > > the > > distribution and solution they have in place for this. For instance maybe > > some > > distros may be satisfied with the integrity of the initramfs for kexec *iff* > > they can vet for the integrity of the components that build the initramfs on > > the target system, or perhaps they distribute the initramfs used by some > > systems so they use singing facilities trusted by the kernel, or in the IMA > > case you do boot up vetting through xatrrs and IMA. > > > > A lot of this means a lot of these signing facilities then should be > > optional > > and work in a permissive mode. Part of my earlier work (already merged) on > > the firmware > > signing stuff was to take out from module signing code the part that let it > > be > > permissive with my goal to re-share the same strategy for other purposes. > > This > > is accomplished by using the bool_enable_only module parameter, for > > instance fw > > signing will use: > > > > +static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE); > > +#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE > > +module_param(sysdata_sig_enforce, bool_enable_only, 0644); > > +#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */ > > > > Technically it should also be possible to remove the #ifndef provided we can > > all rest assured no bullets can be put through it. Anyway, that's the gist > > of > > the permissive model copied from module signing. If we have a lot of similar > > users it begs the question if we should somehow drivertize a generic > > interface > > for these things so that the actual implemenation that deals with > > permissivity > > is shared, its perhaps too early to do that now but something to keep in > > mind > > as it does sound like we will have a bit of users of the same mechanisms / > > strategy. Exactly how they need to be differentiated remains to be seen. > > Ok. Each "hook" would require a separate config option to allow > flexibility. With this design, the decision for requiring signatures > would be made at build. Do we really want policy hard coded into the > kernel? (IMA is policy based.) The thing is module signing is a policy built into the kernel, and as such firmware signing is following that tradition as well. The way historically module signing has evolved over time as LSMs have is through separate frameworks as such naturally its only now we've started to consider module signign through the eyes of a possible future core-LSM that others can stack over. Even with this long term possibility its still a kernel policy. Other similar functionality will natrally follow suit. > > > > > initramfs, > > > > > > > > Hm, what code path? > > > > > > In addition, the files within the initramfs should be measured and > > > verified. There isn't a need for a new hook, but for xattr support in > > > CPIO. I started adding that support last winter - > > > http://lwn.net/Articles/630101/ . Others have requested other changes, > > > not related to xattrs, before bumping the CPIO magic number. There > > > should be a discussion as to what else needs to be done. > > > > I see, thanks. Another way to do this is to copy the module signing > > strategy and since the initramfs is linked in just peg the sinagure of the > > blog at the end. This of course would mean you have to be permissive to > > only enable folks who want this feature. > > At the same time the boot loader verifies the kernel signature, it could > verify the the initramfs signature. kexec should emulate whatever the > boot loader's method for verifying the initramfs signature. Up to you guys :) > > > > > that have > > > > > been or need to be addressed. Since then, a new kexec syscall, file > > > > > descriptor based, was upstreamed that appraises the image. Until we > > > > > can > > > > > preserve the measurement list across kexec, > > > > > > > > I'm sorry I do not follow, can you elaborate on what you mean by this. > > > > Its not clear to me what you mean by the measurement list. Do you mean > > > > all the above items? > > > > > > A measurement is a hash of the file which is stored in the measurement > > > list /ima/ascii_runtime_measurements and is used to extend > > > the TPM (eg. PCR 10). The measurement list, in conjunction with a > > > quote of the TPM PCRs, can be used to remotely detect whether a system > > > has been compromised. > > > > I see thanks. In light of that its unclear why you'd want to "preserve" > > the measurement list from one boot onto another. > > The
Re: [PATCH v2] security: device_cgroup: fix RCU lockdep splat
On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote:
> cc'ing Paul.
>
> On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote:
> > while booting AM437x device, the following splat
> > triggered:
> >
> > [ 12.005238] ===
> > [ 12.009749] [ INFO: suspicious RCU usage. ]
> > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted
> > [ 12.019050] ---
> > [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex
> > called without proper synchronization!
> ...
> > [ 12.128326] [] (verify_new_ex) from []
> > (devcgroup_access_write+0x374/0x658)
> > [ 12.137426] [] (devcgroup_access_write) from []
> > (cgroup_file_write+0x28/0x1bc)
> > [ 12.146796] [] (cgroup_file_write) from []
> > (kernfs_fop_write+0xc0/0x1b8)
> > [ 12.155620] [] (kernfs_fop_write) from []
> > (__vfs_write+0x1c/0xd8)
> > [ 12.163783] [] (__vfs_write) from []
> > (vfs_write+0x90/0x16c)
> > [ 12.171426] [] (vfs_write) from []
> > (SyS_write+0x44/0x9c)
> > [ 12.178806] [] (SyS_write) from []
> > (ret_fast_syscall+0x0/0x1c)
>
> This shouldn't be happening because devcgroup_access_write() always
> grabs devcgroup_mutex. Looking at the log, the culprit seems to be
> f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to
> RCU_LOCKDEP_WARN()"). It missed the bang for the second test while
> inverting it, so adding rcu_read_lock() isn't the right fix here.
>
> Paul, can you please fix it?
Gah! Please see below.
Thanx, Paul
security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition
f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
introduced a bug by incorrectly inverting the condition when moving from
rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). This commit therefore fixes
the inversion.
Reported-by: Felipe Balbi
Reported-by: Tejun Heo
Signed-off-by: Paul E. McKenney
Cc: Serge Hallyn
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 73455089feef..03c1652c9a1f 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
bool match = false;
RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
-lockdep_is_held(_mutex),
+!lockdep_is_held(_mutex),
"device_cgroup:verify_new_ex called without proper
synchronization");
if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: Add ddc i2c reference to veyron
On Wed, Sep 2, 2015 at 4:25 PM, Douglas Anderson wrote:
> The ddc-i2c-bus property was missing from the veyron dtsi file since
> downstream the ddc-i2c-bus was still being specified in rk3288.dtsi and
> nobody noticed when the veyron dtsi was sent upstream. Add it.
>
> Signed-off-by: Douglas Anderson
> ---
> Note: I noticed that this was wrong but I don't currently have
> graphics up and running on upstream on veyron. Posting this anyway
> since it's pretty clear that it's needed. If someone else wants to
> try it out that'd be nice, otherwise I'll put it on my list to figure
> out how to get myself setup for graphics upstream. ;)
Based on your other patch, this is temporary, right?
I've been looking at DRM a lot lately. I think specifying the i2c bus
in the hdmi chip or IP block node is wrong. If the I2C host is
separate from the HDMI block, then it's only connection is to the HDMI
connector. So the I2C host to the connector relationship is what the
DT should describe. HPD gpio is similar. Now if the HDMI bridge
controls DDC and HPD directly, then we don't need to describe those
connections.
Rob
>
> arch/arm/boot/dts/rk3288-veyron.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
> b/arch/arm/boot/dts/rk3288-veyron.dtsi
> index 2fa7a0d..275c78c 100644
> --- a/arch/arm/boot/dts/rk3288-veyron.dtsi
> +++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
> @@ -158,6 +158,7 @@
> };
>
> {
> + ddc-i2c-bus = <>;
> status = "okay";
> };
>
> --
> 2.5.0.457.gab17608
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
