[RFC/PATCH v2] perf report: Show random usage tip on the help line
Currently perf report only shows a help message "For a higher level
overview, try: perf report --sort comm,dso" unconditionally (even if
the sort keys were used). Add more help tips and show randomly.
Load tips from ${prefix}/share/doc/perf-tip/tips.txt file.
$ perf report | tail
0.10% swapper [kernel.vmlinux] [k] irq_exit
0.09% swapper [kernel.vmlinux] [k] flush_smp_call_function_queue
0.08% swapper [kernel.vmlinux] [k] native_write_msr_safe
0.03% swapper [kernel.vmlinux] [k] group_sched_in
0.01% perf [kernel.vmlinux] [k] native_write_msr_safe
#
# (Tip: Search options using a keyword: perf report -h filter)
#
Signed-off-by: Namhyung Kim
---
More tips will be added later once this basic structure is done.
tools/perf/Build | 1 +
tools/perf/Documentation/tips.txt | 14 ++
tools/perf/Makefile.perf | 3 +++
tools/perf/builtin-report.c | 2 +-
tools/perf/config/Makefile| 6 ++
tools/perf/perf.c | 4
tools/perf/util/util.c| 27 +++
tools/perf/util/util.h| 2 ++
8 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/Documentation/tips.txt
diff --git a/tools/perf/Build b/tools/perf/Build
index 00c4b8c3d8ca..6b67e6f4179f 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -41,6 +41,7 @@ CFLAGS_perf.o +=
-DPERF_HTML_PATH="BUILD_STR($(htmldir_SQ))" \
-DPREFIX="BUILD_STR($(prefix_SQ))"
\
-include $(OUTPUT)PERF-VERSION-FILE
CFLAGS_builtin-trace.o+=
-DSTRACE_GROUPS_DIR="BUILD_STR($(STRACE_GROUPS_DIR_SQ))"
+CFLAGS_builtin-report.o += -DTIPDIR="BUILD_STR($(tipdir_SQ))"
libperf-y += util/
libperf-y += arch/
diff --git a/tools/perf/Documentation/tips.txt
b/tools/perf/Documentation/tips.txt
new file mode 100644
index ..383aef8f9509
--- /dev/null
+++ b/tools/perf/Documentation/tips.txt
@@ -0,0 +1,14 @@
+For a higher level overview, try: perf report --sort comm,dso
+Group related events with: perf record -e '{cycles,instructions}:S'
+Compare performance results with: perf diff [ ]
+Boolean options have negative forms like: perf report --no-children
+Customize output of perf script with: perf script -F event,ip,sym
+Generate a script for your data: perf script -g
+Save output of perf stat using: perf stat record
+Create archive of data to see it on other machine: perf archive
+Search options using a keyword: perf report -h
+Use parent filter to see specific call path: perf report -p
+listing interested events using substring match: perf list
+To see list of saved events and attributes: perf evlist -v
+Use --symfs if your symbol files are in non-standard location
+To see callchains in a more compact form: perf report -g folded
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 404e3b1c4e31..b6ee9c1982ec 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -567,6 +567,9 @@ endif
$(call QUIET_INSTALL, perf_completion-script) \
$(INSTALL) -d -m 755
'$(DESTDIR_SQ)$(sysconfdir_SQ)/bash_completion.d'; \
$(INSTALL) perf-completion.sh
'$(DESTDIR_SQ)$(sysconfdir_SQ)/bash_completion.d/perf'
+ $(call QUIET_INSTALL, perf-tip) \
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(tipdir_SQ)'; \
+ $(INSTALL) Documentation/tips.txt -t '$(DESTDIR_SQ)$(tipdir_SQ)'
install-tests: all install-gtk
$(call QUIET_INSTALL, tests) \
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index f10c663af996..965143c98265 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -433,7 +433,7 @@ static int report__browse_hists(struct report *rep)
int ret;
struct perf_session *session = rep->session;
struct perf_evlist *evlist = session->evlist;
- const char *help = "For a higher level overview, try: perf report
--sort comm,dso";
+ const char *help = perf_report_tip(TIPDIR);
switch (use_browser) {
case 1:
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 18b2f96d0941..254d06e39bea 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -691,6 +691,7 @@ sharedir = $(prefix)/share
template_dir = share/perf-core/templates
STRACE_GROUPS_DIR = share/perf-core/strace/groups
htmldir = share/doc/perf-doc
+tipdir = share/doc/perf-tip
ifeq ($(prefix),/usr)
sysconfdir = /etc
ETC_PERFCONFIG = $(sysconfdir)/perfconfig
@@ -717,6 +718,7 @@ infodir_SQ = $(subst ','\'',$(infodir))
perfexecdir_SQ = $(subst ','\'',$(perfexecdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
htmldir_SQ = $(subst ','\'',$(htmldir))
+tipdir_SQ = $(subst ','\'',$(tipdir))
prefix_SQ = $(subst ','\'',$(prefix))
sysconfdir_SQ = $(subst ','\'',$(sysconfdir))
libdir_SQ = $(subst
[PATCH 4/6] [ALSA] portman2x4 - NULL check
Instead of checking var == NULL, the kernel coding style recommends
writing it as !var.
Signed-off-by: Sudip Mukherjee
---
sound/drivers/portman2x4.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/drivers/portman2x4.c b/sound/drivers/portman2x4.c
index 65b0650..985cf67 100644
--- a/sound/drivers/portman2x4.c
+++ b/sound/drivers/portman2x4.c
@@ -105,7 +105,7 @@ static int portman_create(struct snd_card *card,
*rchip = NULL;
pm = kzalloc(sizeof(struct portman), GFP_KERNEL);
- if (pm == NULL)
+ if (!pm)
return -ENOMEM;
/* Init chip specific data */
@@ -764,7 +764,7 @@ static int snd_portman_probe(struct platform_device *pdev)
snd_portman_interrupt, /* ISR */
PARPORT_DEV_EXCL, /* flags */
(void *)card); /* private */
- if (pardev == NULL) {
+ if (!pardev) {
snd_printd("Cannot register pardevice\n");
err = -EIO;
goto __err;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] [ALSA] portman2x4 - remove space
checkpatch complains about space before tab. Signed-off-by: Sudip Mukherjee --- sound/drivers/portman2x4.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/sound/drivers/portman2x4.c b/sound/drivers/portman2x4.c index 4f9717b..65b0650 100644 --- a/sound/drivers/portman2x4.c +++ b/sound/drivers/portman2x4.c @@ -123,21 +123,21 @@ static int portman_create(struct snd_card *card, */ /* Standard PC parallel port status register equates. */ -#definePP_STAT_BSY 0x80/* Busy status. Inverted. */ -#definePP_STAT_ACK 0x40/* Acknowledge. Non-Inverted. */ -#definePP_STAT_POUT0x20/* Paper Out.Non-Inverted. */ -#definePP_STAT_SEL 0x10/* Select. Non-Inverted. */ -#definePP_STAT_ERR 0x08/* Error.Non-Inverted. */ +#definePP_STAT_BSY 0x80/* Busy status. Inverted. */ +#definePP_STAT_ACK 0x40/* Acknowledge. Non-Inverted. */ +#definePP_STAT_POUT0x20/* Paper Out.Non-Inverted. */ +#definePP_STAT_SEL 0x10/* Select. Non-Inverted. */ +#definePP_STAT_ERR 0x08/* Error.Non-Inverted. */ /* Standard PC parallel port command register equates. */ -#definePP_CMD_IEN 0x10/* IRQ Enable. Non-Inverted. */ -#definePP_CMD_SELI 0x08/* Select Input. Inverted. */ -#definePP_CMD_INIT 0x04/* Init Printer. Non-Inverted. */ -#definePP_CMD_FEED 0x02/* Auto Feed.Inverted. */ +#definePP_CMD_IEN 0x10/* IRQ Enable. Non-Inverted. */ +#definePP_CMD_SELI 0x08/* Select Input. Inverted. */ +#definePP_CMD_INIT 0x04/* Init Printer. Non-Inverted. */ +#definePP_CMD_FEED 0x02/* Auto Feed.Inverted. */ #definePP_CMD_STB 0x01/* Strobe. Inverted. */ /* Parallel Port Command Register as implemented by PCP2x4. */ -#defineINT_EN PP_CMD_IEN /* Interrupt enable. */ +#defineINT_EN PP_CMD_IEN /* Interrupt enable. */ #defineSTROBE PP_CMD_STB /* Command strobe. */ /* The parallel port command register field (b1..b3) selects the @@ -148,7 +148,7 @@ static int portman_create(struct snd_card *card, #defineRXDATA0 (0 << 1)/* PCP RxData channel 0. */ #defineRXDATA1 (1 << 1)/* PCP RxData channel 1. */ #defineGEN_CTL (2 << 1)/* PCP General Control Register. */ -#defineSYNC_CTL(3 << 1)/* PCP Sync Control Register. */ +#defineSYNC_CTL(3 << 1)/* PCP Sync Control Register. */ #defineTXDATA0 (4 << 1)/* PCP TxData channel 0. */ #defineTXDATA1 (5 << 1)/* PCP TxData channel 1. */ #defineTXDATA2 (6 << 1)/* PCP TxData channel 2. */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] [ALSA] portman2x4 - fix trailing whitespace
Trailing whitespace is not encouraged by Kernel coding style.
Signed-off-by: Sudip Mukherjee
---
sound/drivers/portman2x4.c | 50 +++---
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/sound/drivers/portman2x4.c b/sound/drivers/portman2x4.c
index 464385a..ba0860d 100644
--- a/sound/drivers/portman2x4.c
+++ b/sound/drivers/portman2x4.c
@@ -57,7 +57,7 @@ static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
-static struct platform_device *platform_devices[SNDRV_CARDS];
+static struct platform_device *platform_devices[SNDRV_CARDS];
static int device_count;
module_param_array(index, int, NULL, S_IRUGO);
@@ -105,7 +105,7 @@ static int portman_create(struct snd_card *card,
*rchip = NULL;
pm = kzalloc(sizeof(struct portman), GFP_KERNEL);
- if (pm == NULL)
+ if (pm == NULL)
return -ENOMEM;
/* Init chip specific data */
@@ -140,7 +140,7 @@ static int portman_create(struct snd_card *card,
#defineINT_EN PP_CMD_IEN /* Interrupt enable. */
#defineSTROBE PP_CMD_STB /* Command strobe. */
-/* The parallel port command register field (b1..b3) selects the
+/* The parallel port command register field (b1..b3) selects the
* various "registers" within the PC/P 2x4. These are the internal
* address of these "registers" that must be written to the parallel
* port command register.
@@ -218,7 +218,7 @@ static inline void portman_write_data(struct portman *pm,
u8 value)
parport_write_data(pm->pardev->port, value);
}
-static void portman_write_midi(struct portman *pm,
+static void portman_write_midi(struct portman *pm,
int port, u8 mididata)
{
int command = ((port + 4) << 1);
@@ -234,20 +234,20 @@ static void portman_write_midi(struct portman *pm,
*/
command |= INT_EN;
- /* Disable interrupts so that the process is not interrupted, then
-* write the address associated with the current Tx channel to the
+ /* Disable interrupts so that the process is not interrupted, then
+* write the address associated with the current Tx channel to the
* PP Command Reg. Do not set the Strobe signal yet.
*/
do {
portman_write_command(pm, command);
- /* While the address lines settle, write parallel output data
to
+ /* While the address lines settle, write parallel output data to
* PP Data Reg. This has no effect until Strobe signal is
asserted.
*/
portman_write_data(pm, mididata);
-
+
/* If PCP channel's TxEmpty is set (TxEmpty is read through the
PP
* Status Register), then go write data. Else go back and wait.
*/
@@ -370,7 +370,7 @@ static int portman_read_midi(struct portman *pm, int port)
/*
* Checks if any input data on the given channel is available
- * Checks RxAvail
+ * Checks RxAvail
*/
static int portman_data_avail(struct portman *pm, int channel)
{
@@ -456,7 +456,7 @@ static int portman_probe(struct parport *p)
* hardware handshake lines to midi box:
*
* Strobe = 0
-* Interrupt Enable = 0
+* Interrupt Enable = 0
*/
/* 2 */
parport_write_control(p, 0);
@@ -481,7 +481,7 @@ static int portman_probe(struct parport *p)
/* 7 */
parport_write_control(p, 0);/* Reset Strobe=0. */
- /* Check if Tx circuitry is functioning properly. If initialized
+ /* Check if Tx circuitry is functioning properly. If initialized
* unit TxEmpty is false, send out char and see if if goes true.
*/
/* 8 */
@@ -567,12 +567,12 @@ static int snd_portman_rawmidi_create(struct snd_card
*card)
struct snd_rawmidi *rmidi;
struct snd_rawmidi_substream *substream;
int err;
-
- err = snd_rawmidi_new(card, CARD_NAME, 0,
- PORTMAN_NUM_OUTPUT_PORTS,
- PORTMAN_NUM_INPUT_PORTS,
+
+ err = snd_rawmidi_new(card, CARD_NAME, 0,
+ PORTMAN_NUM_OUTPUT_PORTS,
+ PORTMAN_NUM_INPUT_PORTS,
);
- if (err < 0)
+ if (err < 0)
return err;
rmidi->private_data = pm;
@@ -584,9 +584,9 @@ static int snd_portman_rawmidi_create(struct snd_card *card)
pm->rmidi = rmidi;
/* register rawmidi ops */
- snd_rawmidi_set_ops(rmidi, SNDRV_RAWMIDI_STREAM_OUTPUT,
+ snd_rawmidi_set_ops(rmidi, SNDRV_RAWMIDI_STREAM_OUTPUT,
[PATCH 5/6] [ALSA] portman2x4 - assignment in if
It is not general practice to assign some values inside if statement.
Signed-off-by: Sudip Mukherjee
---
sound/drivers/portman2x4.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/sound/drivers/portman2x4.c b/sound/drivers/portman2x4.c
index 985cf67..5fcde7d 100644
--- a/sound/drivers/portman2x4.c
+++ b/sound/drivers/portman2x4.c
@@ -743,7 +743,8 @@ static int snd_portman_probe(struct platform_device *pdev)
if (!enable[dev])
return -ENOENT;
- if ((err = snd_portman_probe_port(p)) < 0)
+ err = snd_portman_probe_port(p);
+ if (err < 0)
return err;
err = snd_card_new(>dev, index[dev], id[dev], THIS_MODULE,
@@ -770,7 +771,8 @@ static int snd_portman_probe(struct platform_device *pdev)
goto __err;
}
- if ((err = portman_create(card, pardev, )) < 0) {
+ err = portman_create(card, pardev, );
+ if (err < 0) {
snd_printd("Cannot create main component\n");
parport_unregister_device(pardev);
goto __err;
@@ -778,7 +780,8 @@ static int snd_portman_probe(struct platform_device *pdev)
card->private_data = pm;
card->private_free = snd_portman_card_private_free;
- if ((err = snd_portman_rawmidi_create(card)) < 0) {
+ err = snd_portman_rawmidi_create(card);
+ if (err < 0) {
snd_printd("Creating Rawmidi component failed\n");
goto __err;
}
@@ -792,13 +795,15 @@ static int snd_portman_probe(struct platform_device *pdev)
pm->pardev_claimed = 1;
/* init device */
- if ((err = portman_device_init(pm)) < 0)
+ err = portman_device_init(pm);
+ if (err < 0)
goto __err;
platform_set_drvdata(pdev, card);
/* At this point card will be usable */
- if ((err = snd_card_register(card)) < 0) {
+ err = snd_card_register(card);
+ if (err < 0) {
snd_printd("Cannot register card\n");
goto __err;
}
@@ -850,7 +855,8 @@ static int __init snd_portman_module_init(void)
{
int err;
- if ((err = platform_driver_register(_portman_driver)) < 0)
+ err = platform_driver_register(_portman_driver);
+ if (err < 0)
return err;
if (parport_register_driver(_parport_driver) != 0) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] PCI: designware: ensure ATU is enabled before IO/conf space accesses
Dear Bjorn,
On Wed, 6 Jan 2016 12:20:03 -0600 Bjorn Helgaas wrote:
> [+cc Jisheng]
>
> On Fri, Dec 18, 2015 at 02:38:55PM +0200, Stanimir Varbanov wrote:
> > There is no guarantees that enabling ATU will hit the hardware
> > immediately, and subsequent accesses to configuration / IO spaces
> > are reliable. So fixing this by read back PCIE_ATU_CR2 register
> > just after writing.
> >
> > Without such a fix the PCI device enumeration during kernel boot
> > is not reliable, and reading configuration space for particular
> > PCI device on the bus returns zero aka no device.
> >
> > Signed-off-by: Stanimir Varbanov
> > ---
> > drivers/pci/host/pcie-designware.c |7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c
> > index 02a7452bdf23..7880de63895d 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -154,6 +154,8 @@ static int dw_pcie_wr_own_conf(struct pcie_port *pp,
> > int where, int size,
> > static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
> > int type, u64 cpu_addr, u64 pci_addr, u32 size)
> > {
> > + u32 val;
> > +
> > dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | index,
> > PCIE_ATU_VIEWPORT);
> > dw_pcie_writel_rc(pp, lower_32_bits(cpu_addr), PCIE_ATU_LOWER_BASE);
> > @@ -164,6 +166,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port
> > *pp, int index,
> > dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
> > dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
> > dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
> > + /*
> > +* ensure that the ATU enable has been happaned before accessing
> > +* pci configuration/io spaces through dw_pcie_cfg_[read|write].
> > +*/
> > + dw_pcie_readl_rc(pp, PCIE_ATU_CR2, );
>
> This particular fix makes sense to me.
>
> But I have a larger question about how the ATU works. I see these
> definitions:
>
> #define PCIE_ATU_TYPE_MEM
> #define PCIE_ATU_TYPE_IO
> #define PCIE_ATU_TYPE_CFG0
> #define PCIE_ATU_TYPE_CFG1
>
> and these uses:
>
> - In dw_pcie_host_init(), set PCIE_ATU_TYPE_MEM for unit 1
> (but only if rd_other_conf is not overridden)
>
> - In dw_pcie_rd_other_conf() and dw_pcie_wr_other_conf(),
> set PCIE_ATU_TYPE_CFG0 before config access to own bus;
> set PCIE_ATU_TYPE_CFG1 before config access to other bus;
> set PCIE_ATU_TYPE_IO after completion
>
> I'm confused:
>
> 1) I assume PCIE_ATU_TYPE_MEM is for access to PCI memory space. Why
> is that initialization related to rd_other_conf? Shouldn't that be
> set up always? A comment here would be nice, to clarify that this is
> not related to the subsequent dw_pcie_wr_own_conf() calls.
Indeed, the comment is necessary. I forget the reason until read the code
carefully again. The reason here is
If the platform provides ->rd_other_conf, it means the platform
doesn't support ATU, it uses its own address translation component
rather than ATU, so we should ignore ATU programming for this
kind of platform.
I have sent out one patch to add this comment.
>
> 2) Why doesn't dw_pcie_host_init() use dw_pcie_rd_conf() instead of
> dw_pcie_rd_own_conf()? Using pci_read_config_dword() might be even
> better. Using the internal interfaces piecemeal like we do today is
> just an opportunity for doing it wrong.
IMHO, the reason is during host_init, the pci bus etc. are not initialized,
from another side, the code is really accessing its own conf registers.
>
> 3) The definitions and your comment about "accessing PCI
> configuration/io spaces" suggest that the ATU must be programmed
> differently for accesses to PCI config space vs. I/O space. If that's
Yes.
> the case, we'd need some kind of mutex to protect inl(), etc., during
> config accesses. For example, in this scenario:
>
> thread A thread B
> ---
> pci_read_config_dword()
> dw_pcie_prog_outbound_atu(PCIE_ATU_TYPE_CFG0)
>inl()
> dw_pcie_cfg_read()
> readl()
> dw_pcie_prog_outbound_atu(PCIE_ATU_TYPE_IO)
>inl()
>
> Do both inl() calls by thread B work correctly, even though the ATU
> seems to be programmed for CFG0 for the first but IO for the second?
>
Indeed, there's such race issue as you and RMK pointed out.
IMHO, we need support:
1. platforms which contain three or more iATUs, there's no need to mux
iATU usage: one ATU for IO, one for cfg and another for MEM. But how to
get the number of iATUs, DT? eg. "snps,atu_num = 3"
2. platforms which contain only two iATUs, add mechanism to protect
the cfg vs IO race. Could you please give suggestions to how to achieve
this goal?
Thanks,
Jisheng
--
To unsubscribe from this
Re: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM
Hi Marcel,
On 2016-01-05 08:39, Marcel Ziswiler wrote:
> From: Petr Štetiar
>
> Signed-off-by: Petr Štetiar
> Signed-off-by: Marcel Ziswiler
> ---
>
> Changes in v2:
> - clarify exact Apalis iMX6Q/D SoM type in cover letter
> - clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
> node
> - got rid of obsolete mmc aliases
> - working SGTL5000 audio/sound integration
> - working STMPE811 touch screen controller integration
> - integrated review feedback from Lucas
> - left and even added some more comments as I don't see why putting any
> explanatory comments in dts' should be such a bad thing to do
> - completely got rid of the memory node as that is something typically filled
> in by the boot loader e.g. U-Boot
> - without the regulators simple-bus it no longer boots
> - even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
> support for now and simplify file layout
> - replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300
> 3300>
> usdhc property and yes card detects are indeed active low (;-p)
> - integrated review feedback from Stefan
> - fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
> enabled)
> - fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
> - fixed SPDIF
>
> arch/arm/boot/dts/imx6qdl-apalis.dtsi | 1040
> +
> 1 file changed, 1040 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6qdl-apalis.dtsi
>
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> new file mode 100644
> index 000..6104e2e
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -0,0 +1,1040 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include
> +
> +/ {
> + model = "Toradex Apalis iMX6Q/D Module";
> + compatible = "toradex,apalis_imx6q", "fsl,imx6q";
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 500>;
> + status = "disabled";
> + };
> +
> + /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> + i2cddc: i2c@0 {
> + compatible = "i2c-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c_ddc>;
> + gpios = < 16 GPIO_ACTIVE_HIGH /* sda */
> + 30 GPIO_ACTIVE_HIGH /* scl */
> + >;
> + i2c-gpio,delay-us = <2>;/* ~100 kHz */
> + status = "okay";
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> +
> + reg_1p8v: 1p8v {
> + compatible = "regulator-fixed";
> + regulator-name = "1P8V";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +
> + reg_2p5v: 2p5v {
Re: [PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support
Hi, On Wednesday 06 January 2016 07:43 PM, Rob Herring wrote: > On Wed, Jan 06, 2016 at 04:19:53PM +0530, Kishon Vijay Abraham I wrote: >> Perform syscon configurations to get x2 mode to working in DRA74x and >> DRA72x. Also add a new compatible string to dfferentiate >> DRA72x and DRA74x, since b1c0 mask is different for both these platforms. >> >> Signed-off-by: Kishon Vijay Abraham I >> --- >> Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++- >> drivers/pci/host/pci-dra7xx.c| 81 >> +- >> 2 files changed, 86 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt >> b/Documentation/devicetree/bindings/pci/ti-pci.txt >> index 60e2516..0b10e84 100644 >> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt >> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt >> @@ -1,7 +1,9 @@ >> TI PCI Controllers >> >> PCIe Designware Controller >> - - compatible: Should be "ti,dra7-pcie"" >> + - compatible: "ti,dra7-pcie" is deprecated >> + Should be "ti,dra746-pcie" for DRA74x >> + Should be "ti,dra726-pcie" for DRA72x >> - reg : Two register ranges as listed in the reg-names property >> - reg-names : The first entry must be "ti-conf" for the TI specific >> registers >> The second entry must be "rc-dbics" for the designware pcie >> @@ -14,6 +16,10 @@ PCIe Designware Controller >> where is the instance number of the pcie from the HW spec. >> - interrupts : Two interrupt entries must be specified. The first one is >> for >> main interrupt line and the second for MSI interrupt line. >> + - syscon-lane-conf : phandle/offset pair. Phandle to the system control >> module and the >> + register offset to specify 1 lane or 2 lane. >> + - syscon-lane-sel : phandle/offset pair. Phandle to the system control >> module and the >> + register offset to specify lane selection. > > These should have a ti prefix. Okay. Will fix that and post a new version. Thanks Kishon > >> - #address-cells, >> #size-cells, >> #interrupt-cells, -- 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 PATCH v1 1/2] drm: rockchip: hdmi: add RK3229 HDMI support
Thanks for "Kbuild test robot" reminding, I forget to update
"mode_valid" function define in imx-hdmi side, would send new version out,
--
drivers/gpu/drm/imx/dw_hdmi-imx.c:181:2: warning: initialization from
incompatible pointer type
.mode_valid = imx6q_hdmi_mode_valid,
^
drivers/gpu/drm/imx/dw_hdmi-imx.c:181:2: warning: (near initialization for
'imx6q_hdmi_drv_data.mode_valid')
drivers/gpu/drm/imx/dw_hdmi-imx.c:189:2: warning: initialization from
incompatible pointer type
.mode_valid = imx6dl_hdmi_mode_valid,
^
drivers/gpu/drm/imx/dw_hdmi-imx.c:189:2: warning: (near initialization for
'imx6dl_hdmi_drv_data.mode_valid')
Sorry,
- Yakir
On 01/07/2016 12:37 PM, Yakir Yang wrote:
RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
the max output resolution is 4K.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/bridge/dw-hdmi.c| 33 ++-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 380 +---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 ++
include/drm/bridge/dw_hdmi.h| 5 +-
4 files changed, 516 insertions(+), 39 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 6fbec99..60b1dcf 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
{
unsigned res_idx;
u8 val, msec;
+ int ret;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
+ int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
if (prep)
return -EINVAL;
@@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
return -EINVAL;
}
+ if (hdmi->plat_data->extphy_config) {
+ /* gen2 tx power off */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+ ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
+mpixelclock);
+ /* gen2 tx power on */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+ dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+ return ret;
+ }
+
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- mpll_config->mpixelclock)
+ if (mpixelclock <= mpll_config->mpixelclock)
break;
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- curr_ctrl->mpixelclock)
+ if (mpixelclock <= curr_ctrl->mpixelclock)
break;
for (; phy_config->mpixelclock != ~0UL; phy_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- phy_config->mpixelclock)
+ if (mpixelclock <= phy_config->mpixelclock)
break;
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
phy_config->mpixelclock == ~0UL) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
- hdmi->hdmi_data.video_mode.mpixelclock);
+ mpixelclock);
return -EINVAL;
}
@@ -1476,14 +1489,16 @@ dw_hdmi_connector_mode_valid(struct drm_connector *connector,
{
struct dw_hdmi *hdmi = container_of(connector,
struct dw_hdmi, connector);
+ struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
enum drm_mode_status mode_status = MODE_OK;
/* We don't support double-clocked modes */
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_BAD;
- if (hdmi->plat_data->mode_valid)
- mode_status = hdmi->plat_data->mode_valid(connector, mode);
+ if (plat_data->mode_valid)
+ mode_status = plat_data->mode_valid(plat_data, mode);
+
return mode_status;
}
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index c65ce8c..424d548 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -7,6 +7,7 @@
* (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -21,18 +22,135 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
[PATCH] PCI: designware: comment the condition of programming ATU in host init
Some platforms don't support ATU, e.g pci-keystone.c, these platforms use their own address translation component rather than ATU, and they provide the rd_other_conf and wr_other_conf to programming the translation component then do the required access, so we ignore the ATU programming for these platforms. Add the comment to explain the reason. As Bjorn pointed out, "these definitions: #define PCIE_ATU_TYPE_MEM #define PCIE_ATU_TYPE_IO #define PCIE_ATU_TYPE_CFG0 #define PCIE_ATU_TYPE_CFG1 and these uses: - In dw_pcie_host_init(), set PCIE_ATU_TYPE_MEM for unit 1 (but only if rd_other_conf is not overridden) - In dw_pcie_rd_other_conf() and dw_pcie_wr_other_conf(), set PCIE_ATU_TYPE_CFG0 before config access to own bus; set PCIE_ATU_TYPE_CFG1 before config access to other bus; set PCIE_ATU_TYPE_IO after completion Why is that initialization related to rd_other_conf? Shouldn't that be set up always? A comment here would be nice..." To be honest, I can't answer this question immediately until I read the code carefully again. So indeed, the comment is really necessary. Signed-off-by: Jisheng Zhang --- drivers/pci/host/pcie-designware.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 02a7452..b795b20 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -517,6 +517,12 @@ int dw_pcie_host_init(struct pcie_port *pp) if (pp->ops->host_init) pp->ops->host_init(pp); + /* +* If the platform provides ->rd_other_conf, it means the platform +* doesn't support ATU, it uses its own address translation component +* rather than ATU, so we should ignore ATU programming for this +* kind of platform. +*/ if (!pp->ops->rd_other_conf) dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1, PCIE_ATU_TYPE_MEM, pp->mem_base, -- 2.7.0.rc3 -- 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] MAINTAINERS: update for Freescale DCU DRM driver
Promote myself as new maintainer of the Freescale DCU DRM driver. Signed-off-by: Stefan Agner --- This has been previously discussed privately. The original driver author and maintainer Jianwei does not work for Freescale anymore and can not carve out spare time to maintain the driver. As I started to make use of the driver on the Freescale Vybrid SoC and already posted several fixes and improvements, I am willing to maintain the driver. Thanks Jianwei for your work on that driver! Dave, I hope you are OK with that? I plan to send a pull request with the patches which have been on the ml lately, specifically the "Fix no fb check bug" and my fixes and enhancements patchset, along with this maintainer change, does that sound reasonable? There is one more pending patchset for this drivers, the TCON and Vybrid support patchset, but this is probably not ready yet. I also plan to post another patchset which enables multiple overlay planes and a cursor plane. -- Stefan MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e9caa4b..3f0aea3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3678,7 +3678,7 @@ F:include/drm/exynos* F: include/uapi/drm/exynos* DRM DRIVERS FOR FREESCALE DCU -M: Jianwei Wang +M: Stefan Agner M: Alison Wang L: dri-de...@lists.freedesktop.org S: Supported -- 2.6.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 v2 00/12] mtd: nand_bbt: introduce independent nand BBT
Hi Boris,
On Wed, Jan 6, 2016 at 10:29 PM, Boris Brezillon
wrote:
> On Wed, 30 Dec 2015 09:31:06 +0100
> Boris Brezillon wrote:
>
>> Hi Peter,
>>
>> On Wed, 30 Dec 2015 15:18:39 +0800
>> 潘栋 wrote:
>>
>> > Hi Boris and Ezequiel,
>> >
>> > 2015-12-29 23:11 GMT+08:00 Boris Brezillon
>> > :
>> > > On Tue, 29 Dec 2015 12:07:50 -0300
>> > > Ezequiel Garcia wrote:
>> > >
>> > >> On 29 December 2015 at 06:35, Boris Brezillon
>> > >> wrote:
>> > >> > Hi,
>> > >> >
>> > >> > On Mon, 28 Dec 2015 17:42:50 -0300
>> > >> > Ezequiel Garcia wrote:
>> > >> >
>> > >> >> This is looking a lot better, thanks for the good work!
>> > >> >>
>> > >> >> On 15 December 2015 at 02:59, Peter Pan
>> > >> >> wrote:
>> > >> >> > Currently nand_bbt.c is tied with struct nand_chip, and it makes
>> > >> >> > other
>> > >> >> > NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
>> > >> >> > onenand has own bbt(onenand_bbt.c).
>> > >> >> >
>> > >> >> > Separate struct nand_chip from BBT code can make current BBT
>> > >> >> > shareable.
>> > >> >> > We create struct nand_bbt to take place of nand_chip in nand_bbt.c.
>> > >> >> > Struct nand_bbt contains all the information BBT needed from
>> > >> >> > outside and
>> > >> >> > it should be embedded into NAND family chip struct (such as struct
>> > >> >> > nand_chip).
>> > >> >> > NAND family driver should allocate, initialize and free struct
>> > >> >> > nand_bbt.
>> > >> >> >
>> > >> >> > Below is mtd folder structure we want:
>> > >> >> > mtd
>> > >> >> > ├── Kconfig
>> > >> >> > ├── Makefile
>> > >> >> > ├── ...
>> > >> >> > ├── nand_bbt.c
>> > >> >>
>> > >> >> Hm.. I'm not sure about having nand_bbt.c in drivers/mtd.
>> > >> >> What's wrong with drivers/mtd/nand ?
>> > >> >
>> > >> > I haven't reviewed the series yet, but I agree. If the BBT code is
>> > >> > only
>> > >> > meant to be used on NAND based devices, it should probably stay in
>> > >> > drivers/mtd/nand.
>> > >> >
>> > >> >>
>> > >> >> In fact, I was thinking we could go further and clean up the
>> > >> >> directories a bit
>> > >> >> by separating core code, from controllers code, from SPI NAND code:
>> > >> >>
>> > >> >> drivers/mtd/nand/
>> > >> >> drivers/mtd/nand/controllers
>> > >> >> drivers/mtd/nand/spi
>> > >> >>
>> > >> >> Makes any sense?
>> > >> >
>> > >> > Actually I had the secret plan of moving all (raw) NAND controller
>> > >> > drivers into the drivers/mtd/nand/controllers directory, though this
>> > >> > was for a different reason: I'd like to create another directory for
>> > >> > manufacturer specific code in order to support some advanced features
>> > >> > on NANDs that do not implement (or only partially implement) the ONFI
>> > >> > standard.
>> > >> >
>> > >> > The separation you're talking about here is more related to the
>> > >> > interface used to communicate with the NAND chip.
>> > >> >
>> > >> > How about using the following hierarchy?
>> > >> >
>> > >> > drivers/mtd/nand/
>> > >> > drivers/mtd/nand/interfaces/raw/
>> > >> > drivers/mtd/nand/interfaces/raw/controllers/
>> > >> > drivers/mtd/nand/interfaces/spi/
>> > >> > drivers/mtd/nand/interfaces/onenand/
>> > >> > drivers/mtd/nand/chips/
>> > >> >
>> > >> > What do you think?
>> > >> >
>> > >>
>> > >> I believe we are bikeshedding here, but what the heck.
>> > >>
>> > >> That seems too involved. A simpler hierarchy could be clear enough,
>> > >> and seems to follow what other subsystems do:
>> > >>
>> > >> drivers/mtd/nand/
>> > >> drivers/mtd/nand/raw/
>> > >
>> > > And probably some common logic in there too.
>> > >
>> > >> drivers/mtd/nand/spi/
>> > >> drivers/mtd/nand/onenand/
>> > >> drivers/mtd/nand/chips/
>> > >>
>> > >
>> > > I'm fine with this one too ;-).
>> >
>> > I'm fine with this structure too. drivers/mtd/nand folder becomes top
>> > folder for
>> > all NAND based devices. Because (raw)NAND, SPI-NAND and ONENAND have
>> > different command set and feature, each has its own core - nand_base.c
>> > spi-nand-base.c
>> > and onenand_base.c. So maybe it'll take a lot effort to abstract a
>> > all-nand-core-code
>> > (of course BBT should be one of them). What's your opinion?
>>
>> Absolutely, that was the idea: move everything into the
>> drivers/mtd/nand directory (with the structure described above), keep
>> some specific logic for each interface type, and see if we can factor
>> out some common code (I noticed that SPI NAND devices have a parameter
>> page which looks similar to the one exposed by ONFI compliant devices,
>> except this parameter page is retrieved using a different command, the
>> same goes for the ->{set,get}_features() functions).
>> But let's focus on the nand_bbt code for now.
>>
>> >
>> > Also, please review the BBT patch if you have time. I think it's
>> > helpful on the new NAND code
>> > hierarchy.
>>
>> I'll try to review it this week.
>
> I'm a bit late, but I think I've reviewed most of it now.
I already go through your
Re: [PATCH v2 1/2] drm: bridge: sil902x
On 01/06/2016 05:55 PM, Boris Brezillon wrote: Add basic support for the sil902x RGB -> HDMI bridge. This driver does not support audio output yet. Signed-off-by: Boris Brezillon --- Hello, This patch is only adding basic support for the sil9022 chip. As stated in the commit log, there's no audio support, but the driver also hardcodes a lot of things (like the RGB input format to use). There are two reasons for this: 1/ the DRM framework does not allow for advanced link description between an encoder and a bridge (that's for the RGB format limitation). Any idea how this should be described? The adv7511 driver uses a DT param "input_colorspace" to chose between RGB or YUV. I don't think DT is the best idea, but I don't know of a better way either. The connector's display_info.color_formats field gives us some info about the color formats supported by the monitor, but I guess that isn't sufficient data to know what format the encoder is pushing out. We get around this problem in case the case of DSI encoders by using the mipi_dsi_device api, where a DSI based bridge or panel can pass color format/lane info to the DSI host (i.e, encoder) by using mipi_dsi_attach(). 2/ I don't have the datasheet of this HDMI encoder, and all logic has been extracted from those two drivers [1][2], which means I may miss some important things in my encoder setup. Another thing I find weird in the drm_bridge interface is the fact that we have a ->attach() method, but no ->detach(), which can be a problem if we allow drm bridges and KMS drivers to be compiled as modules. Any reason for that? I guess the drm_bridge_add/remove ops make can ensure that the bridge driver itself can be compiled as a module. However, you're right that we would need a bridge detach op that the kms driver should call before it is removed (to unregister the connector we created). Someone would still need to make sure about the order in which the modules are removed. If the bridge driver is removed first, then it would really mess up the kms driver using the bridge. Would the kms driver using this chip really have an encoder? Since the chip takes in RGB input, I'm assuming that the encoder in the kms driver would more or less be nop funcs, giving their way to bridge ops. In such cases, I think the bridge still doesn't fit in so well. The best fit here is how the current tda998x driver is modeled. It adds itself as a component that creates both an encoder and connector, which the kms driver can use directly. This approach, of course, prevents us using tda998x in kms drivers that don't accept any encoders that it didn't create itself. Thanks, Archit That's all for the questions part :-). Best Regards, Boris Changes in v2: - fix errors reported by kbuild test robot --- drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/sil902x.c | 491 +++ 3 files changed, 500 insertions(+) create mode 100644 drivers/gpu/drm/bridge/sil902x.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 27e2022..9701fd2 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -40,4 +40,12 @@ config DRM_PARADE_PS8622 ---help--- Parade eDP-LVDS bridge chip driver. +config DRM_SIL902X + tristate "Silicon Image sil902x RGB/HDMI bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + Silicon Image sil902x bridge chip driver. + endmenu diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index f13c33d..a689aad 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o +obj-$(CONFIG_DRM_SIL902X) += sil902x.o diff --git a/drivers/gpu/drm/bridge/sil902x.c b/drivers/gpu/drm/bridge/sil902x.c new file mode 100644 index 000..2657031 --- /dev/null +++ b/drivers/gpu/drm/bridge/sil902x.c @@ -0,0 +1,491 @@ +/* + * Copyright (C) 2014 Atmel + * Bo Shen + * + * Authors: Bo Shen + * Boris Brezillon + * Wu, Songjun + * + * + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for
linux-next: manual merge of the target-updates tree with the rdma tree
Hi Nicholas,
Today's linux-next merge of the target-updates tree got conflicts in:
drivers/infiniband/ulp/iser/iscsi_iser.h
drivers/infiniband/ulp/iser/iser_initiator.c
drivers/infiniband/ulp/iser/iser_memory.c
drivers/infiniband/ulp/iser/iser_verbs.c
drivers/infiniband/ulp/isert/ib_isert.c
between commits:
4a061b287b1e ("IB/ulps: Avoid calling ib_query_device")
cfeb91b375ad ("IB/iser: Convert to CQ abstraction")
2392a4cdcb8d ("IB/iser: constify iser_reg_ops structure")
422bd0acb062 ("IB/isert: Support the remote invalidation exception")
59caaed7a72a ("IB/iser: Support the remote invalidation exception")
from the rdma tree and commit:
ddca7d44ccd2 ("iser: Have initiator and target to share protocol structures
and definitions")
6d2cb3ad4bc2 ("iser-target: Support the remote invalidation exception")
c37c810bae45 ("IB/iser: Increment the rkey when registering and not when
invalidating")
9a4a71456262 ("IB/iser: Support the remote invalidation exception")
from the target-updates tree.
I fixed it up (hopefully - mainly taking one of the other side (usually
the rdma tree version, so please check the result when I release it)
and can carry the fix as necessary (no action is required).
Seom of these patches are very similar ...
--
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: Nokia N900: u-SD card in v4.2+
Hi, On Thursday 07 January 2016 02:16 AM, Pavel Machek wrote: > Hi! > > In v4.1, both internal MMC and u-SD cards work ok. > > In v4.2, only the internal MMC is detected. In v4.3, not even internal > MMC works. In v4.4, only the internal MMC is detected. > > Does it work for you? Any patches? I don't have Nokia N900 to check this, but can you share your config and kernel logs? Check if CONFIG_REGULATOR_PBIAS is present in your config. CONFIG_REGULATOR_PBIAS is now mandatory for all omap3+ SoCs to work. Thanks Kishon > > (I do have hack in the dts to disable back cover detection...) > > Pavel > -- 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/
[RFC 00/15] Add 64 bit timestamp support
This is an update to Arnd Bergmann's RFC patch series:
https://lkml.org/lkml/2014/5/30/669 .
The syscalls and runtime libraries will be handled in separate patch series.
The filling of max and min timestamps for individual filesystems can be
leveraged from the patch series:
https://lkml.org/lkml/2015/11/20/413
1. Objective:
To transition all file system code to use 64 bit time.
This translates to using timespec64 across the fs code for any
timestamp representation.
2. Problem Description:
struct timespec cannot represent times after year 2038 on 32 bit
systems.
The alternative to timespec in the kernel world is timespec64 to get
around the above problem. This will be the UAPI exposed interface.
3. Design objectives:
The goal of this approach was to come up with small manageable patches
to address the above problem.
Preferably, a single patch per filesystem that can be merged independently.
Also, a more generic approach that all the individual filesystems could follow
was preferred.
4. Solution:
The solution incorporated in the patch series involves stages defined below:
4.1. CONFIG_FS_USES_64BIT_TIME
This new config is defined to #ifdef code that is required to support 64 bit
times.
4.2. struct inode times:
The struct inode saves {a,c,m}timestamps as struct timespec.
This leads to 2 problems:
a. The size of the structure depends on whether the machine is 32/ 64
bit.
b. y2038 problem described above.
struct timespec64 also has the same problem as in (a) above.
Choosing scalar types to store these timestamps(time64 and s32) solves both the
above problems.
Adding accessors to access these timestamps would hide the internal data type
so that this can be changed according to config in (4.1).
4.3. struct inode_timespec:
Use inode_timespec for all other timestamp representation throughout VFS and
individual filesystems.
inode_timespec is aliased to timespec or timespec64 based on config defined
in (4.1).
Using timespec64 in this stage would require ifdef-ing the code, which is
spread throughout the code.
4.4. Enable config in (4.1).
4.5. Convert inode_timespec to timespec64:
Drop all references to inode_timespec in (4.3).
Replace it with timespec64.
5. Alternate Solution:
Steps involved are:
5.1. Change VFS code to handle both timespec64 and timespec:
There are a few API's in the VFS that take timestamps as arguments:
generic_update_time(), inode->i_op->update_time(), lease_get_mtime(),
fstack_copy_attr_all(), setattr_copy(), generic_fillattr.
The attr and kstat properties could have accessors like inode.
But, the other functions will have to maintain copies or be updated
simultaenously along with other affecting filesystems.
5.2.struct timespec64:
Change individual fs to use timespec64.
5.3. struct inode times:
The struct inode saves {a,c,m}timestamps as struct timespec.
This leads to 2 problems:
a. The size of the structure depends on whether the machine is 32/ 64
bit.
b. y2038 problem described above.
struct timespec64 also has the same problem as in (a) above.
Choosing scalar types to store these timestamps(time64 and s32) solves both the
above problems.
Change individual filesystems to use macros to access inode times.
Inode macros can assume conversion from timespec64 always.
5.4. VFS:
Change vfs code also as above in (1) and (2).
5.5. Drop timespec
This involves dropping support for any api/ struct changes to make vfs use only
timespec64 for timestamps.
6. Rationale:
The advantage of the method described in (5) is that we do not have
inode_timespec aliases only to be dropped later.
But, the method suffers from disadvantages:
a. As mentioned in (5.1), our process is affected as all the filesystems
using each api must be changed simultaenously or VFS should have a copy.
b. While individual filesystems are being changed, VFS will have to have
2 copies of a few apis. This will mean that at this time, any new code
being added might use either. This might lead to confusion.
Misc:
7. Range check:
Patches include range check and clamping of timestamps.
This topic did not have a conclusion on the previous RFC.
7.1. Rationale
The method incorporated in the patch series is based on following principles:
a. Linux does not impose any fixed format for on-disk inodes.
LKML discussion is still ongoing concerning the best handling of file
systems
used or updated after their expiration date.
b. Linux cannot surmise the side effects to a file system because of the
wrong timestamps as each fs saves timestamps differently.
c. Individual filesystems must be able to say what to do when timestamps
are clamped.
7.2. Solution
Based on the above principles, the solution is described below:
7.2.1. There are 2 instances that the solution handles differently:
a. While mounting a
[RFC 02/15] vfs: Change all structures to support 64 bit time
The current representation of inode times in struct inode, struct iattr,
and struct kstat use struct timespec. timespec is not y2038 safe.
Use scalar data types (seconds and nanoseconds stored separately) to
represent timestamps in struct inode in order to maintain same size for
times across 32 bit and 64 bit architectures.
In addition, lay them out such that they are packed on a naturally
aligned boundary on 64 bit arch as 4 bytes are used to store nsec.
This makes each tuple(sec, nscec) use 12 bytes instead of 16 bytes.
This will help save RAM space as inode structure is cached in memory.
The other structures are transient and do not benefit from these
changes.
Add accessors for inode timestamps.
These provide a way to access the time field members.
Accessors abstract the timestamp representation so that any logic
to convert between the struct inode timestamps and other interfaces
can be placed here.
The plan is to globally change all references to these types through
these accessors only. So when the actual internal representation
changes, it will be transparent to the outside world.
This can be extended to add code to validate the inode times that
are being set.
Macros are chosen as accessors rather than functions because we can
condense 3 {a,c,m} time functions into a single macro. After we agree
on an approach, the implementation could be changed to use static
inline functions if it suits more.
Add inode_timespec aliases to help convert kstat and iattr times to use
64 bit times. These hide the internal data type.
Use uapi exposed data types here to keep minimal timstamp data type
conversions in API's interfacing with vfs.
After the CONFIG_FS_USES_64BIT_TIME is enabled, all inode_timespec
aliases will be removed and timespec64 data types and API's will
be used directly.
Signed-off-by: Deepa Dinamani
---
include/linux/fs.h | 55 +++---
include/linux/stat.h | 6 +++---
include/linux/time64.h | 21 +++
3 files changed, 72 insertions(+), 10 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 12ba937..b9f3cee 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -245,13 +245,13 @@ typedef void (dax_iodone_t)(struct buffer_head *bh_map,
int uptodate);
*/
struct iattr {
unsigned intia_valid;
- umode_t ia_mode;
- kuid_t ia_uid;
- kgid_t ia_gid;
- loff_t ia_size;
- struct timespec ia_atime;
- struct timespec ia_mtime;
- struct timespec ia_ctime;
+ umode_t ia_mode;
+ kuid_t ia_uid;
+ kgid_t ia_gid;
+ loff_t ia_size;
+ struct inode_timespec ia_atime;
+ struct inode_timespec ia_mtime;
+ struct inode_timespec ia_ctime;
/*
* Not an attribute, but an auxiliary info for filesystems wanting to
@@ -616,9 +616,18 @@ struct inode {
};
dev_t i_rdev;
loff_t i_size;
+#ifdef CONFIG_FS_USES_64BIT_TIME
+ time64_ti_atime_sec;
+ time64_ti_mtime_sec;
+ time64_ti_ctime_sec;
+ s32 i_atime_nsec;
+ s32 i_mtime_nsec;
+ s32 i_ctime_nsec;
+#else
struct timespec i_atime;
struct timespec i_mtime;
struct timespec i_ctime;
+#endif
spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_size */
unsigned short i_bytes;
unsigned inti_blkbits;
@@ -679,6 +688,38 @@ struct inode {
void*i_private; /* fs or device private pointer */
};
+#ifdef CONFIG_FS_USES_64BIT_TIME
+
+#define VFS_INODE_SET_XTIME(xtime, inode, ts64)\
+ do {\
+ struct inode_timespec __ts = (ts64);\
+ (inode)->xtime##_sec = __ts.tv_sec; \
+ (inode)->xtime##_nsec = __ts.tv_nsec; \
+ } while (0)
+
+#define VFS_INODE_GET_XTIME(xtime, inode) \
+ (struct timespec64){.tv_sec = (inode)->xtime##_sec, \
+ .tv_nsec = (inode)->xtime##_nsec}
+
+#else
+
+#define VFS_INODE_SET_XTIME(xtime, inode, ts) \
+ ((inode)->xtime = (ts))
+
+#define VFS_INODE_GET_XTIME(xtime, inode) \
+ ((inode)->xtime)
+
+#endif
+
+#define VFS_INODE_SWAP_XTIME(xtime, inode1, inode2)\
+ do {\
+ struct inode_timespec __ts =\
+ VFS_INODE_GET_XTIME(xtime, inode1); \
+ VFS_INODE_SET_XTIME(xtime, inode1, \
+
[RFC 07/15] fs: ext4: convert to use 64 bit time
struct timespec is not y2038 safe.
The ext4 uses time_extra fields to extend {a,c,m,cr} times until
2446.
Use struct inode_timespec to replace timespec.
inode_timespec will eventually be replaced by struct timespec64
when CONFIG_FS_USES_64BIT_TIME is enabled.
Signed-off-by: Deepa Dinamani
---
fs/ext4/acl.c | 3 ++-
fs/ext4/ext4.h| 44
fs/ext4/extents.c | 25 +++--
fs/ext4/ialloc.c | 9 +++--
fs/ext4/inline.c | 10 --
fs/ext4/inode.c | 16
fs/ext4/ioctl.c | 16 ++--
fs/ext4/namei.c | 40
fs/ext4/super.c | 6 +-
fs/ext4/xattr.c | 2 +-
10 files changed, 116 insertions(+), 55 deletions(-)
diff --git a/fs/ext4/acl.c b/fs/ext4/acl.c
index 69b1e73..e8073d5 100644
--- a/fs/ext4/acl.c
+++ b/fs/ext4/acl.c
@@ -200,7 +200,8 @@ __ext4_set_acl(handle_t *handle, struct inode *inode, int
type,
if (error < 0)
return error;
else {
- inode->i_ctime = ext4_current_time(inode);
+ VFS_INODE_SET_XTIME(i_ctime, inode,
+ ext4_current_time(inode));
ext4_mark_inode_dirty(handle, inode);
if (error == 0)
acl = NULL;
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index c569430..4bb2604 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -754,14 +754,15 @@ struct move_extent {
* affected filesystem before 2242.
*/
-static inline __le32 ext4_encode_extra_time(struct timespec *time)
+static inline __le32 ext4_encode_extra_time(struct inode_timespec *time)
{
u32 extra = sizeof(time->tv_sec) > 4 ?
((time->tv_sec - (s32)time->tv_sec) >> 32) & EXT4_EPOCH_MASK :
0;
return cpu_to_le32(extra | (time->tv_nsec << EXT4_EPOCH_BITS));
}
-static inline void ext4_decode_extra_time(struct timespec *time, __le32 extra)
+static inline void ext4_decode_extra_time(struct inode_timespec *time,
+ __le32 extra)
{
if (unlikely(sizeof(time->tv_sec) > 4 &&
(extra & cpu_to_le32(EXT4_EPOCH_MASK {
@@ -784,12 +785,13 @@ static inline void ext4_decode_extra_time(struct timespec
*time, __le32 extra)
time->tv_nsec = (le32_to_cpu(extra) & EXT4_NSEC_MASK) >>
EXT4_EPOCH_BITS;
}
-#define EXT4_INODE_SET_XTIME(xtime, inode, raw_inode) \
-do { \
- (raw_inode)->xtime = cpu_to_le32((inode)->xtime.tv_sec); \
- if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra)) \
- (raw_inode)->xtime ## _extra = \
- ext4_encode_extra_time(&(inode)->xtime); \
+#define EXT4_INODE_SET_XTIME(xtime, inode, raw_inode)
\
+do {
\
+ struct inode_timespec __ts = VFS_INODE_GET_XTIME(xtime, inode);
\
+ (raw_inode)->xtime = cpu_to_le32(__ts.tv_sec);
\
+ if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra))
\
+ (raw_inode)->xtime ## _extra =
\
+ ext4_encode_extra_time(&__ts);
\
} while (0)
#define EXT4_EINODE_SET_XTIME(xtime, einode, raw_inode)
\
@@ -801,14 +803,16 @@ do {
\
ext4_encode_extra_time(&(einode)->xtime); \
} while (0)
-#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode) \
-do { \
- (inode)->xtime.tv_sec = (signed)le32_to_cpu((raw_inode)->xtime); \
- if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra)) \
- ext4_decode_extra_time(&(inode)->xtime,\
- raw_inode->xtime ## _extra);\
- else \
- (inode)->xtime.tv_nsec = 0;\
+#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)
\
+do {
\
+ struct inode_timespec __ts = VFS_INODE_GET_XTIME(xtime, inode);
\
+ __ts.tv_sec = (signed)le32_to_cpu((raw_inode)->xtime);
\
+ if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra))
\
+
[RFC 09/15] fs: cifs: replace inode_timespec with timespec64
Substitute inode_timespec aliases with timespec64.
Since CONFIG_FS_USES_64BIT_TIME is enabled, internally
all inode_timespec references are using timespec64
already.
Signed-off-by: Deepa Dinamani
---
fs/cifs/cache.c | 4 ++--
fs/cifs/cifsglob.h | 6 +++---
fs/cifs/cifsproto.h | 6 +++---
fs/cifs/cifssmb.c | 4 ++--
fs/cifs/file.c | 2 +-
fs/cifs/inode.c | 12 ++--
fs/cifs/netmisc.c | 10 +-
7 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/fs/cifs/cache.c b/fs/cifs/cache.c
index 8d27e69b..61c21bf 100644
--- a/fs/cifs/cache.c
+++ b/fs/cifs/cache.c
@@ -221,8 +221,8 @@ const struct fscache_cookie_def
cifs_fscache_super_index_def = {
* Auxiliary data attached to CIFS inode within the cache
*/
struct cifs_fscache_inode_auxdata {
- struct inode_timespec last_write_time;
- struct inode_timespec last_change_time;
+ struct timespec64 last_write_time;
+ struct timespec64 last_change_time;
u64 eof;
};
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index c95dce7..7dfb0e2 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -1393,9 +1393,9 @@ struct cifs_fattr {
dev_t cf_rdev;
unsigned intcf_nlink;
unsigned intcf_dtype;
- struct inode_timespec cf_atime;
- struct inode_timespec cf_mtime;
- struct inode_timespec cf_ctime;
+ struct timespec64 cf_atime;
+ struct timespec64 cf_mtime;
+ struct timespec64 cf_ctime;
};
static inline void free_dfs_info_param(struct dfs_info3_param *param)
diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index 9979c74..663b8a4 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -126,10 +126,10 @@ extern enum securityEnum select_sectype(struct
TCP_Server_Info *server,
enum securityEnum requested);
extern int CIFS_SessSetup(const unsigned int xid, struct cifs_ses *ses,
const struct nls_table *nls_cp);
-extern struct inode_timespec
+extern struct timespec64
cifs_NTtimeToUnix(__le64 utc_nanoseconds_since_1601);
-extern u64 cifs_UnixTimeToNT(struct inode_timespec);
-extern struct inode_timespec cnvrtDosUnixTm(__le16 le_date, __le16 le_time,
+extern u64 cifs_UnixTimeToNT(struct timespec64);
+extern struct timespec64 cnvrtDosUnixTm(__le16 le_date, __le16 le_time,
int offset);
extern void cifs_set_oplock_level(struct cifsInodeInfo *cinode, __u32 oplock);
extern int cifs_get_writer(struct cifsInodeInfo *cinode);
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index a813bcd..465e089 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -478,7 +478,7 @@ decode_lanman_negprot_rsp(struct TCP_Server_Info *server,
NEGOTIATE_RSP *pSMBr)
* this requirement.
*/
int val, seconds, remain, result;
- struct inode_timespec ts, utc;
+ struct timespec64 ts, utc;
utc = FS_TIME;
ts = cnvrtDosUnixTm(rsp->SrvTime.Date,
@@ -4004,7 +4004,7 @@ QInfRetry:
if (rc) {
cifs_dbg(FYI, "Send error in QueryInfo = %d\n", rc);
} else if (data) {
- struct inode_timespec ts;
+ struct timespec64 ts;
__u32 time = le32_to_cpu(pSMBr->last_write_time);
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 2d226cf..656e799 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1839,7 +1839,7 @@ static int cifs_partialpagewrite(struct page *page,
unsigned from, unsigned to)
int bytes_written = 0;
struct inode *inode;
struct cifsFileInfo *open_file;
- struct inode_timespec now;
+ struct timespec64 now;
if (!mapping || !mapping->host)
return -EFAULT;
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index bb91bf7..c65d7e3 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -92,7 +92,7 @@ static void
cifs_revalidate_cache(struct inode *inode, struct cifs_fattr *fattr)
{
struct cifsInodeInfo *cifs_i = CIFS_I(inode);
- struct inode_timespec mtime;
+ struct timespec64 mtime;
cifs_dbg(FYI, "%s: revalidating inode %llu\n",
__func__, cifs_i->uniqueid);
@@ -112,7 +112,7 @@ cifs_revalidate_cache(struct inode *inode, struct
cifs_fattr *fattr)
/* revalidate if mtime or size have changed */
mtime = VFS_INODE_GET_XTIME(i_mtime, inode);
- if (inode_timespec_equal(, >cf_mtime)
+ if (timespec64_equal(, >cf_mtime)
&& cifs_i->server_eof == fattr->cf_eof) {
cifs_dbg(FYI, "%s: inode %llu is unchanged\n",
__func__, cifs_i->uniqueid);
@@ -320,7 +320,7 @@ static void
cifs_create_dfs_fattr(struct cifs_fattr *fattr, struct super_block *sb)
{
struct cifs_sb_info *cifs_sb = CIFS_SB(sb);
- struct
[RFC 08/15] fs: Enable 64 bit time
64 bit time support is in place for all filesystems. Enable CONFIG_USES_64BIT_TIME to start using 64 bit time everywhere. Signed-off-by: Deepa Dinamani --- fs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/Kconfig b/fs/Kconfig index a11934b..bfeefce 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -11,7 +11,7 @@ config DCACHE_WORD_ACCESS #use 64 bit timestamps config FS_USES_64BIT_TIME bool - default n + default y help Temporary configuration to switch over all file systems to use 64 bit time. -- 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/
[RFC 11/15] fs: ext4: replace inode_timespec with timespec64
Substitute inode_timespec aliases with timespec64.
Since CONFIG_FS_USES_64BIT_TIME is enabled, internally
all inode_timespec references are using timespec64
already.
Signed-off-by: Deepa Dinamani
---
fs/ext4/ext4.h| 14 +++---
fs/ext4/extents.c | 6 +++---
fs/ext4/ialloc.c | 2 +-
fs/ext4/inline.c | 4 ++--
fs/ext4/inode.c | 6 +++---
fs/ext4/ioctl.c | 2 +-
fs/ext4/namei.c | 10 +-
fs/ext4/super.c | 2 +-
8 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 4bb2604..2d4bef0 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -754,14 +754,14 @@ struct move_extent {
* affected filesystem before 2242.
*/
-static inline __le32 ext4_encode_extra_time(struct inode_timespec *time)
+static inline __le32 ext4_encode_extra_time(struct timespec64 *time)
{
u32 extra = sizeof(time->tv_sec) > 4 ?
((time->tv_sec - (s32)time->tv_sec) >> 32) & EXT4_EPOCH_MASK :
0;
return cpu_to_le32(extra | (time->tv_nsec << EXT4_EPOCH_BITS));
}
-static inline void ext4_decode_extra_time(struct inode_timespec *time,
+static inline void ext4_decode_extra_time(struct timespec64 *time,
__le32 extra)
{
if (unlikely(sizeof(time->tv_sec) > 4 &&
@@ -787,7 +787,7 @@ static inline void ext4_decode_extra_time(struct
inode_timespec *time,
#define EXT4_INODE_SET_XTIME(xtime, inode, raw_inode)
\
do {
\
- struct inode_timespec __ts = VFS_INODE_GET_XTIME(xtime, inode);
\
+ struct timespec64 __ts = VFS_INODE_GET_XTIME(xtime, inode);
\
(raw_inode)->xtime = cpu_to_le32(__ts.tv_sec);
\
if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra))
\
(raw_inode)->xtime ## _extra =
\
@@ -805,7 +805,7 @@ do {
\
#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)
\
do {
\
- struct inode_timespec __ts = VFS_INODE_GET_XTIME(xtime, inode);
\
+ struct timespec64 __ts = VFS_INODE_GET_XTIME(xtime, inode);
\
__ts.tv_sec = (signed)le32_to_cpu((raw_inode)->xtime);
\
if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra))
\
ext4_decode_extra_time(&__ts,
\
@@ -935,9 +935,9 @@ struct ext4_inode_info {
/*
* File creation time. Its function is same as that of
-* struct inode_timespec i_{a,c,m}time in the generic inode.
+* struct timespec64 i_{a,c,m}time in the generic inode.
*/
- struct inode_timespec i_crtime;
+ struct timespec64 i_crtime;
/* mballoc */
struct list_head i_prealloc_list;
@@ -1445,7 +1445,7 @@ static inline struct ext4_inode_info *EXT4_I(struct inode
*inode)
return container_of(inode, struct ext4_inode_info, vfs_inode);
}
-static inline struct inode_timespec ext4_current_time(struct inode *inode)
+static inline struct timespec64 ext4_current_time(struct inode *inode)
{
return (inode->i_sb->s_time_gran < NSEC_PER_SEC) ?
current_fs_time(inode->i_sb) : current_fs_time_sec(inode->i_sb);
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 99c4800..ec1a912 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4756,7 +4756,7 @@ static long ext4_zero_range(struct file *file, loff_t
offset,
loff_t len, int mode)
{
struct inode *inode = file_inode(file);
- struct inode_timespec now;
+ struct timespec64 now;
handle_t *handle = NULL;
unsigned int max_blocks;
loff_t new_size = 0;
@@ -5465,7 +5465,7 @@ int ext4_collapse_range(struct inode *inode, loff_t
offset, loff_t len)
{
struct super_block *sb = inode->i_sb;
ext4_lblk_t punch_start, punch_stop;
- struct inode_timespec now;
+ struct timespec64 now;
handle_t *handle;
unsigned int credits;
loff_t new_size, ioffset;
@@ -5616,7 +5616,7 @@ int ext4_insert_range(struct inode *inode, loff_t offset,
loff_t len)
struct ext4_ext_path *path;
struct ext4_extent *extent;
ext4_lblk_t offset_lblk, len_lblk, ee_start_lblk = 0;
- struct inode_timespec now;
+ struct timespec64 now;
unsigned int credits, ee_len;
int ret = 0, depth, split_flag = 0;
loff_t ioffset;
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 6f16598..929c092 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -756,7 +756,7 @@ struct inode *__ext4_new_inode(handle_t *handle, struct
inode *dir,
ext4_group_t i;
[RFC 04/15] vfs: Add support for vfs code to use 64 bit time
VFS currently uses struct timespec timestamps which are not
y2038 safe.
Change all the struct inode timestamps accesses through
accessor macros only. This will help the switch over
to 64 bit times seamlessly.
Use struct inode_timespec aliases everywhere.
This will change timestamp data types to struct timespec64
when 64 bit time switch occurs.
Change all calls to CURRENT_TIME to current_fs_time().
The CURRENT_TIME macro is not accurate for file system code
as it does not perform range checks on timestamps nor does it
cater to individual file system timestamp granularity.
Change all calls to timespec_trunc() to fs_time_trunc().
The latter supports range checking on timestamps.
Signed-off-by: Deepa Dinamani
---
fs/attr.c| 15 +++---
fs/bad_inode.c | 10 +++--
fs/binfmt_misc.c | 7 +--
fs/inode.c | 53
fs/libfs.c | 45
fs/locks.c | 5 ++---
fs/nsfs.c| 6 +-
fs/pipe.c| 6 +-
fs/posix_acl.c | 2 +-
fs/stack.c | 6 +++---
fs/stat.c| 6 +++---
fs/utimes.c | 6 --
include/linux/fs_stack.h | 9
13 files changed, 121 insertions(+), 55 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 6530ced..4156239 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -148,14 +148,14 @@ void setattr_copy(struct inode *inode, const struct iattr
*attr)
if (ia_valid & ATTR_GID)
inode->i_gid = attr->ia_gid;
if (ia_valid & ATTR_ATIME)
- inode->i_atime = timespec_trunc(attr->ia_atime,
- inode->i_sb->s_time_gran);
+ VFS_INODE_SET_XTIME(i_atime, inode,
+ fs_time_trunc(attr->ia_atime, inode->i_sb));
if (ia_valid & ATTR_MTIME)
- inode->i_mtime = timespec_trunc(attr->ia_mtime,
- inode->i_sb->s_time_gran);
+ VFS_INODE_SET_XTIME(i_mtime, inode,
+ fs_time_trunc(attr->ia_mtime, inode->i_sb));
if (ia_valid & ATTR_CTIME)
- inode->i_ctime = timespec_trunc(attr->ia_ctime,
- inode->i_sb->s_time_gran);
+ VFS_INODE_SET_XTIME(i_ctime, inode,
+ fs_time_trunc(attr->ia_ctime, inode->i_sb));
if (ia_valid & ATTR_MODE) {
umode_t mode = attr->ia_mode;
@@ -192,7 +192,7 @@ int notify_change(struct dentry * dentry, struct iattr *
attr, struct inode **de
struct inode *inode = dentry->d_inode;
umode_t mode = inode->i_mode;
int error;
- struct timespec now;
+ struct inode_timespec now;
unsigned int ia_valid = attr->ia_valid;
WARN_ON_ONCE(!mutex_is_locked(>i_mutex));
@@ -210,7 +210,6 @@ int notify_change(struct dentry * dentry, struct iattr *
attr, struct inode **de
}
now = current_fs_time(inode->i_sb);
-
attr->ia_ctime = now;
if (!(ia_valid & ATTR_ATIME_SET))
attr->ia_atime = now;
diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index 103f5d7..3c51e22 100644
--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -169,11 +169,17 @@ static const struct inode_operations bad_inode_ops =
void make_bad_inode(struct inode *inode)
{
+ struct inode_timespec now;
+
remove_inode_hash(inode);
inode->i_mode = S_IFREG;
- inode->i_atime = inode->i_mtime = inode->i_ctime =
- current_fs_time(inode->i_sb);
+
+ now = current_fs_time(inode->i_sb);
+
+ VFS_INODE_SET_XTIME(i_atime, inode, now);
+ VFS_INODE_SET_XTIME(i_mtime, inode, now);
+ VFS_INODE_SET_XTIME(i_ctime, inode, now);
inode->i_op = _inode_ops;
inode->i_fop = _file_ops;
}
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index 78f005f..4fd4437 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -562,12 +562,15 @@ static void entry_status(Node *e, char *page)
static struct inode *bm_get_inode(struct super_block *sb, int mode)
{
struct inode *inode = new_inode(sb);
+ struct inode_timespec now;
if (inode) {
inode->i_ino = get_next_ino();
inode->i_mode = mode;
- inode->i_atime = inode->i_mtime = inode->i_ctime =
- current_fs_time(inode->i_sb);
+ now = current_fs_time(inode->i_sb);
+ VFS_INODE_SET_XTIME(i_atime, inode, now);
+ VFS_INODE_SET_XTIME(i_mtime, inode, now);
+ VFS_INODE_SET_XTIME(i_ctime, inode, now);
}
return inode;
}
diff --git a/fs/inode.c b/fs/inode.c
index 4c8f719..d3d64dc 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1532,27 +1532,36 @@ EXPORT_SYMBOL(bmap);
* passed since the last atime update.
*/
static int
[RFC 03/15] kernel: time: Add macros and functions to support 64 bit time
The current_fs_time function is not y2038 safe because
of the use of struct timespec.
The macros CURRENT_TIME and CURRENT_TIME_SEC do not represent
file system times correctly as they cannnot perform range checks
or truncations. These are also not y2038 safe. Add 64 bit versions
of the above macros.
Provide a new set of FS_TIME macros which will return time in
timespec or timespec64 based on CONFIG_FS_USES_64_BIT_TIME.
These are meant to be used only within file systems because of
being tied to the above config. Once the config is enabled,
the timespec version of it can be deleted and the 64 bit time version
can be used elsewhere also.
Add struct timespec64 version for current_fs_time().
Current version of current_fs_time() can be dropped after enabling
CONFIG_FS_USES_64BIT_TIME.
Provide an alternative to timespec_trunc(): fs_time_trunc().
This function takes super block as an argument in addition to
timestamp so that it can include range and precision checks.
Additionally, the function uses y2038 safe timespec64 instead of
timespec for timestamp representation.
Add function: current_fs_time_sec() to obtain only the seconds
portion of the current time(Equivalent to CURRENT_TIME_SEC).
This function has two versions selected by the config
CONFIG_FS_USES_64BIT_TIME.
The 32 bit version support can be dropped after the above config
is enabled globally.
All calls to timespec_trunc() will be eventually replaced by
fs_time_trunc(). At which point, timespec_trunc() can be deleted.
All the above function calls use fs_time_range_check() to clamp
the timestamps.
Inodes that are saved in memory and on disk always have valid
timestamps. But, the accessors can detect a clamped timestamp
while saving the timestamps into inodes.
The clamped timestamp handling is split into two seperate cases:
a. Mounting a fs that has exceeded it's current timestamp needs.
b. A mounted fs exceeds timestamps needs.
Both the above cases are handled using seperate callbacks:
superblock bad_timestamp_mount and bad_timestamp operations.
Motivation for the above callbacks being that the Linux kernel does
not internally use timestamps and it cannot decide how catastrophic
these timestamp clamps can be for the on disk file system or
user space applications that use it.
Signed-off-by: Deepa Dinamani
---
fs/libfs.c | 5 ++
fs/super.c | 10
include/linux/fs.h | 50 ++--
include/linux/time64.h | 4 ++
kernel/time/time.c | 156 +
5 files changed, 196 insertions(+), 29 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c
index 8dc37fc..4fa2002 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -227,6 +227,9 @@ struct dentry *mount_pseudo(struct file_system_type
*fs_type, char *name,
s->s_magic = magic;
s->s_op = ops ? ops : _super_operations;
s->s_time_gran = 1;
+ s->s_time_min = FS_DEFAULT_MIN_TIMESTAMP;
+ s->s_time_max = FS_DEFAULT_MAX_TIMESTAMP;
+
root = new_inode(s);
if (!root)
goto Enomem;
@@ -482,6 +485,8 @@ int simple_fill_super(struct super_block *s, unsigned long
magic,
s->s_magic = magic;
s->s_op = _super_operations;
s->s_time_gran = 1;
+ s->s_time_min = FS_DEFAULT_MIN_TIMESTAMP;
+ s->s_time_max = FS_DEFAULT_MAX_TIMESTAMP;
inode = new_inode(s);
if (!inode)
diff --git a/fs/super.c b/fs/super.c
index 7ea56de..3f53def 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -239,6 +239,8 @@ static struct super_block *alloc_super(struct
file_system_type *type, int flags)
s->s_maxbytes = MAX_NON_LFS;
s->s_op = _op;
s->s_time_gran = 10;
+ s->s_time_min = FS_DEFAULT_MIN_TIMESTAMP;
+ s->s_time_max = FS_DEFAULT_MAX_TIMESTAMP;
s->cleancache_poolid = CLEANCACHE_NO_POOL;
s->s_shrink.seeks = DEFAULT_SEEKS;
@@ -1143,6 +1145,14 @@ mount_fs(struct file_system_type *type, int flags, const
char *name, void *data)
WARN((sb->s_maxbytes < 0), "%s set sb->s_maxbytes to "
"negative value (%lld)\n", type->name, sb->s_maxbytes);
+ /* check timestamp range */
+ if (unlikely(is_fs_timestamp_bad(current_fs_time(sb))) &&
+ (sb->s_op->bad_timestamp_mount)) {
+ error = sb->s_op->bad_timestamp_mount(sb);
+ if (error)
+ goto out_sb;
+ }
+
up_write(>s_umount);
free_secdata(secdata);
return root;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b9f3cee..5112bc2 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -693,8 +693,14 @@ struct inode {
#define VFS_INODE_SET_XTIME(xtime, inode, ts64)\
do {\
struct inode_timespec __ts = (ts64);\
+ struct super_block *__sb = inode->i_sb; \
[RFC 10/15] fs: fat: replace inode_timespec with timespec64
Substitute inode_timespec aliases with timespec64.
Since CONFIG_FS_USES_64BIT_TIME is enabled, internally
all inode_timespec references are using timespec64
already.
Signed-off-by: Deepa Dinamani
---
fs/fat/dir.c | 4 ++--
fs/fat/fat.h | 6 +++---
fs/fat/file.c| 4 ++--
fs/fat/inode.c | 12 ++--
fs/fat/misc.c| 4 ++--
fs/fat/namei_msdos.c | 8
fs/fat/namei_vfat.c | 14 +++---
7 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/fs/fat/dir.c b/fs/fat/dir.c
index fa8a922..683f973 100644
--- a/fs/fat/dir.c
+++ b/fs/fat/dir.c
@@ -1034,7 +1034,7 @@ int fat_remove_entries(struct inode *dir, struct
fat_slot_info *sinfo)
struct super_block *sb = dir->i_sb;
struct msdos_dir_entry *de;
struct buffer_head *bh;
- struct inode_timespec now;
+ struct timespec64 now;
int err = 0, nr_slots;
/*
@@ -1133,7 +1133,7 @@ error:
return err;
}
-int fat_alloc_new_dir(struct inode *dir, struct inode_timespec *ts)
+int fat_alloc_new_dir(struct inode *dir, struct timespec64 *ts)
{
struct super_block *sb = dir->i_sb;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index cabb0fd..859626a 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -303,7 +303,7 @@ extern int fat_scan_logstart(struct inode *dir, int
i_logstart,
struct fat_slot_info *sinfo);
extern int fat_get_dotdot_entry(struct inode *dir, struct buffer_head **bh,
struct msdos_dir_entry **de);
-extern int fat_alloc_new_dir(struct inode *dir, struct inode_timespec *ts);
+extern int fat_alloc_new_dir(struct inode *dir, struct timespec64 *ts);
extern int fat_add_entries(struct inode *dir, void *slots, int nr_slots,
struct fat_slot_info *sinfo);
extern int fat_remove_entries(struct inode *dir, struct fat_slot_info *sinfo);
@@ -406,10 +406,10 @@ void fat_msg(struct super_block *sb, const char *level,
const char *fmt, ...);
extern int fat_clusters_flush(struct super_block *sb);
extern int fat_chain_add(struct inode *inode, int new_dclus, int nr_cluster);
extern void fat_time_fat2unix(struct msdos_sb_info *sbi,
- struct inode_timespec *ts,
+ struct timespec64 *ts,
__le16 __time, __le16 __date, u8 time_cs);
extern void fat_time_unix2fat(struct msdos_sb_info *sbi,
- struct inode_timespec *ts,
+ struct timespec64 *ts,
__le16 *time, __le16 *date, u8 *time_cs);
extern int fat_sync_bhs(struct buffer_head **bhs, int nr_bhs);
diff --git a/fs/fat/file.c b/fs/fat/file.c
index e7f060f..48c985d 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -188,7 +188,7 @@ static int fat_cont_expand(struct inode *inode, loff_t size)
{
struct address_space *mapping = inode->i_mapping;
loff_t start = inode->i_size, count = size - inode->i_size;
- struct inode_timespec ts;
+ struct timespec64 ts;
int err;
err = generic_cont_expand_simple(inode, size);
@@ -283,7 +283,7 @@ error:
static int fat_free(struct inode *inode, int skip)
{
struct super_block *sb = inode->i_sb;
- struct inode_timespec ts;
+ struct timespec64 ts;
int err, wait, free_start, i_start, i_logstart;
if (MSDOS_I(inode)->i_start == 0)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index a1eba05..03a8fa0 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -232,7 +232,7 @@ static int fat_write_end(struct file *file, struct
address_space *mapping,
struct page *pagep, void *fsdata)
{
struct inode *inode = mapping->host;
- struct inode_timespec ts;
+ struct timespec64 ts;
int err;
err = generic_write_end(file, mapping, pos, len, copied, pagep, fsdata);
if (err < len)
@@ -505,7 +505,7 @@ static int fat_validate_dir(struct inode *dir)
int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
{
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
- struct inode_timespec mtime, ctime, atime;
+ struct timespec64 mtime, ctime, atime;
int error;
MSDOS_I(inode)->i_pos = 0;
@@ -840,7 +840,7 @@ static int __fat_write_inode(struct inode *inode, int wait)
struct msdos_sb_info *sbi = MSDOS_SB(sb);
struct buffer_head *bh;
struct msdos_dir_entry *raw_entry;
- struct inode_timespec ts;
+ struct timespec64 ts;
loff_t i_pos;
sector_t blocknr;
int err, offset;
@@ -1402,9 +1402,9 @@ static int fat_read_root(struct inode *inode)
MSDOS_I(inode)->mmu_private = inode->i_size;
fat_save_attrs(inode, ATTR_DIR);
- VFS_INODE_SET_XTIME(i_atime, inode, ((struct inode_timespec) {0, 0}));
- VFS_INODE_SET_XTIME(i_mtime, inode, ((struct
[RFC 15/15] fs: Drop CONFIG_FS_USES_64BIT_TIME
All file system code is using 64 bit time already and this config is no longer required. Signed-off-by: Deepa Dinamani --- fs/Kconfig | 10 -- 1 file changed, 10 deletions(-) diff --git a/fs/Kconfig b/fs/Kconfig index bfeefce..922893f 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -8,16 +8,6 @@ menu "File systems" config DCACHE_WORD_ACCESS bool -#use 64 bit timestamps -config FS_USES_64BIT_TIME - bool - default y - help -Temporary configuration to switch over all file systems to -use 64 bit time. -Need to be enabled only after all individual file system -and vfs changes are in place. - if BLOCK source "fs/ext2/Kconfig" -- 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/
[RFC 05/15] fs: cifs: Add support for cifs to use 64 bit time
Change all struct timespec references to struct inode_timespec.
Use inode timestamp accessors to access inode time fields.
This will help the switch to struct timespec64 when
CONFIG_FS_USES_64BIT_TIME is enabled.
Use current_fs_time() instead of CURRENT_TIME macros to help
range and precision checks.
Truncate and perform range checks before saving the times in
struct inode.
Switch over connection times to use SYSTEM_TIME macro instead
of CURRENT_TIME. Since SYSTEM_TIME is also under the
CONFIG_FS_USES_64BIT_TIME this will help the switch to use
timespec64.
Use long long for seconds field in cnvrtDosUnixTm(). This will
help represent 64 bit time.
Since DOS uses 1980 epoch, all the timestamps are positive when
represented in UNIX format. Change all arithmetic to unsigned.
Note that even though the theoretical max on DOS times is 2107,
its api's only support until the year 2099. This means we can
get away with 32 bit unsigned sec field. But, the sec field uses
long long to maintain uniformity in the kernel, where everyone
uses the theoretical max.
Signed-off-by: Deepa Dinamani
---
fs/cifs/cache.c | 16 -
fs/cifs/cifsencrypt.c | 2 +-
fs/cifs/cifsglob.h| 6 ++---
fs/cifs/cifsproto.h | 9 +++
fs/cifs/cifssmb.c | 17 +-
fs/cifs/file.c| 9 ---
fs/cifs/inode.c | 65 +--
fs/cifs/netmisc.c | 26 +++--
8 files changed, 92 insertions(+), 58 deletions(-)
diff --git a/fs/cifs/cache.c b/fs/cifs/cache.c
index 6c665bf..8d27e69b 100644
--- a/fs/cifs/cache.c
+++ b/fs/cifs/cache.c
@@ -221,8 +221,8 @@ const struct fscache_cookie_def
cifs_fscache_super_index_def = {
* Auxiliary data attached to CIFS inode within the cache
*/
struct cifs_fscache_inode_auxdata {
- struct timespec last_write_time;
- struct timespec last_change_time;
+ struct inode_timespec last_write_time;
+ struct inode_timespec last_change_time;
u64 eof;
};
@@ -259,8 +259,10 @@ cifs_fscache_inode_get_aux(const void *cookie_netfs_data,
void *buffer,
memset(, 0, sizeof(auxdata));
auxdata.eof = cifsi->server_eof;
- auxdata.last_write_time = cifsi->vfs_inode.i_mtime;
- auxdata.last_change_time = cifsi->vfs_inode.i_ctime;
+ auxdata.last_write_time =
+ VFS_INODE_GET_XTIME(i_mtime, >vfs_inode);
+ auxdata.last_change_time =
+ VFS_INODE_GET_XTIME(i_ctime, >vfs_inode);
if (maxbuf > sizeof(auxdata))
maxbuf = sizeof(auxdata);
@@ -283,8 +285,10 @@ fscache_checkaux cifs_fscache_inode_check_aux(void
*cookie_netfs_data,
memset(, 0, sizeof(auxdata));
auxdata.eof = cifsi->server_eof;
- auxdata.last_write_time = cifsi->vfs_inode.i_mtime;
- auxdata.last_change_time = cifsi->vfs_inode.i_ctime;
+ auxdata.last_write_time =
+ VFS_INODE_GET_XTIME(i_mtime, >vfs_inode);
+ auxdata.last_change_time =
+ VFS_INODE_GET_XTIME(i_ctime, >vfs_inode);
if (memcmp(data, , datalen) != 0)
return FSCACHE_CHECKAUX_OBSOLETE;
diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
index afa09fc..b0ef587 100644
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -483,7 +483,7 @@ find_timestamp(struct cifs_ses *ses)
blobptr += attrsize; /* advance attr value */
}
- return cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
+ return cpu_to_le64(cifs_UnixTimeToNT(FS_TIME));
}
static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash,
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index a25b251..c95dce7 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -1393,9 +1393,9 @@ struct cifs_fattr {
dev_t cf_rdev;
unsigned intcf_nlink;
unsigned intcf_dtype;
- struct timespec cf_atime;
- struct timespec cf_mtime;
- struct timespec cf_ctime;
+ struct inode_timespec cf_atime;
+ struct inode_timespec cf_mtime;
+ struct inode_timespec cf_ctime;
};
static inline void free_dfs_info_param(struct dfs_info3_param *param)
diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index eed7ff5..9979c74 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -126,10 +126,11 @@ extern enum securityEnum select_sectype(struct
TCP_Server_Info *server,
enum securityEnum requested);
extern int CIFS_SessSetup(const unsigned int xid, struct cifs_ses *ses,
const struct nls_table *nls_cp);
-extern struct timespec cifs_NTtimeToUnix(__le64 utc_nanoseconds_since_1601);
-extern u64 cifs_UnixTimeToNT(struct timespec);
-extern struct timespec cnvrtDosUnixTm(__le16 le_date, __le16 le_time,
- int offset);
+extern struct inode_timespec
+ cifs_NTtimeToUnix(__le64 utc_nanoseconds_since_1601);
+extern u64
[RFC 14/15] vfs: Remove inode_timespec aliases
Now that CONFIG_FS_USES_64BIT_TIME is enabled, the aliases
for inode_timespec are no longer used and can be removed.
Signed-off-by: Deepa Dinamani
---
include/linux/time64.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/include/linux/time64.h b/include/linux/time64.h
index eb3cdc0..f30c910 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -26,27 +26,6 @@ struct itimerspec64 {
#endif
-#ifdef CONFIG_FS_USES_64BIT_TIME
-
-/* Place holder defines until CONFIG_FS_USES_64BIT_TIME
- * is enabled.
- * timespec64 data type and functions will be used at that
- * time directly and these defines will be deleted.
- */
-#define inode_timespec timespec64
-
-#define inode_timespec_compare timespec64_compare
-#define inode_timespec_equal timespec64_equal
-
-#else
-
-#define inode_timespec timespec
-
-#define inode_timespec_compare timespec_compare
-#define inode_timespec_equal timespec_equal
-
-#endif
-
#define CURRENT_TIME64 (current_kernel_time64())
#define CURRENT_TIME64_SEC \
((struct timespec64) { ktime_get_real_seconds(), 0 })
--
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/
[RFC 12/15] vfs: remove inode_timespec and timespec references
Substitute inode_timespec aliases with timespec64.
Since CONFIG_FS_USES_64BIT_TIME is enabled, internally
all inode_timespec references are using timespec64
already.
Signed-off-by: Deepa Dinamani
---
fs/attr.c| 2 +-
fs/bad_inode.c | 2 +-
fs/binfmt_misc.c | 2 +-
fs/inode.c | 36 ++--
fs/libfs.c | 12 ++--
fs/locks.c | 2 +-
fs/nsfs.c| 2 +-
fs/pipe.c| 2 +-
fs/utimes.c | 4 ++--
include/linux/fs.h | 24 +---
include/linux/stat.h | 6 +++---
11 files changed, 44 insertions(+), 50 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index 4156239..ec5e9ad 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -192,7 +192,7 @@ int notify_change(struct dentry * dentry, struct iattr *
attr, struct inode **de
struct inode *inode = dentry->d_inode;
umode_t mode = inode->i_mode;
int error;
- struct inode_timespec now;
+ struct timespec64 now;
unsigned int ia_valid = attr->ia_valid;
WARN_ON_ONCE(!mutex_is_locked(>i_mutex));
diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index 3c51e22..2a8daef 100644
--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -169,7 +169,7 @@ static const struct inode_operations bad_inode_ops =
void make_bad_inode(struct inode *inode)
{
- struct inode_timespec now;
+ struct timespec64 now;
remove_inode_hash(inode);
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index 4fd4437..c58ecb7 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -562,7 +562,7 @@ static void entry_status(Node *e, char *page)
static struct inode *bm_get_inode(struct super_block *sb, int mode)
{
struct inode *inode = new_inode(sb);
- struct inode_timespec now;
+ struct timespec64 now;
if (inode) {
inode->i_ino = get_next_ino();
diff --git a/fs/inode.c b/fs/inode.c
index d3d64dc..86218f6 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1532,12 +1532,12 @@ EXPORT_SYMBOL(bmap);
* passed since the last atime update.
*/
static int relatime_need_update(struct vfsmount *mnt, struct inode *inode,
-struct inode_timespec now)
+struct timespec64 now)
{
- struct inode_timespec ctime;
- struct inode_timespec mtime;
- struct inode_timespec atime;
+ struct timespec64 ctime;
+ struct timespec64 mtime;
+ struct timespec64 atime;
if (!(mnt->mnt_flags & MNT_RELATIME))
return 1;
@@ -1549,12 +1549,12 @@ static int relatime_need_update(struct vfsmount *mnt,
struct inode *inode,
/*
* Is mtime younger than atime? If yes, update atime:
*/
- if (inode_timespec_compare(, ) >= 0)
+ if (timespec64_compare(, ) >= 0)
return 1;
/*
* Is ctime younger than atime? If yes, update atime:
*/
- if (inode_timespec_compare(, ) >= 0)
+ if (timespec64_compare(, ) >= 0)
return 1;
/*
@@ -1569,7 +1569,7 @@ static int relatime_need_update(struct vfsmount *mnt,
struct inode *inode,
return 0;
}
-int generic_update_time(struct inode *inode, struct inode_timespec *time,
+int generic_update_time(struct inode *inode, struct timespec64 *time,
int flags)
{
int iflags = I_DIRTY_TIME;
@@ -1594,10 +1594,10 @@ EXPORT_SYMBOL(generic_update_time);
* This does the actual work of updating an inodes time or version. Must have
* had called mnt_want_write() before calling this.
*/
-static int update_time(struct inode *inode, struct inode_timespec *time,
+static int update_time(struct inode *inode, struct timespec64 *time,
int flags)
{
- int (*update_time)(struct inode *, struct inode_timespec *, int);
+ int (*update_time)(struct inode *, struct timespec64 *, int);
update_time = inode->i_op->update_time ? inode->i_op->update_time :
generic_update_time;
@@ -1617,8 +1617,8 @@ static int update_time(struct inode *inode, struct
inode_timespec *time,
bool atime_needs_update(const struct path *path, struct inode *inode)
{
struct vfsmount *mnt = path->mnt;
- struct inode_timespec now;
- struct inode_timespec atime;
+ struct timespec64 now;
+ struct timespec64 atime;
if (inode->i_flags & S_NOATIME)
return false;
@@ -1637,7 +1637,7 @@ bool atime_needs_update(const struct path *path, struct
inode *inode)
return false;
atime = VFS_INODE_GET_XTIME(i_atime, inode);
- if (inode_timespec_equal(, ))
+ if (timespec64_equal(, ))
return false;
return true;
@@ -1647,7 +1647,7 @@ void touch_atime(const struct path *path)
{
struct vfsmount *mnt = path->mnt;
struct inode *inode = d_inode(path->dentry);
- struct inode_timespec now;
+ struct
[RFC 13/15] kernel: time: change inode_timespec to timespec64
Substitute inode_timespec aliases with timespec64.
Since CONFIG_FS_USES_64BIT_TIME is enabled, internally
all inode_timespec references are using timespec64
already.
Signed-off-by: Deepa Dinamani
Conflicts:
kernel/time/time.c
Conflicts:
kernel/time/time.c
---
kernel/time/time.c | 130 +++--
1 file changed, 76 insertions(+), 54 deletions(-)
diff --git a/kernel/time/time.c b/kernel/time/time.c
index 24ca258..87d9a4c 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -230,6 +230,76 @@ SYSCALL_DEFINE1(adjtimex, struct timex __user *, txc_p)
return copy_to_user(txc_p, , sizeof(struct timex)) ? -EFAULT : ret;
}
+<<< HEAD
+===
+/**
+ * current_fs_time - Return FS time
+ * @sb: Superblock.
+ *
+ * Return the current time truncated to the time granularity supported by
+ * the fs.
+ */
+struct timespec64 current_fs_time(struct super_block *sb)
+{
+ struct timespec64 now = current_kernel_time64();
+
+ return fs_time_trunc(now, sb);
+}
+EXPORT_SYMBOL(current_fs_time);
+
+struct timespec64 current_fs_time_sec(struct super_block *sb)
+{
+ struct timespec64 ts = {ktime_get_real_seconds(), 0};
+
+ /* range check for time. */
+ fs_time_range_check(sb, );
+
+ return ts;
+}
+EXPORT_SYMBOL(current_fs_time_sec);
+
+/*
+ * Convert jiffies to milliseconds and back.
+ *
+ * Avoid unnecessary multiplications/divisions in the
+ * two most common HZ cases:
+ */
+unsigned int jiffies_to_msecs(const unsigned long j)
+{
+#if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
+ return (MSEC_PER_SEC / HZ) * j;
+#elif HZ > MSEC_PER_SEC && !(HZ % MSEC_PER_SEC)
+ return (j + (HZ / MSEC_PER_SEC) - 1)/(HZ / MSEC_PER_SEC);
+#else
+# if BITS_PER_LONG == 32
+ return (HZ_TO_MSEC_MUL32 * j) >> HZ_TO_MSEC_SHR32;
+# else
+ return (j * HZ_TO_MSEC_NUM) / HZ_TO_MSEC_DEN;
+# endif
+#endif
+}
+EXPORT_SYMBOL(jiffies_to_msecs);
+
+unsigned int jiffies_to_usecs(const unsigned long j)
+{
+ /*
+* Hz usually doesn't go much further MSEC_PER_SEC.
+* jiffies_to_usecs() and usecs_to_jiffies() depend on that.
+*/
+ BUILD_BUG_ON(HZ > USEC_PER_SEC);
+
+#if !(USEC_PER_SEC % HZ)
+ return (USEC_PER_SEC / HZ) * j;
+#else
+# if BITS_PER_LONG == 32
+ return (HZ_TO_USEC_MUL32 * j) >> HZ_TO_USEC_SHR32;
+# else
+ return (j * HZ_TO_USEC_NUM) / HZ_TO_USEC_DEN;
+# endif
+#endif
+}
+EXPORT_SYMBOL(jiffies_to_usecs);
+
/* fs_time_range_check:
* Function to check if a given timestamp is in the range allowed for a
* filesystem.
@@ -240,7 +310,7 @@ SYSCALL_DEFINE1(adjtimex, struct timex __user *, txc_p)
* nsec is set to 0 if not in allowed range.
*/
static void
-fs_time_range_check(struct super_block *sb, struct inode_timespec *ts)
+fs_time_range_check(struct super_block *sb, struct timespec64 *ts)
{
if (unlikely(sb->s_time_max < ts->tv_sec ||
sb->s_time_min > ts->tv_sec)) {
@@ -257,7 +327,7 @@ fs_time_range_check(struct super_block *sb, struct
inode_timespec *ts)
* fs_time_range_check.
* returns 0 otherwise.
*/
-int is_fs_timestamp_bad(struct inode_timespec ts)
+int is_fs_timestamp_bad(struct timespec64 ts)
{
if (ts.tv_nsec == FS_TIMESTAMP_NSEC_NOT_VALID)
return -1;
@@ -267,16 +337,16 @@ int is_fs_timestamp_bad(struct inode_timespec ts)
EXPORT_SYMBOL(is_fs_timestamp_bad);
/*
- * fs_time_trunc - Truncate inode_timespec to a granularity
- * @t: inode_timespec
+ * fs_time_trunc - Truncate timespec64 to a granularity
+ * @t: timespec64
* @sb: Super block.
*
* Truncate a timespec to a granularity. Always rounds down. Granularity
* must * not be 0 nor greater than a second (NSEC_PER_SEC, or 10^9 ns).
* Returns 1 on error, 0 otherwise.
*/
-struct inode_timespec
-fs_time_trunc(struct inode_timespec t, struct super_block *sb)
+struct timespec64
+fs_time_trunc(struct timespec64 t, struct super_block *sb)
{
u32 gran = sb->s_time_gran;
@@ -300,34 +370,6 @@ fs_time_trunc(struct inode_timespec t, struct super_block
*sb)
EXPORT_SYMBOL(fs_time_trunc);
/**
- * timespec_trunc - Truncate timespec to a granularity
- * @t: Timespec
- * @gran: Granularity in ns.
- *
- * Truncate a timespec to a granularity. Always rounds down. gran must
- * not be 0 nor greater than a second (NSEC_PER_SEC, or 10^9 ns).
- *
- * This function is deprecated and should no longer be used for filesystems.
- * fs_time_trunc should be used instead.
- */
-struct timespec timespec_trunc(struct timespec t, unsigned gran)
-{
-
- /* Avoid division in the common cases 1 ns and 1 s. */
- if (gran == 1) {
- /* nothing */
- } else if (gran == NSEC_PER_SEC) {
- t.tv_nsec = 0;
- } else if (gran > 1 && gran < NSEC_PER_SEC) {
- t.tv_nsec -= t.tv_nsec % gran;
- } else {
- WARN(1, "illegal file time granularity: %u", gran);
- }
- return t;
-}
[RFC 06/15] fs: fat: convert fat to 64 bit time
FAT filesystem supports timestamps until the year 2099
even though the theoretical max is 2107.
But, the struct timespec overflows in the year 2038 on
32 bit systems.
Use inode_timespec throughout the file system code so
that the timestamps can switch to y2038 safe
struct timespec64 when CONFIG_FS_USES_64BIT_TIME is
turned on.
Use a larger data type for seconds in fat_time_fat2unix().
This extends timestamps beyond the year 2038.
Signed-off-by: Deepa Dinamani
---
fs/fat/dir.c | 7 +--
fs/fat/fat.h | 8 +---
fs/fat/file.c| 10 --
fs/fat/inode.c | 46 --
fs/fat/misc.c| 7 ---
fs/fat/namei_msdos.c | 40 +---
fs/fat/namei_vfat.c | 41 +++--
7 files changed, 106 insertions(+), 53 deletions(-)
diff --git a/fs/fat/dir.c b/fs/fat/dir.c
index 7def96c..fa8a922 100644
--- a/fs/fat/dir.c
+++ b/fs/fat/dir.c
@@ -1034,6 +1034,7 @@ int fat_remove_entries(struct inode *dir, struct
fat_slot_info *sinfo)
struct super_block *sb = dir->i_sb;
struct msdos_dir_entry *de;
struct buffer_head *bh;
+ struct inode_timespec now;
int err = 0, nr_slots;
/*
@@ -1071,7 +1072,9 @@ int fat_remove_entries(struct inode *dir, struct
fat_slot_info *sinfo)
}
}
- dir->i_mtime = dir->i_atime = CURRENT_TIME_SEC;
+ now = current_fs_time_sec(sb);
+ VFS_INODE_SET_XTIME(i_mtime, dir, now);
+ VFS_INODE_SET_XTIME(i_atime, dir, now);
if (IS_DIRSYNC(dir))
(void)fat_sync_inode(dir);
else
@@ -1130,7 +1133,7 @@ error:
return err;
}
-int fat_alloc_new_dir(struct inode *dir, struct timespec *ts)
+int fat_alloc_new_dir(struct inode *dir, struct inode_timespec *ts)
{
struct super_block *sb = dir->i_sb;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index e6b764a..cabb0fd 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -303,7 +303,7 @@ extern int fat_scan_logstart(struct inode *dir, int
i_logstart,
struct fat_slot_info *sinfo);
extern int fat_get_dotdot_entry(struct inode *dir, struct buffer_head **bh,
struct msdos_dir_entry **de);
-extern int fat_alloc_new_dir(struct inode *dir, struct timespec *ts);
+extern int fat_alloc_new_dir(struct inode *dir, struct inode_timespec *ts);
extern int fat_add_entries(struct inode *dir, void *slots, int nr_slots,
struct fat_slot_info *sinfo);
extern int fat_remove_entries(struct inode *dir, struct fat_slot_info *sinfo);
@@ -405,9 +405,11 @@ void fat_msg(struct super_block *sb, const char *level,
const char *fmt, ...);
} while (0)
extern int fat_clusters_flush(struct super_block *sb);
extern int fat_chain_add(struct inode *inode, int new_dclus, int nr_cluster);
-extern void fat_time_fat2unix(struct msdos_sb_info *sbi, struct timespec *ts,
+extern void fat_time_fat2unix(struct msdos_sb_info *sbi,
+ struct inode_timespec *ts,
__le16 __time, __le16 __date, u8 time_cs);
-extern void fat_time_unix2fat(struct msdos_sb_info *sbi, struct timespec *ts,
+extern void fat_time_unix2fat(struct msdos_sb_info *sbi,
+ struct inode_timespec *ts,
__le16 *time, __le16 *date, u8 *time_cs);
extern int fat_sync_bhs(struct buffer_head **bhs, int nr_bhs);
diff --git a/fs/fat/file.c b/fs/fat/file.c
index 43d3475..e7f060f 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -188,13 +188,16 @@ static int fat_cont_expand(struct inode *inode, loff_t
size)
{
struct address_space *mapping = inode->i_mapping;
loff_t start = inode->i_size, count = size - inode->i_size;
+ struct inode_timespec ts;
int err;
err = generic_cont_expand_simple(inode, size);
if (err)
goto out;
- inode->i_ctime = inode->i_mtime = CURRENT_TIME_SEC;
+ ts = current_fs_time_sec(inode->i_sb);
+ VFS_INODE_SET_XTIME(i_ctime, inode, ts);
+ VFS_INODE_SET_XTIME(i_mtime, inode, ts);
mark_inode_dirty(inode);
if (IS_SYNC(inode)) {
int err2;
@@ -280,6 +283,7 @@ error:
static int fat_free(struct inode *inode, int skip)
{
struct super_block *sb = inode->i_sb;
+ struct inode_timespec ts;
int err, wait, free_start, i_start, i_logstart;
if (MSDOS_I(inode)->i_start == 0)
@@ -297,7 +301,9 @@ static int fat_free(struct inode *inode, int skip)
MSDOS_I(inode)->i_logstart = 0;
}
MSDOS_I(inode)->i_attrs |= ATTR_ARCH;
- inode->i_ctime = inode->i_mtime = CURRENT_TIME_SEC;
+ ts = current_fs_time_sec(sb);
+ VFS_INODE_SET_XTIME(i_ctime, inode, ts);
+ VFS_INODE_SET_XTIME(i_mtime, inode, ts);
if (wait) {
[RFC 01/15] fs: add Kconfig entry CONFIG_FS_USES_64BIT_TIME
This config will be used to #ifdef code that will be required for switching over all file systems to use 64 bit time. The config should remain turned off until all the support in vfs and other file systems has been added. Signed-off-by: Deepa Dinamani --- fs/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/fs/Kconfig b/fs/Kconfig index 922893f..a11934b 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -8,6 +8,16 @@ menu "File systems" config DCACHE_WORD_ACCESS bool +#use 64 bit timestamps +config FS_USES_64BIT_TIME + bool + default n + help +Temporary configuration to switch over all file systems to +use 64 bit time. +Need to be enabled only after all individual file system +and vfs changes are in place. + if BLOCK source "fs/ext2/Kconfig" -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag
On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote: > From: Rameshwar Prasad Sahu > > For interrupt controller that doesn't support irq_disable and hardware > with level interrupt, an extra interrupt can be pending. This patch fixes > the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line. > > Reference: http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c > Applied now -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kexec_file_load failed with "Missing required AuthAttr"
Hi,
I saw the warning "Missing required AuthAttr" when testing kexec, known issue?
Idea about how to fix it?
The kernel is latest linus tree plus sevral patches from Toshi to cleanup io
resource structure.
in function pkcs7_sig_note_set_of_authattrs():
if (!test_bit(sinfo_has_content_type, >aa_set) ||
!test_bit(sinfo_has_message_digest, >aa_set) ||
(ctx->msg->data_type == OID_msIndirectData &&
!test_bit(sinfo_has_ms_opus_info, >aa_set))) {
pr_warn("Missing required AuthAttr\n");
return -EBADMSG;
}
The third condition below is true:
(ctx->msg->data_type == OID_msIndirectData &&
!test_bit(sinfo_has_ms_opus_info, >aa_set))
I signed the kernel with redhat test key like below:
pesign -c 'Red Hat Test Certificate' -i arch/x86/boot/bzImage -o
/boot/vmlinuz-4.4.0-rc8+ -s --force
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] clk: qcom: Add MSM8996 Global Clock Control (GCC) driver
Stephen,
On 12/01/2015 07:01 AM, Stephen Boyd wrote:
> Add support for the global clock controller found on MSM8996
> based devices. This should allow most non-multimedia device
> drivers to probe and control their clocks.
On my 8096 board I see the following orphan clocks,
/sys/kernel/debug/clk # cat clk_orphan_summary
clock enable_cnt prepare_cntrate accuracy
phase
---
-
gcc_ufs_rx_symbol_1_clk 00 0 0 0
gcc_ufs_rx_symbol_0_clk 00 0 0 0
gcc_ufs_tx_symbol_0_clk 00 0 0 0
gcc_pcie_2_pipe_clk 00 0 0 0
gcc_pcie_1_pipe_clk 00 0 0 0
gcc_pcie_0_pipe_clk 00 0 0 0
gcc_usb3_phy_pipe_clk00 0 0 0
I was looking at some ufs clocks which lead me to this. something that needs to
be fixed?
regards,
Rajendra
>
> Signed-off-by: Stephen Boyd
> ---
> .../devicetree/bindings/clock/qcom,gcc.txt |1 +
> drivers/clk/qcom/Kconfig |8 +
> drivers/clk/qcom/Makefile |1 +
> drivers/clk/qcom/gcc-msm8996.c | 3422
>
> include/dt-bindings/clock/qcom,gcc-msm8996.h | 339 ++
> 5 files changed, 3771 insertions(+)
> create mode 100644 drivers/clk/qcom/gcc-msm8996.c
> create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8996.h
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
> b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
> index 152dfaab2575..72f82f444091 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
> +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
> @@ -13,6 +13,7 @@ Required properties :
> "qcom,gcc-msm8974"
> "qcom,gcc-msm8974pro"
> "qcom,gcc-msm8974pro-ac"
> + "qcom,gcc-msm8996"
>
> - reg : shall contain base register location and length
> - #clock-cells : shall contain 1
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index ee4c83aab4f4..fb2b499c647d 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -106,3 +106,11 @@ config MSM_MMCC_8974
> Support for the multimedia clock controller on msm8974 devices.
> Say Y if you want to support multimedia devices such as display,
> graphics, video encode/decode, camera, etc.
> +
> +config MSM_GCC_8996
> + tristate "MSM8996 Global Clock Controller"
> + depends on COMMON_CLK_QCOM
> + help
> + Support for the global clock controller on msm8996 devices.
> + Say Y if you want to use peripheral devices such as UART, SPI,
> + i2c, USB, UFS, SD/eMMC, PCIe, etc.
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 472200040788..42dca6799414 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -21,5 +21,6 @@ obj-$(CONFIG_MSM_GCC_8916) += gcc-msm8916.o
> obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
> obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
> obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
> +obj-$(CONFIG_MSM_GCC_8996) += gcc-msm8996.o
> obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
> obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
> diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
> new file mode 100644
> index ..16d7c323db49
> --- /dev/null
> +++ b/drivers/clk/qcom/gcc-msm8996.c
> @@ -0,0 +1,3422 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "common.h"
> +#include "clk-regmap.h"
> +#include "clk-alpha-pll.h"
> +#include "clk-rcg.h"
> +#include "clk-branch.h"
> +#include "reset.h"
> +
> +#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
> +
> +enum {
> + P_XO,
> + P_GPLL0,
> + P_GPLL2,
> + P_GPLL3,
> + P_GPLL1,
> +
Re: [PATCH v2 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
On 01/07/2016 at 10:36 AM, Minfei Huang wrote:
> On 01/07/16 at 10:14am, Xunlei Pang wrote:
+static int
+kexec_mark_range(unsigned long start, unsigned long end, bool protect)
+{
+ struct page *page;
+ unsigned int nr_pages;
+
+ /* For physical range: [start, end] */
+ if (!start || !end || start > end)
+ return 0;
>>> Hi, Xunlei.
>>>
>>> if (start > end)
>>> return 0;
>> If both start and end are zero, we want to return directly, so the two
>> more check doesn't hurt.
> How about if the start is equal to 0, and end is larger than 0? It is
> better to make code more robust, although it never happen in currect
> kexec code.
Hmm, this will be better:
if (!end || start > end)
return 0;
it handles the common case not using crash_low_res(start and end are 0).
Regards,
Xunlei
>
>>> See the below comment.
+
+ page = pfn_to_page(start >> PAGE_SHIFT);
+ nr_pages = (end + PAGE_SIZE - start) >> PAGE_SHIFT;
>>> As I commented in last version, it is better to cover the case if the
>>> range from start to end acrosses two pages.
>> right.
>>
+ if (protect)
+ return set_pages_ro(page, nr_pages);
+ else
+ return set_pages_rw(page, nr_pages);
+}
+
+static void kexec_mark_crashkres(bool protect)
+{
+ unsigned long control;
+
+ kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
>>> Adding the following if test to test crashk_low_res is better. Then we
>>> do not need to test if start or end is equal to 0 in kexec_mark_range.
>>>
>>> if (crashk_low_res.start != crashk_low_res.end) {
>>> kexec_mark_range(crashk_low_res.start,
>>> crashk_low_res.end, protect);
>>> }
>> The checks in kexec_mark_range() will handle the case, it's not
>> performance-critical path and will make the code less clean.
>>
+
+ /* Don't touch the control code page used in crash_kexec().*/
+ control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
+ /* Control code page is located in the 2nd page. */
+ kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
+ kexec_mark_range(control + 2 * PAGE_SIZE, crashk_res.end, protect);
>>> I think it is more readable, if we use MACRO KEXEC_CONTROL_PAGE_SIZE,
>>> instead of using 2*PAGE_SIZE directly.
>> OK.
>>
>> How about the following update:
>> +static void kexec_mark_crashkres(bool protect)
>> +{
>> + unsigned long control;
>> +
>> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
>> +
>> + /* Don't touch the control code page used in crash_kexec().*/
>> + control =
>> PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>> + /* Control code page is located in the 2nd page. */
>> + kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
>> + control += KEXEC_CONTROL_PAGE_SIZE;
>> + kexec_mark_range(control, crashk_res.end, protect);
>> +}
> I'm fine with this.
>
> Thanks
> Minfei
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
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] i2c: designware: Do not require clock when SSCN and FFCN are provided
Hi, On 01/06/2016 06:31 PM, Loc Ho wrote: Hi All, The current driver uses input clock source frequency to calculate values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not currently have a good way to provide the frequency information. Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used to directly provide these values. So, the clock information should no longer be required during probing. However, since clk can be invalid, additional checks must be done where we are making use of it. Signed-off-by: Mika Westerberg Signed-off-by: Suravee Suthikulpanit Tested-by: Loc Ho --- Note: This has been tested on AMD Seattle RevB for both DT and ACPI. Changes from V3 (https://lkml.org/lkml/2015/12/22/596): * Add i2c_dw_plat_prepare_clk() per Andy's suggestion * Add tested-by Loc Ho. The changes from V3 are big enough that I'd appreciate a new Tested-by tag. I had tested this via this mixes of test cases: a. NO APD driver + this patch ==> HCNT/LCNT as expected b. with APD driver + this patch ==> HCNT/LCNT as expected c. with APD driver + this patch + double the frequency APD driver ==> HCNT/LCNT as expected d. with APD driver + this patch + double the frequency APD driver + comment out the ACPI parameter retrieve ==> HCNT/LCNT changed as expected Therefore, you can add my - Tested-by: Loc Ho -Loc Thanks Loc, Suravee -- 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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag
On Wed, Jan 06, 2016 at 11:05:02AM +0100, Thomas Gleixner wrote:
> On Wed, 6 Jan 2016, Vinod Koul wrote:
> > On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
> > > >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct
> > > >> xgene_dma *pdma)
> > > >> /* Register DMA channel rx irq */
> > > >> for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
> > > >> chan = >chan[i];
> > > >> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
> > > >
> > > > Why not use irq_settings_disable_unlazy(), at least read the reference
> > > > you
> > > > pointed out!
> > >
> > > irq_settings_disable_unlazy() is helper function to test
> > > IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
> > > FYI...
> > > +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
> > > +{
> > > + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
> > > +}
> >
> > Ah yes, I saw clear API and assumed there would be set. Then I think we
> > should add a set helper as well as the usage is intended for drivers to
> > set this flag
> >
> > Thomas,
> >
> > Any reason why you didn't add a set helper, only test and clear?
>
> Why would I? Those helpers are core internal and not usable in random drivers.
>
> Drivers have irq_set_status_flags()/irq_clear_status_flags() ...
The effect of irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY) is same as
providing a helper. If your recommendation is to use this by driver then I
am find with the approach too
Thanks
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v1 2/2] dt-bindings: add document for rk3229-hdmi
Signed-off-by: Yakir Yang
---
.../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 668091f..1cdc627 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -2,7 +2,7 @@ Rockchip specific extensions to the Synopsys Designware HDMI
Required properties:
-- compatible: "rockchip,rk3288-dw-hdmi";
+- compatible: "rockchip,rk3288-dw-hdmi", "rockchip,rk3229-dw-hdmi";
- reg: Physical base address and length of the controller's registers.
- clocks: phandle to hdmi iahb and isfr clocks.
- clock-names: should be "iahb" "isfr"
@@ -15,8 +15,10 @@ Required properties:
rk3288 platform
Optional properties
+- reg: Physical base address and length of the external HDMI PHY's registers.
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
+ phandle to the external HDMI PHY clock, name should be
"extphy"
Example:
hdmi: hdmi@ff98 {
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] perf/x86/amd/power: Add AMD accumulated power reporting mechanism
On Thu, Jan 07, 2016 at 11:14:50AM +0800, kbuild test robot wrote: > Hi Huang, > > [auto build test ERROR on bp/for-next] > [also build test ERROR on v4.4-rc8 next-20160106] > [cannot apply to tip/x86/core] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https://github.com/0day-ci/linux/commits/Huang-Rui/perf-x86-power-Introduce-AMD-accumlated-power-reporting-mechanism/20160107-103309 > base: https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp for-next > config: i386-randconfig-s1-201601 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > All error/warnings (new ones prefixed by >>): > >In file included from include/linux/kobject.h:21:0, > from include/linux/module.h:17, > from arch/x86/kernel/cpu/perf_event_amd_power.c:13: > >> arch/x86/kernel/cpu/perf_event.h:663:31: error: 'events_sysfs_show' > >> undeclared here (not in a function) > .attr = __ATTR(_name, 0444, events_sysfs_show, NULL), \ > ^ >include/linux/sysfs.h:103:10: note: in definition of macro '__ATTR' > .show = _show, \ > ^ > >> arch/x86/kernel/cpu/perf_event_amd_power.c:244:1: note: in expansion of > >> macro 'EVENT_ATTR_STR' > EVENT_ATTR_STR(power-pkg, power_pkg, "event=0x01"); > ^ > > vim +/events_sysfs_show +663 arch/x86/kernel/cpu/perf_event.h > Thanks to report this issue. That's because events_sysfs_show is declared under CONFIG_CPU_SUP_INTEL, I will add a patch to move it out. Thanks, Rui -- 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/
[RFC PATCH v1 1/2] drm: rockchip: hdmi: add RK3229 HDMI support
RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
the max output resolution is 4K.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/bridge/dw-hdmi.c| 33 ++-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 380 +---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 ++
include/drm/bridge/dw_hdmi.h| 5 +-
4 files changed, 516 insertions(+), 39 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 6fbec99..60b1dcf 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
{
unsigned res_idx;
u8 val, msec;
+ int ret;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
+ int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
if (prep)
return -EINVAL;
@@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
return -EINVAL;
}
+ if (hdmi->plat_data->extphy_config) {
+ /* gen2 tx power off */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+ ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
+mpixelclock);
+ /* gen2 tx power on */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+ dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+ return ret;
+ }
+
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- mpll_config->mpixelclock)
+ if (mpixelclock <= mpll_config->mpixelclock)
break;
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- curr_ctrl->mpixelclock)
+ if (mpixelclock <= curr_ctrl->mpixelclock)
break;
for (; phy_config->mpixelclock != ~0UL; phy_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- phy_config->mpixelclock)
+ if (mpixelclock <= phy_config->mpixelclock)
break;
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
phy_config->mpixelclock == ~0UL) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
- hdmi->hdmi_data.video_mode.mpixelclock);
+ mpixelclock);
return -EINVAL;
}
@@ -1476,14 +1489,16 @@ dw_hdmi_connector_mode_valid(struct drm_connector
*connector,
{
struct dw_hdmi *hdmi = container_of(connector,
struct dw_hdmi, connector);
+ struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
enum drm_mode_status mode_status = MODE_OK;
/* We don't support double-clocked modes */
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_BAD;
- if (hdmi->plat_data->mode_valid)
- mode_status = hdmi->plat_data->mode_valid(connector, mode);
+ if (plat_data->mode_valid)
+ mode_status = plat_data->mode_valid(plat_data, mode);
+
return mode_status;
}
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index c65ce8c..424d548 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -7,6 +7,7 @@
* (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -21,18 +22,135 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
-#define GRF_SOC_CON60x025c
-#define HDMI_SEL_VOP_LIT(1 << 4)
+#include "dw_hdmi-rockchip.h"
struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
+ struct dw_hdmi_plat_data plat_data;
+
+ void __iomem *extphy_regbase;
+ struct clk *extphy_pclk;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
-static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
+static const struct extphy_config_tab rk3229_extphy_cfg[] = {
+ { .mpixelclock = 16500,
+ .pre_emphasis = 0, .slopeboost = 0, .clk_level = 4,
+ .data0_level = 4, 4, 4,
+ },
+
+
[RFC PATCH v1 0/2] Add RK3229 HDMI support
RK3229 have integrated an DesignedWare HDMI controller and an INNO HDMI phy, so we can still reuse the dw-hdmi driver for RK3229 HDMI controller, but we need to create an separate driver for RK3229 HDMI PHY. Yakir Yang (2): drm: rockchip: hdmi: add RK3229 HDMI support dt-bindings: add document for rk3229-hdmi .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +- drivers/gpu/drm/bridge/dw-hdmi.c | 33 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 380 +++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h| 137 include/drm/bridge/dw_hdmi.h | 5 +- 5 files changed, 519 insertions(+), 40 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel
On Wed, January 6, 2016 6:47 pm, Dmitry Torokhov wrote: > It is wrong. Aside form the fact that IMO xpad.c is the wrong place for > this code to be in, why are we waiting for the input device to be opened by > userspace before we do the switch instead of doing it immediately? The 'send magic' might be better in a probe() call, but I don't believe that it requires userspace interaction as it stands. The wheel will disconnect almost immediately without me doing anything other than plug it in. -- Jan 6 21:18:50 speedster kernel: [ 439.604037] usb 5-1: new full-speed USB device number 2 using uhci_hcd Jan 6 21:18:50 speedster kernel: [ 439.791153] usb 5-1: New USB device found, idVendor=046d, idProduct=c261 Jan 6 21:18:50 speedster kernel: [ 439.791160] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 6 21:18:50 speedster kernel: [ 439.791164] usb 5-1: Product: G920 Driving Force Racing Wheel for Xbox One Jan 6 21:18:50 speedster kernel: [ 439.791167] usb 5-1: Manufacturer: Logitech Jan 6 21:18:50 speedster kernel: [ 439.791170] usb 5-1: SerialNumber: 5d1d5129cebe Jan 6 21:18:50 speedster mtp-probe: checking bus 5, device 2: "/sys/devices/pci:00/:00:1d.3/usb5/5-1" Jan 6 21:18:50 speedster mtp-probe: bus: 5, device: 2 was not an MTP device Jan 6 21:18:51 speedster kernel: [ 440.815191] input: Logitech G920 Driving Force Racing Wheel as /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/input/input4 Jan 6 21:18:51 speedster kernel: [ 440.815310] usbcore: registered new interface driver xpad Jan 6 21:18:52 speedster kernel: [ 441.340093] usb 5-1: USB disconnect, device number 2 Jan 6 21:18:52 speedster kernel: [ 442.052037] usb 5-1: new full-speed USB device number 3 using uhci_hcd Jan 6 21:18:52 speedster kernel: [ 442.239129] usb 5-1: New USB device found, idVendor=046d, idProduct=c262 Jan 6 21:18:52 speedster kernel: [ 442.239136] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 6 21:18:52 speedster kernel: [ 442.239139] usb 5-1: Product: G920 Driving Force Racing Wheel for Xbox One Jan 6 21:18:52 speedster kernel: [ 442.239142] usb 5-1: Manufacturer: Logitech Jan 6 21:18:52 speedster kernel: [ 442.239145] usb 5-1: SerialNumber: 5d1d5129cebe Jan 6 21:18:52 speedster mtp-probe: checking bus 5, device 3: "/sys/devices/pci:00/:00:1d.3/usb5/5-1" Jan 6 21:18:52 speedster mtp-probe: bus: 5, device: 3 was not an MTP device Jan 6 21:18:52 speedster kernel: [ 442.267248] input: Logitech G920 Driving Force Racing Wheel for Xbox One as /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/0003:046D:C262.0002/input/input5 Jan 6 21:18:52 speedster kernel: [ 442.267510] logitech-hidpp-device 0003:046D:C262.0002: input,hiddev0,hidraw1: USB HID v1.11 Joystick [Logitech G920 Driving Force Racing Wheel for Xbox One] on usb-:00:1d.3-1/input0 Jan 6 21:18:53 speedster kernel: [ 442.322160] logitech-hidpp-device 0003:046D:C262.0002: HID++ 4.2 device connected. -- I also did a quick check with the 'send magic' disabled. Xpad creates the js0 and populates buttons, but pressing buttons/turning wheel does not result in any change in js0. I don't disagree to it being a seperate module, but don't have the time to implement/test at the moment. If some else does that would be good, can we make sure that the kconfig/makefile stuff uses same/sensible HID_CONFIGs? Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/5] Make cpuid <-> nodeid mapping persistent.
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.
So here is the problem:
Assume we have the following cpuid <-> nodeid in the beginning:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119
and we hot-remove node2 and node3, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
and we hot-add node4 and node5, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119
But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs){
...
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {
if (cpumask_subset(pool->attrs->cpumask,
wq_numa_possible_cpumask[node])) {
pool->node = node;
break;
}
}
}
Since wq_numa_possible_cpumask is not updated, it could be mapped to an offline
node,
which will lead to memory allocation failure:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
It happens here:
create_worker(struct worker_pool *pool)
|--> worker = alloc_worker(pool->node);
static struct worker *alloc_worker(int node)
{
struct worker *worker;
worker = kzalloc_node(sizeof(*worker), GFP_KERNEL, node); --> Here,
useing the wrong node.
..
return worker;
}
[Solution]
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <->
apicid
mapping. So the key point is obtaining all cpus' apicid.
apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
MADT (Multiple APIC Description Table). So we finish the job in the following
steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
This is done by introducing an extra parameter to generic_processor_info to
let the
caller control if disabled cpus are ignored.
2. Introduce a new array storing all possible cpuid <-> apicid mapping. And
also modify
the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping
when
registering local apic. Store the mapping in this array.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
For previous discussion, please refer to:
https://lkml.org/lkml/2015/2/27/145
https://lkml.org/lkml/2015/3/25/989
https://lkml.org/lkml/2015/5/14/244
https://lkml.org/lkml/2015/7/7/200
https://lkml.org/lkml/2015/9/27/209
Change log v3 -> v4:
1. Fix the kernel panic at boot time. The cause is that I tried to build
zonelists
before per cpu areas were initialized.
Change log v2 -> v3:
1.
[PATCH 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting.
From: Gu Zheng
This patch finishes step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/ia64/kernel/acpi.c | 2 +-
arch/x86/kernel/acpi/boot.c | 2 +-
drivers/acpi/bus.c| 3 ++
drivers/acpi/processor_core.c | 65 +++
include/linux/acpi.h | 2 ++
5 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index b1698bc..7db5563 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -796,7 +796,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
* ACPI based hotplug CPU support
*/
#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
/*
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0ce06ee..7d45261 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -696,7 +696,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a212cef..d59e1cd 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1094,6 +1094,9 @@ static int __init acpi_init(void)
acpi_debugfs_init();
acpi_sleep_proc_init();
acpi_wakeup_device_init();
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+ acpi_set_processor_mapping();
+#endif
return 0;
}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 824b98b..45580ff 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -261,6 +261,71 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static bool map_processor(acpi_handle handle, int *phys_id, int *cpuid)
+{
+ int type;
+ u32 acpi_id;
+ acpi_status status;
+ acpi_object_type acpi_type;
+ unsigned long long tmp;
+ union acpi_object object = { 0 };
+ struct acpi_buffer buffer = { sizeof(union acpi_object), };
+
+ status = acpi_get_type(handle, _type);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ switch (acpi_type) {
+ case ACPI_TYPE_PROCESSOR:
+ status = acpi_evaluate_object(handle, NULL, NULL, );
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = object.processor.proc_id;
+ break;
+ case ACPI_TYPE_DEVICE:
+ status = acpi_evaluate_integer(handle, "_UID", NULL, );
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = tmp;
+ break;
+ default:
+ return false;
+ }
+
+ type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
+
+ *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false);
+ *cpuid = acpi_map_cpuid(*phys_id, acpi_id);
+ if (*cpuid == -1)
+ return false;
+
+ return true;
+}
+
+static acpi_status __init
+set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context,
+ void **rv)
+{
+ u32 apic_id;
+ int cpu_id;
+
+ if (!map_processor(handle, _id, _id))
+ return AE_ERROR;
+
+ acpi_map_cpu2node(handle, cpu_id, apic_id);
+ return AE_OK;
+}
+
+void __init acpi_set_processor_mapping(void)
+{
+ /* Set persistent cpu <-> node mapping for all processors. */
+ acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+ ACPI_UINT32_MAX, set_processor_node_mapping,
+ NULL, NULL, NULL);
+}
+#endif
+
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
u64 *phys_addr, int *ioapic_id)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 1991aea..327cb7e 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -194,6 +194,8 @@ static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
/* Arch dependent functions for cpu hotplug support */
int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu);
int acpi_unmap_cpu(int cpu);
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid);
+void __init acpi_set_processor_mapping(void);
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
[PATCH 2/5] x86, acpi, cpu-hotplug: Enable acpi to register all possible cpus at boot time.
From: Gu Zheng
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.
So here is the problem:
Assume we have the following cpuid <-> nodeid in the beginning:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119
and we hot-remove node2 and node3, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
and we hot-add node4 and node5, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119
But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs){
...
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {
if (cpumask_subset(pool->attrs->cpumask,
wq_numa_possible_cpumask[node])) {
pool->node = node;
break;
}
}
}
Since wq_numa_possible_cpumask is not updated, it could be mapped to an offline
node,
which will lead to memory allocation failure:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
It happens here:
create_worker(struct worker_pool *pool)
|--> worker = alloc_worker(pool->node);
static struct worker *alloc_worker(int node)
{
struct worker *worker;
worker = kzalloc_node(sizeof(*worker), GFP_KERNEL, node); --> Here,
useing the wrong node.
..
return worker;
}
[Solution]
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <->
apicid
mapping. So the key point is obtaining all cpus' apicid.
apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
MADT (Multiple APIC Description Table). So we finish the job in the following
steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
This is done by introducing an extra parameter to generic_processor_info to
let the
caller control if disabled cpus are ignored.
2. Introduce a new array storing all possible cpuid <-> apicid mapping. And
also modify
the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping
when
registering local apic. Store the mapping in this array.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished step 1.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/x86/kernel/apic/apic.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 2f69e3b..29915cf 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1988,7
[PATCH 4/5] x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid.
From: Gu Zheng
This patch finishes step 3.
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
So, in order to setup persistent cpuid <-> nodeid mapping for all possible CPUs,
we should:
1. Setup cpuid <-> apicid mapping for all possible CPUs, which has been done in
step 1.
2. Setup cpuid <-> nodeid mapping for all possible CPUs. But before that, we
should
obtain all apicids from MADT.
All processors' apicids can be obtained by _MAT method or from MADT in ACPI.
The current code ignores disabled processors and returns -ENODEV.
After this patch, a new parameter will be added to MADT APIs so that caller
is able to control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40 insertions(+), 22 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 6979186..d30111a 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -300,8 +300,11 @@ static int acpi_processor_get_info(struct acpi_device
*device)
* Extra Processor objects may be enumerated on MP systems with
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
+*
+* NOTE: Even if the processor has a cpuid, it may not present because
+* cpuid <-> apicid mapping is persistent now.
*/
- if (invalid_logical_cpuid(pr->id)) {
+ if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
int ret = acpi_processor_hotadd_init(pr);
if (ret)
return ret;
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 33a38d6..824b98b 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -32,12 +32,12 @@ static struct acpi_table_madt *get_madt_table(void)
}
static int map_lapic_id(struct acpi_subtable_header *entry,
-u32 acpi_id, phys_cpuid_t *apic_id)
+u32 acpi_id, phys_cpuid_t *apic_id, bool ignore_disabled)
{
struct acpi_madt_local_apic *lapic =
container_of(entry, struct acpi_madt_local_apic, header);
- if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(lapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (lapic->processor_id != acpi_id)
@@ -48,12 +48,13 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
}
static int map_x2apic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
+ bool ignore_disabled)
{
struct acpi_madt_local_x2apic *apic =
container_of(entry, struct acpi_madt_local_x2apic, header);
- if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(apic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration && (apic->uid == acpi_id)) {
@@ -65,12 +66,13 @@ static int map_x2apic_id(struct acpi_subtable_header *entry,
}
static int map_lsapic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
+ bool ignore_disabled)
{
struct acpi_madt_local_sapic *lsapic =
container_of(entry, struct acpi_madt_local_sapic, header);
- if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(lsapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration) {
@@ -87,12 +89,13 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
* Retrieve the ARM CPU physical identifier (MPIDR)
*/
static int map_gicc_mpidr(struct acpi_subtable_header *entry,
- int device_declaration,
[PATCH 1/5] x86, memhp, numa: Online memory-less nodes at boot time.
For now, x86 does not support memory-less node. A node without memory
will not be onlined, and the cpus on it will be mapped to the other
online nodes with memory in init_cpu_to_node(). The reason of doing this
is to ensure each cpu has mapped to a node with memory, so that it will
be able to allocate local memory for that cpu.
But we don't have to do it in this way.
In this series of patches, we are going to construct cpu <-> node mapping
for all possible cpus at boot time, which is a 1-1 mapping. It means the
cpu will be mapped to the node it belongs to, and will never be changed.
If a node has only cpus but no memory, the cpus on it will be mapped to
a memory-less node. And the memory-less node should be onlined.
This patch allocate pgdats for all memory-less nodes and online them at
boot time. As a result, when cpus on these memory-less nodes try to allocate
memory from local node, it will automatically fall back to the proper zones
in the zonelists.
Signed-off-by: Tang Chen
---
arch/x86/mm/numa.c | 27 +--
include/linux/mmzone.h | 1 +
mm/page_alloc.c| 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f65..010edb4 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -704,22 +704,19 @@ void __init x86_numa_init(void)
numa_init(dummy_numa_init);
}
-static __init int find_near_online_node(int node)
+static void __init init_memory_less_node(int nid)
{
- int n, val;
- int min_val = INT_MAX;
- int best_node = -1;
+ unsigned long zones_size[MAX_NR_ZONES] = {0};
+ unsigned long zholes_size[MAX_NR_ZONES] = {0};
- for_each_online_node(n) {
- val = node_distance(node, n);
+ /* Allocate and initialize node data. Memory-less node is now online.*/
+ alloc_node_data(nid);
+ free_area_init_node(nid, zones_size, 0, zholes_size);
- if (val < min_val) {
- min_val = val;
- best_node = n;
- }
- }
-
- return best_node;
+ /*
+* All zonelists will be built later in start_kernel() after per cpu
+* areas are initialized.
+*/
}
/*
@@ -748,8 +745,10 @@ void __init init_cpu_to_node(void)
if (node == NUMA_NO_NODE)
continue;
+
if (!node_online(node))
- node = find_near_online_node(node);
+ init_memory_less_node(node);
+
numa_set_node(cpu, node);
}
}
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e23a9e7..9c4d4d5 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -736,6 +736,7 @@ static inline bool is_dev_zone(const struct zone *zone)
extern struct mutex zonelists_mutex;
void build_all_zonelists(pg_data_t *pgdat, struct zone *zone);
+void build_zonelists(pg_data_t *pgdat);
void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx);
bool zone_watermark_ok(struct zone *z, unsigned int order,
unsigned long mark, int classzone_idx, int alloc_flags);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9d666df..15c0358 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4145,7 +4145,7 @@ static void set_zonelist_order(void)
current_zonelist_order = user_zonelist_order;
}
-static void build_zonelists(pg_data_t *pgdat)
+void build_zonelists(pg_data_t *pgdat)
{
int j, node, load;
enum zone_type i;
--
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 3/5] x86, acpi, cpu-hotplug: Introduce cpuid_to_apicid[] array to store persistent cpuid <-> apicid mapping.
From: Gu Zheng
This patch finishes step 2.
In this patch, we introduce a new static array named cpuid_to_apicid[],
which is large enough to store info for all possible cpus.
And then, we modify the cpuid calculation. In generic_processor_info(),
it simply finds the next unused cpuid. And it is also why the cpuid <-> nodeid
mapping changes with node hotplug.
After this patch, we find the next unused cpuid, map it to an apicid,
and store the mapping in cpuid_to_apicid[], so that cpuid <-> apicid
mapping will be persistent.
And finally we will use this array to make cpuid <-> nodeid persistent.
cpuid <-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/x86/include/asm/mpspec.h | 1 +
arch/x86/kernel/acpi/boot.c | 6 ++---
arch/x86/kernel/apic/apic.c | 61 ---
3 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index b07233b..db902d8 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -86,6 +86,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
#endif
int generic_processor_info(int apicid, int version);
+int __generic_processor_info(int apicid, int version, bool enabled);
#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_LOCAL_APIC)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e759076..0ce06ee 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -174,15 +174,13 @@ static int acpi_register_lapic(int id, u8 enabled)
return -EINVAL;
}
- if (!enabled) {
+ if (!enabled)
++disabled_cpus;
- return -EINVAL;
- }
if (boot_cpu_physical_apicid != -1U)
ver = apic_version[boot_cpu_physical_apicid];
- return generic_processor_info(id, ver);
+ return __generic_processor_info(id, ver, enabled);
}
static int __init
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 29915cf..d0a2f32 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1988,7 +1988,53 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
-static int __generic_processor_info(int apicid, int version, bool enabled)
+/*
+ * The number of allocated logical CPU IDs. Since logical CPU IDs are allocated
+ * contiguously, it equals to current allocated max logical CPU ID plus 1.
+ * All allocated CPU ID should be in [0, nr_logical_cpuidi), so the maximum of
+ * nr_logical_cpuids is nr_cpu_ids.
+ *
+ * NOTE: Reserve 0 for BSP.
+ */
+static int nr_logical_cpuids = 1;
+
+/*
+ * Used to store mapping between logical CPU IDs and APIC IDs.
+ */
+static int cpuid_to_apicid[] = {
+ [0 ... NR_CPUS - 1] = -1,
+};
+
+/*
+ * Should use this API to allocate logical CPU IDs to keep nr_logical_cpuids
+ * and cpuid_to_apicid[] synchronized.
+ */
+static int allocate_logical_cpuid(int apicid)
+{
+ int i;
+
+ /*
+* cpuid <-> apicid mapping is persistent, so when a cpu is up,
+* check if the kernel has allocated a cpuid for it.
+*/
+ for (i = 0; i < nr_logical_cpuids; i++) {
+ if (cpuid_to_apicid[i] == apicid)
+ return i;
+ }
+
+ /* Allocate a new cpuid. */
+ if (nr_logical_cpuids >= nr_cpu_ids) {
+ WARN_ONCE(1, "Only %d processors supported."
+"Processor %d/0x%x and the rest are ignored.\n",
+nr_cpu_ids - 1, nr_logical_cpuids, apicid);
+ return -1;
+ }
+
+ cpuid_to_apicid[nr_logical_cpuids] = apicid;
+ return nr_logical_cpuids++;
+}
+
+int __generic_processor_info(int apicid, int version, bool enabled)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
@@ -2069,8 +2115,17 @@ static int __generic_processor_info(int apicid, int
version, bool enabled)
* for BSP.
*/
cpu = 0;
- } else
- cpu = cpumask_next_zero(-1, cpu_present_mask);
+
+ /* Logical cpuid 0 is reserved for BSP. */
+ cpuid_to_apicid[0] = apicid;
+ } else {
+ cpu = allocate_logical_cpuid(apicid);
+ if (cpu < 0) {
+ if (enabled)
+ disabled_cpus++;
+ return -EINVAL;
+ }
+ }
/*
* Validate version
--
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
Re: [PATCH] [v4]Input: evdev - drop partial events after emptying the buffer
Hello Mr. Torokhov,
Could you please help to update about below patch ?
Thanks,
Aniroop Mathur
On Tue, Jan 5, 2016 at 3:26 AM, Aniroop Mathur wrote:
> This patch introduces concept to drop partial events in evdev handler
> itself after emptying the buffer which are dropped by all evdev
> clients in userspace after SYN_DROPPED occurs and this in turn reduces
> evdev client reading requests plus saves memory space filled by partial
> events in evdev handler buffer.
> Also, this patch prevents dropping of full packet by evdev client after
> SYN_DROPPED occurs in case last stored event was SYN_REPORT.
> (like after clock change request)
>
> --
> Please ignore v3.
>
> Signed-off-by: Aniroop Mathur
> ---
> drivers/input/evdev.c | 53
> ++-
> 1 file changed, 40 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index e9ae3d5..15b6eb2 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -58,6 +58,7 @@ struct evdev_client {
> struct list_head node;
> unsigned int clk_type;
> bool revoked;
> + bool drop_pevent; /* specifies if partial events need to be dropped */
> unsigned long *evmasks[EV_CNT];
> unsigned int bufsize;
> struct input_event buffer[];
> @@ -156,7 +157,12 @@ static void __evdev_flush_queue(struct evdev_client
> *client, unsigned int type)
> static void __evdev_queue_syn_dropped(struct evdev_client *client)
> {
> struct input_event ev;
> + struct input_event *prev_ev;
> ktime_t time;
> + unsigned int mask = client->bufsize - 1;
> +
> + /* Store previous event */
> + prev_ev = >buffer[(client->head - 1) & mask];
>
> time = client->clk_type == EV_CLK_REAL ?
> ktime_get_real() :
> @@ -170,13 +176,33 @@ static void __evdev_queue_syn_dropped(struct
> evdev_client *client)
> ev.value = 0;
>
> client->buffer[client->head++] = ev;
> - client->head &= client->bufsize - 1;
> + client->head &= mask;
>
> if (unlikely(client->head == client->tail)) {
> /* drop queue but keep our SYN_DROPPED event */
> - client->tail = (client->head - 1) & (client->bufsize - 1);
> + client->tail = (client->head - 1) & mask;
> client->packet_head = client->tail;
> }
> +
> + /*
> +* If last packet is NOT fully stored, set drop_pevent to true to
> +* ignore partial events and if last packet is fully stored, queue
> +* SYN_REPORT so that clients would not ignore next full packet.
> +*/
> + if (prev_ev->type != EV_SYN && prev_ev->code != SYN_REPORT) {
> + client->drop_pevent = true;
> + } else if (prev_ev->type == EV_SYN && prev_ev->code == SYN_REPORT) {
> + prev_ev->time = ev.time;
> + client->buffer[client->head++] = *prev_ev;
> + client->head &= mask;
> + client->packet_head = client->head;
> +
> + /* drop queue but keep our SYN_DROPPED & SYN_REPORT event */
> + if (unlikely(client->head == client->tail)) {
> + client->tail = (client->head - 2) & mask;
> + client->packet_head = client->tail;
> + }
> + }
> }
>
> static void evdev_queue_syn_dropped(struct evdev_client *client)
> @@ -235,18 +261,8 @@ static void __pass_event(struct evdev_client *client,
> client->head &= client->bufsize - 1;
>
> if (unlikely(client->head == client->tail)) {
> - /*
> -* This effectively "drops" all unconsumed events, leaving
> -* EV_SYN/SYN_DROPPED plus the newest event in the queue.
> -*/
> - client->tail = (client->head - 2) & (client->bufsize - 1);
> -
> - client->buffer[client->tail].time = event->time;
> - client->buffer[client->tail].type = EV_SYN;
> - client->buffer[client->tail].code = SYN_DROPPED;
> - client->buffer[client->tail].value = 0;
> -
> client->packet_head = client->tail;
> + __evdev_queue_syn_dropped(client);
> }
>
> if (event->type == EV_SYN && event->code == SYN_REPORT) {
> @@ -284,6 +300,17 @@ static void evdev_pass_values(struct evdev_client
> *client,
> wakeup = true;
> }
>
> + /*
> +* drop partial events of last packet but queue SYN_REPORT
> +* so that clients would not ignore extra full packet.
> +*/
> + if (client->drop_pevent) {
> + if (v->type == EV_SYN && v->code == SYN_REPORT)
> + client->drop_pevent = false;
> + else
> + continue;
> + }
> +
>
[PATCH RESEND] perf tools: bug fix, an error of parsing 'man..*' config variable.
To add new man viewer, configs like 'man..cmd',
'man..path' can be set into config file (~/.perfconfig).
But parsing config file is stopped because the config variable
contains '.' character i.e.
If setting 'man.xman.cmd' into config file,
[man]
gman.cmd = gman
when launching perf an error message is printed like below.
Fatal: bad config file line 11 in /home/taeung/.perfconfig
So modify iskeychar() function to decide '.' character
as key character parsing config file.
Cc: Namhyung Kim
Cc: Jiri Olsa
Signed-off-by: Taeung Song
---
tools/perf/util/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index d3e12e3..3c01ced 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -122,7 +122,7 @@ static char *parse_value(void)
static inline int iskeychar(int c)
{
- return isalnum(c) || c == '-' || c == '_';
+ return isalnum(c) || c == '-' || c == '_' || c == '.';
}
static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
--
2.5.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 v5 5/5] misc: eeprom_93xx46: Add support for a GPIO 'select' line.
This commit adds support to the eeprom_93x46 driver allowing a GPIO line
to function as a 'select' or 'enable' signal prior to accessing the
EEPROM.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
Reviewed-by: Vladimir Zapolskiy
---
drivers/misc/eeprom/eeprom_93xx46.c | 35 +++
include/linux/eeprom_93xx46.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index d50bc17..d28fac2 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -10,11 +10,13 @@
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -343,6 +345,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device
*dev,
}
static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
+static void select_assert(void *context)
+{
+ struct eeprom_93xx46_dev *edev = context;
+
+ gpiod_set_value_cansleep(edev->pdata->select, 1);
+}
+
+static void select_deassert(void *context)
+{
+ struct eeprom_93xx46_dev *edev = context;
+
+ gpiod_set_value_cansleep(edev->pdata->select, 0);
+}
+
static const struct of_device_id eeprom_93xx46_of_table[] = {
{ .compatible = "eeprom-93xx46", },
{ .compatible = "atmel,at93c46d", .data = _at93c46d_data, },
@@ -357,6 +373,8 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
struct device_node *np = spi->dev.of_node;
struct eeprom_93xx46_platform_data *pd;
u32 tmp;
+ int gpio;
+ enum of_gpio_flags of_flags;
int ret;
pd = devm_kzalloc(>dev, sizeof(*pd), GFP_KERNEL);
@@ -381,6 +399,23 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
if (of_property_read_bool(np, "read-only"))
pd->flags |= EE_READONLY;
+ gpio = of_get_named_gpio_flags(np, "select-gpios", 0, _flags);
+ if (gpio_is_valid(gpio)) {
+ unsigned long flags =
+ of_flags == OF_GPIO_ACTIVE_LOW ? GPIOF_ACTIVE_LOW : 0;
+
+ ret = devm_gpio_request_one(>dev, gpio, flags,
+ "eeprom_93xx46_select");
+ if (ret)
+ return ret;
+
+ pd->select = gpio_to_desc(gpio);
+ pd->prepare = select_assert;
+ pd->finish = select_deassert;
+
+ gpiod_direction_output(pd->select, 0);
+ }
+
if (of_id->data) {
const struct eeprom_93xx46_devtype_data *data = of_id->data;
diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
index 92fa4c3..885f587 100644
--- a/include/linux/eeprom_93xx46.h
+++ b/include/linux/eeprom_93xx46.h
@@ -3,6 +3,8 @@
* platform description for 93xx46 EEPROMs.
*/
+struct gpio_desc;
+
struct eeprom_93xx46_platform_data {
unsigned char flags;
#define EE_ADDR8 0x01/* 8 bit addr. cfg */
@@ -21,4 +23,5 @@ struct eeprom_93xx46_platform_data {
*/
void (*prepare)(void *);
void (*finish)(void *);
+ struct gpio_desc *select;
};
--
2.4.10
--
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 v5 4/5] misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.
Atmel devices in this family have some quirks not found in other similar
chips - they do not support a sequential read of the entire EEPROM
contents, and the control word sent at the start of each operation
varies in bit length.
This commit adds quirk support to the driver and modifies the read
implementation to support non-sequential reads for consistency with
other misc/eeprom drivers.
Tested on a custom Freescale VF610-based platform, with an AT93C46D
device attached via dspi2. The spi-gpio driver was used to allow the
necessary non-byte-sized transfers.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
Reviewed-by: Vladimir Zapolskiy
---
drivers/misc/eeprom/eeprom_93xx46.c | 126 ++--
include/linux/eeprom_93xx46.h | 6 ++
2 files changed, 97 insertions(+), 35 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index cc27e11..d50bc17 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -27,6 +27,15 @@
#define ADDR_ERAL 0x20
#define ADDR_EWEN 0x30
+struct eeprom_93xx46_devtype_data {
+ unsigned int quirks;
+};
+
+static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
+ .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
+ EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
+};
+
struct eeprom_93xx46_dev {
struct spi_device *spi;
struct eeprom_93xx46_platform_data *pdata;
@@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
int addrlen;
};
+static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
+{
+ return edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ;
+}
+
+static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev *edev)
+{
+ return edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH;
+}
+
static ssize_t
eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
@@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
*kobj,
{
struct eeprom_93xx46_dev *edev;
struct device *dev;
- struct spi_message m;
- struct spi_transfer t[2];
- int bits, ret;
- u16 cmd_addr;
+ ssize_t ret = 0;
dev = container_of(kobj, struct device, kobj);
edev = dev_get_drvdata(dev);
- cmd_addr = OP_READ << edev->addrlen;
+ mutex_lock(>lock);
- if (edev->addrlen == 7) {
- cmd_addr |= off & 0x7f;
- bits = 10;
- } else {
- cmd_addr |= (off >> 1) & 0x3f;
- bits = 9;
- }
+ if (edev->pdata->prepare)
+ edev->pdata->prepare(edev);
- dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
- cmd_addr, edev->spi->max_speed_hz);
+ while (count) {
+ struct spi_message m;
+ struct spi_transfer t[2] = { { 0 } };
+ u16 cmd_addr = OP_READ << edev->addrlen;
+ size_t nbytes = count;
+ int bits;
+ int err;
+
+ if (edev->addrlen == 7) {
+ cmd_addr |= off & 0x7f;
+ bits = 10;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 1;
+ } else {
+ cmd_addr |= (off >> 1) & 0x3f;
+ bits = 9;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 2;
+ }
- spi_message_init();
- memset(t, 0, sizeof(t));
+ dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
+ cmd_addr, edev->spi->max_speed_hz);
- t[0].tx_buf = (char *)_addr;
- t[0].len = 2;
- t[0].bits_per_word = bits;
- spi_message_add_tail([0], );
+ spi_message_init();
- t[1].rx_buf = buf;
- t[1].len = count;
- t[1].bits_per_word = 8;
- spi_message_add_tail([1], );
+ t[0].tx_buf = (char *)_addr;
+ t[0].len = 2;
+ t[0].bits_per_word = bits;
+ spi_message_add_tail([0], );
- mutex_lock(>lock);
+ t[1].rx_buf = buf;
+ t[1].len = count;
+ t[1].bits_per_word = 8;
+ spi_message_add_tail([1], );
- if (edev->pdata->prepare)
- edev->pdata->prepare(edev);
+ err = spi_sync(edev->spi, );
+ /* have to wait at least Tcsl ns */
+ ndelay(250);
- ret = spi_sync(edev->spi, );
- /* have to wait at least Tcsl ns */
- ndelay(250);
- if (ret) {
- dev_err(>spi->dev, "read %zu bytes at %d: err. %d\n",
- count, (int)off, ret);
+ if (err) {
+ dev_err(>spi->dev, "read %zu bytes at %d: err.
%d\n",
+
[PATCH v5 3/5] misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.
This commit implements bindings in the eeprom_93xx46 driver allowing
device word size and read-only attributes to be specified via
devicetree.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
Reviewed-by: Vladimir Zapolskiy
---
drivers/misc/eeprom/eeprom_93xx46.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index e1bf0a5..cc27e11 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -294,12 +296,58 @@ static ssize_t eeprom_93xx46_store_erase(struct device
*dev,
}
static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
+static const struct of_device_id eeprom_93xx46_of_table[] = {
+ { .compatible = "eeprom-93xx46", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+
+static int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+ struct device_node *np = spi->dev.of_node;
+ struct eeprom_93xx46_platform_data *pd;
+ u32 tmp;
+ int ret;
+
+ pd = devm_kzalloc(>dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+
+ ret = of_property_read_u32(np, "data-size", );
+ if (ret < 0) {
+ dev_err(>dev, "data-size property not found\n");
+ return ret;
+ }
+
+ if (tmp == 8) {
+ pd->flags |= EE_ADDR8;
+ } else if (tmp == 16) {
+ pd->flags |= EE_ADDR16;
+ } else {
+ dev_err(>dev, "invalid data-size (%d)\n", tmp);
+ return -EINVAL;
+ }
+
+ if (of_property_read_bool(np, "read-only"))
+ pd->flags |= EE_READONLY;
+
+ spi->dev.platform_data = pd;
+
+ return 0;
+}
+
static int eeprom_93xx46_probe(struct spi_device *spi)
{
struct eeprom_93xx46_platform_data *pd;
struct eeprom_93xx46_dev *edev;
int err;
+ if (spi->dev.of_node) {
+ err = eeprom_93xx46_probe_dt(spi);
+ if (err < 0)
+ return err;
+ }
+
pd = spi->dev.platform_data;
if (!pd) {
dev_err(>dev, "missing platform data\n");
@@ -370,6 +418,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
static struct spi_driver eeprom_93xx46_driver = {
.driver = {
.name = "93xx46",
+ .of_match_table = of_match_ptr(eeprom_93xx46_of_table),
},
.probe = eeprom_93xx46_probe,
.remove = eeprom_93xx46_remove,
--
2.4.10
--
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 v5 1/5] misc: eeprom_93xx46: Fix 16-bit read and write accesses.
Compatible at93xx46 devices from both Microchip and Atmel expect a
word-based address, regardless of whether the device is strapped for 8-
or 16-bit operation. However, the offset parameter passed in when
reading or writing at a specific location is always specified in terms
of bytes.
This commit fixes 16-bit read and write accesses by shifting the offset
parameter to account for this difference between a byte offset and a
word-based address.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
---
drivers/misc/eeprom/eeprom_93xx46.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index ff63f05..e1bf0a5 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -54,7 +54,7 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
*kobj,
cmd_addr |= off & 0x7f;
bits = 10;
} else {
- cmd_addr |= off & 0x3f;
+ cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
}
@@ -155,7 +155,7 @@ eeprom_93xx46_write_word(struct eeprom_93xx46_dev *edev,
bits = 10;
data_len = 1;
} else {
- cmd_addr |= off & 0x3f;
+ cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
data_len = 2;
}
--
2.4.10
--
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 v5 2/5] Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver.
This commit documents bindings to be added to the eeprom_93xx46 driver
which will allow:
- Device word size and read-only attributes to be specified.
- A device-specific compatible string for use with Atmel AT93C46D
EEPROMs.
- Specifying a GPIO line to function as a 'select' or 'enable' signal
prior to accessing the EEPROM.
Signed-off-by: Cory Tusar
Acked-by: Rob Herring
Tested-by: Chris Healy
---
.../devicetree/bindings/misc/eeprom-93xx46.txt | 25 ++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
new file mode 100644
index 000..a8ebb46
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -0,0 +1,25 @@
+EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
+
+Required properties:
+- compatible : shall be one of:
+"atmel,at93c46d"
+"eeprom-93xx46"
+- data-size : number of data bits per word (either 8 or 16)
+
+Optional properties:
+- read-only : parameter-less property which disables writes to the EEPROM
+- select-gpios : if present, specifies the GPIO that will be asserted prior to
+ each access to the EEPROM (e.g. for SPI bus multiplexing)
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+
+Example:
+ eeprom@0 {
+ compatible = "eeprom-93xx46";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ spi-cs-high;
+ data-size = <8>;
+ select-gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
--
2.4.10
--
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 v5 0/5] Devicetree support for misc/eeprom/eeprom_93xx46.
This series of patches adds an initial set of devicetree bindings to the eeprom_93xx46 driver which mirror the configuration options previously available as a platform device. These bindings are then extended to include support for specific Atmel devices in this family and also to support GPIO-based selection of the device (e.g. for use with an SPI bus mux). Additionally, an address aliasing issue with 16-bit read and write accesses in the eeprom_93xx46 driver discovered during testing is fixed. Changes since v4: - Only forward-declare 'struct gpio_desc' in eeprom_93xx46.h. - Reviewed-by: Vladimir Zapolskiy Changes since v3: - Tested-by: Chris Healy ...on a separate i.MX51 platform with Microchip 93LC46A EEPROM. Changes since v2: - Changed node name to 'eeprom' in DT bindings example. - Simplified several bits of return logic. - Removed #ifdef CONFIG_OF. - Allow compiler to handle promotion to bool return values. - Reworked GPIO handling to use gpiod_* functions throughout (and fixed an oversight where GPIO flags were being ignored). Changes since v1: - Consolidated all Documentation/devictree additions into a single patch. - Clarified compatible string shall be only one of the supported values. - Renamed the 'select-gpio' binding to 'select-gpios'. Cory Tusar (5): misc: eeprom_93xx46: Fix 16-bit read and write accesses. Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver. misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings. misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device. misc: eeprom_93xx46: Add support for a GPIO 'select' line. .../devicetree/bindings/misc/eeprom-93xx46.txt | 25 +++ drivers/misc/eeprom/eeprom_93xx46.c| 212 + include/linux/eeprom_93xx46.h | 9 + 3 files changed, 210 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt -- 2.4.10 -- 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] mm: mempolicy: skip non-migratable VMAs when setting MPOL_MF_LAZY
MPOL_MF_LAZY is not visible from userspace since 'commit a720094ded8c
("mm: mempolicy: Hide MPOL_NOOP and MPOL_MF_LAZY from userspace for now")'
, but it should still skip non-migratable VMAs such as VM_IO, VM_PFNMAP,
and VM_HUGETLB VMAs, and avoid useless overhead of minor faults.
Signed-off-by: Liang Chen
Signed-off-by: Gavin Guo
---
Changes since v2:
- Add more description into the changelog
We have been evaluating the enablement of MPOL_MF_LAZY again, and found
this issue. And we decided to push this patch upstream no matter if we
finally determine to propose re-enablement of MPOL_MF_LAZY or not. Since
it can be a potential problem even if MPOL_MF_LAZY is not enabled this
time.
---
mm/mempolicy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 87a1779..436ff411 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -610,7 +610,8 @@ static int queue_pages_test_walk(unsigned long start,
unsigned long end,
if (flags & MPOL_MF_LAZY) {
/* Similar to task_numa_work, skip inaccessible VMAs */
- if (vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))
+ if (vma_migratable(vma) &&
+ vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))
change_prot_numa(vma, start, endvma);
return 1;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trace: correct start_index in find_next
On Thu, 07 Jan 2016 10:56:56 +0800 "Zhang, Yanmin" wrote: > How is this patch? It fixes a kernel panic. > Linus already pulled it. It's also marked for stable. See commit: f36d1be2930ede0a1947686e1126ffda5d5ee1bb in Linus's tree. I renamed the subject slightly to: "tracing: Fix setting of start_index in find_next()" -- Steve -- 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] trace: correct start_index in find_next
On 2016/1/7 11:50, Steven Rostedt wrote: > On Thu, 07 Jan 2016 10:56:56 +0800 > "Zhang, Yanmin" wrote: > >> How is this patch? It fixes a kernel panic. >> > Linus already pulled it. It's also marked for stable. See commit: > f36d1be2930ede0a1947686e1126ffda5d5ee1bb in Linus's tree. > > I renamed the subject slightly to: > > "tracing: Fix setting of start_index in find_next()" > Thanks as usual. -- 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 v1 3/3] ARM64 LPC: update binding doc
在 2016/1/6 21:36, Rongrong Zou 写道:
在 2016/1/5 20:19, Arnd Bergmann 写道:
On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:
在 2016/1/5 0:34, Arnd Bergmann 写道:
On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:
在 2016/1/4 19:13, Arnd Bergmann 写道:
On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:
在 2015/12/31 23:00, Rongrong Zou 写道:
Ranges property can set empty, but this means 1:1 translation. the I/O
port range is translated to MMIO address 0x0001 to
0x0001 0004, it looks wrong else. I wonder if anyone get legacy
I/O port resource from dts.
As I said, nothing should really require the ranges property here, unless
you have a valid IORESOURCE_MEM translation. The code that requires
the ranges to be present is wrong.
I think the openfirmware(DT) do not support for those unmapped I/O ports,
because I
must get resource by calling of_address_to_resource(), which have to call
pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
better idea for this now. Maybe liviu can give me some opinions.
I think on x86 it works (or used to work, few people use open firmware on
x86 these days, and it may be broken), and the pci_address_to_pio() call
behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
memory mapped I/O addresses, they have their own way of accessing them
just like your platform.
The big problem is:
The return value of_translate_address can be only an cpu addr,
there is no map from cpuaddr to I/O port in x86 as you said,
we still can't get io resource.
static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
{
...
taddr = of_translate_address(dev, addrp);
...
}
/**
* of_address_to_resource - Translate device tree address and return as
resource
*
* Note that if your address is a PIO address, the conversion will fail if
* the physical address can't be internally converted to an IO token with
* pci_address_to_pio(), that is because it's either called to early or it
* can't be matched to any host bridge IO space
*/
int of_address_to_resource(struct device_node *dev, int index,
struct resource *r)
The problem here seems to be that the code assumes that either the I/O ports
are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
it because now we can have the combination of the two.
I am considering the following solution:
Adding unmapped isa io functions in
drivers/of/address.c,
static LIST_HEAD(legacy_io_range_list);
int isa_register_io_range(phys_addr_t addr, resource_size_t size);
/* before I call isa(LPC) bus driver, the input I/O port must be translated to
phys_addr_t
(the least 16bit means port addr on bus, the second 16bit means bus id)*/
phys_addr_t isa_pio_to_bus_addr(unsigned long pio);
/* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
unsigned long isa_bus_addr_to_pio(phys_addr_t address);
drivers/bus/lpc.c
lpc_bus_probe()
{
isa_register_io_range(phys_addr_t addr, resource_size_t size);
}
inb(unsigned long port)
{
unsigned short bus;
phys_addr_t addr;
/*hit isa port range*/
if(addr = isa_pio_to_bus_addr(port))
{
bus = (addr >> 16) & 0x;
call lpc driver with addr;
return lpc_read_byte(bus, addr);
}
else /*not hit*/
{
return readb(PCI_IOBASE + port);
}
}
For ipmi driver, I can get I/O port resource by DMI rather than dts.
No, the ipmi driver uses the resource that belongs to the platform
device already, you can't rely on DMI data to be present there.
Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
openfirmware and a few other), I think we just use one of them, not all of them.
It depend on vendor's hardware solution actually.
I don't think we should mix multiple methods here: if the bus is described
in DT, all its children should be there as well. Otherwise you get into problems
e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
for one or more of them have an offset to the bus specific addresses.
The bus probe code decides what the Linux I/O port numbers are, but DMI
and other methods have no idea of the mapping. As long as there is only
one instance, using the first 0x1000 addresses with a 1:1 mapping saves
us a bit of trouble, but I'd be worried about relying on that assumption
too much.
Arnd
.
--
Thanks,
Rongrong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/5] doc: bindings: Document for hi655x regulator driver
On 2016/1/5 23:47, Mark Brown wrote: > On Mon, Jan 04, 2016 at 08:27:49PM +0800, Chen Feng wrote: >> Add Document for hi655x pmic regulator driver > > As indicated in the driver review this seems to be a bit of an unusual > binding that I think needs reworking, also it needs a bit more detail - > for example, listing which regulator names are valid. > > Please also use subject lines reflecting the normal style for the > subsystem. > OK,Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/5] regulator: add regulator driver of hi655x pmic
On 2016/1/5 23:44, Mark Brown wrote:
> On Mon, Jan 04, 2016 at 08:27:51PM +0800, Chen Feng wrote:
>
>> +/*LDO 2 & LDO 14*/
>
> Please use the normal kernel coding style for comments, I'm surprised
> checkpatch didn't warn you about this.
>
ok,thanks!
>> +static const unsigned int ldo2_voltages[] = {
>> +250, 260, 270, 280,
>> +290, 300, 310, 320,
>
> This looks like a linear range from 2.5V in steps of 100mV? A linear
> range is better than a table since values can be mapped directly without
> having to scan a table.
>
Agree with you.
>> +/*LDO7 & LDO10*/
>> +static const unsigned int ldo7_voltages[] = {
>> +180, 185, 285, 290,
>> +300, 310, 320, 330,
>
> This is the sort of thing a voltage table is for where the voltages
> aren't evenly spaced and don't map onto a formula.
>
>> +static const struct of_device_id of_hi655x_regulator_match_tbl[] = {
>> +{
>> +.compatible = "hisilicon,hi655x-regulator",
>> +},
>> +};
>> +MODULE_DEVICE_TABLE(of, of_hi655x_regulator_match_tbl);
>
> A couple of problems here. One is that the compatible strings should be
> for specific devices, not use a wildcard. The other is that since this
> is part of a PMIC and we already have a compatible string for the PMIC
> so this is really just a set of properties for that device rather than a
> totally separate device - we're not achieving any real reuse over
> multiple devices or anything.
ok.
>
>> +for (i = 0; i < ARRAY_SIZE(regulators); i++) {
>> +if (!of_node_cmp(np->name, regulators[i].rdesc.name))
>> +break;
>> +}
>> +
>> +if (i == ARRAY_SIZE(regulators)) {
>> +dev_err(dev, "error regulator %s int dts\n", np->name);
>> +return -ENODEV;
>> +}
>> +
>> +regulator = [i];
>> +init_data = of_get_regulator_init_data(dev, np,
>> + >rdesc);
>> +if (!init_data)
>> +return -EINVAL;
>
> Don't open code this, use the standard support with of_match and
> regulators_node.
>
>> +config.dev = dev;
>> +config.init_data = init_data;
>> +config.driver_data = regulator;
>> +config.regmap = pmic->regmap;
>> +config.of_node = pdev->dev.of_node;
>
>> +rdev = devm_regulator_register(dev, >rdesc,
>> + );
>> +if (IS_ERR(rdev))
>> +return PTR_ERR(rdev);
>
> Though this looks like it's trying to have a device per regulator which
> is an unusual pattern and if we are doing that then relying on the node
> name to figure out which device this is a bit broken.
>
ok, I will fix the patch and resend 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 V2 0/3] Change notes of V2
> From: Xiangliang Yu : > > Main changes in V2: > > 1. Fixed compiler warning; > > 2. Add marcro argument of ndev in NTB_READ_REG/NTB_WRITE_REG; 3. > Add > > notes for flush and wakeup interfaces; > > > > Xiangliang Yu (3): > > NTB: Add AMD PCI-Express NTB driver > > NTB: Add AMD NTB support in Kconfig and Makefile > > NTB: Add flush_req and wakeup interface > > Could you re-spin these patches as: > > Patch 1: > Only the parts of the driver that fit the current NTB APIs. > > Patch 2: > The new flush_req API, and the related code in the AMD driver. > > Patch 3: > The new wakeup API, and related code in the AMD driver. > Ok. > In particular, I think we need feedback on #3 from PCI and power > management maintainers. I don't get your concern. I think we can add device attribute file to let application to trigger wakeup function, then NTB hardware will do the rest. NTB driver just need to implement suspend/resume interface of PCI PM. Add one more thing, do you think NTB should support runtime power management? > > When making #1, please make sure that the patch stands on its own, without > any of the code related to #2 or #3 in #1. Do put the makefile and kconfig > changes in #1. Ok.
Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring
On Wed, 2016-01-06 at 21:13 -0500, Mimi Zohar wrote:
> On Thu, 2016-01-07 at 00:34 +, David Howells wrote:
> > David Howells wrote:
> >
> > > Partially revert commit 41c89b64d7184a780f12f2cccdabe65cb2408893:
> > >
> > > Author: Petko Manolov
> > > Date: Wed Dec 2 17:47:55 2015 +0200
> > > IMA: create machine owner and blacklist keyrings
> > >
> > > The problem is that prep->trusted is a simple boolean and the additional
> > > x509_validate_trust() call doesn't therefore distinguish levels of
> > > trustedness, but is just OR'd with the result of validation against the
> > > system trusted keyring.
> > >
> > > However, setting the trusted flag means that this key may be added to
> > > *any*
> > > trusted-only keyring - including the system trusted keyring.
>
> Hm, I'm not able to add a key to the system keyring that is signed by a
> key on either the system or the IMA MOK keyrings. The system keyring
> seems to be "locked". A key that is signed by either a key on the
> system or the IMA MOK keyring can be added to the IMA keyring.
>
> keyctl show %keyring:.system_keyring
> Keyring
> 973688077 ---lswrv 0 0 keyring: .system_keyring
>
> evmctl import m1-cert-signed.der 973688077
> add_key failed
> errno: Permission denied (13)
The "KEY_USR_WRITE" permission is required in order to add keys to a
keyring. This permission is specified for the IMA keyring, but not for
the system keyring, which explains why I could add a key to the IMA
keyring, but not the system keyring.
system_trusted_keyring =
keyring_alloc(".system_keyring",
KUIDT_INIT(0), KGIDT_INIT(0),
current_cred(),
((KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ |
KEY_USR_SEARCH),
KEY_ALLOC_NOT_IN_QUOTA, NULL);
keyring[id] = keyring_alloc(keyring_name[id], KUIDT_INIT(0),
KGIDT_INIT(0), cred,
((KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ |
KEY_USR_WRITE | KEY_USR_SEARCH),
KEY_ALLOC_NOT_IN_QUOTA, NULL);
The only keys added to the system keyring should be those listed in the
Kconfig SYSTEM_TRUSTED_KEYS specified file.
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 4/4] perf/x86/amd/power: Add AMD accumulated power reporting mechanism
Hi Huang,
[auto build test ERROR on bp/for-next]
[also build test ERROR on v4.4-rc8 next-20160106]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Huang-Rui/perf-x86-power-Introduce-AMD-accumlated-power-reporting-mechanism/20160107-103309
base: https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp for-next
config: i386-randconfig-s1-201601 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kobject.h:21:0,
from include/linux/module.h:17,
from arch/x86/kernel/cpu/perf_event_amd_power.c:13:
>> arch/x86/kernel/cpu/perf_event.h:663:31: error: 'events_sysfs_show'
>> undeclared here (not in a function)
.attr = __ATTR(_name, 0444, events_sysfs_show, NULL), \
^
include/linux/sysfs.h:103:10: note: in definition of macro '__ATTR'
.show = _show, \
^
>> arch/x86/kernel/cpu/perf_event_amd_power.c:244:1: note: in expansion of
>> macro 'EVENT_ATTR_STR'
EVENT_ATTR_STR(power-pkg, power_pkg, "event=0x01");
^
vim +/events_sysfs_show +663 arch/x86/kernel/cpu/perf_event.h
3a54aaa0 Stephane Eranian 2013-01-24 657 .id =
PERF_COUNT_HW_##_id, \
3a54aaa0 Stephane Eranian 2013-01-24 658 .event_str = NULL,
\
3a54aaa0 Stephane Eranian 2013-01-24 659 };
3a54aaa0 Stephane Eranian 2013-01-24 660
3a54aaa0 Stephane Eranian 2013-01-24 661 #define EVENT_ATTR_STR(_name, v,
str)\
3a54aaa0 Stephane Eranian 2013-01-24 662 static struct perf_pmu_events_attr
event_attr_##v = {\
3a54aaa0 Stephane Eranian 2013-01-24 @663 .attr = __ATTR(_name,
0444, events_sysfs_show, NULL), \
3a54aaa0 Stephane Eranian 2013-01-24 664 .id = 0,
\
3a54aaa0 Stephane Eranian 2013-01-24 665 .event_str = str,
\
3a54aaa0 Stephane Eranian 2013-01-24 666 };
:: The code at line 663 was first introduced by commit
:: 3a54aaa0a3ddb2cf2ec1b94a94024e9a8a8af962 perf/x86: Improve sysfs event
mapping with event string
:: TO: Stephane Eranian
:: CC: Arnaldo Carvalho de Melo
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 00/35 v2] separate operations from flags in the bio/request structs
On Wed, Jan 06, 2016 at 08:40:09PM -0500, Martin K. Petersen wrote: > > "Mike" == mchristi writes: > > Mike> The following patches begin to cleanup the request->cmd_flags and > bio-> bi_rw mess. We currently use cmd_flags to specify the operation, > Mike> attributes and state of the request. For bi_rw we use it for > Mike> similar info and also the priority but then also have another > Mike> bi_flags field for state. At some point, we abused them so much we > Mike> just made cmd_flags 64 bits, so we could add more. > > Mike> The following patches seperate the operation (read, write discard, > Mike> flush, etc) from cmd_flags/bi_rw. > > Mike> This patchset was made against linux-next from today Jan 5 2016. > Mike> (git tag next-20160105). > > Very nice work. Thanks for doing this! > > I think it's a much needed cleanup. I focused mainly on the core block, > discard, write same and sd.c pieces and everything looks sensible to me. > > I wonder what the best approach is to move a patch set with this many > stakeholders forward? Set a "speak now or forever hold your peace" > review deadline? I say just ask Linus to pull it immediately after the next merge window closes 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 13/35] xfs: set bi_op to REQ_OP
On Tue, Jan 05, 2016 at 02:53:16PM -0600, mchri...@redhat.com wrote: > From: Mike Christie > > This patch has xfs set the bio bi_op to a REQ_OP, and > rq_flag_bits to bi_rw. > > Note: > I have run xfs tests on these btrfs patches. There were some failures > with and without the patches. I have not had time to track down why > xfstest fails without the patches. > > Signed-off-by: Mike Christie > --- > fs/xfs/xfs_aops.c | 3 ++- > fs/xfs/xfs_buf.c | 27 +++ > 2 files changed, 17 insertions(+), 13 deletions(-) Not sure which patches your note is refering to here. The XFS change here looks fine. Acked-by: Dave Chinner -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 v4 0/5] mtd: nand: properly handle bitflips in erased pages
Hi Boris, On Wed, Dec 30, 2015 at 08:32:02PM +0100, Boris Brezillon wrote: > Hi, > > This patch series aims at providing a common logic to check for bitflips > in erased pages. > > Currently each driver is implementing its own logic to check for bitflips > in erased pages. Not only this create code duplication, but most of these > implementations are incorrect. > Here are a few aspects that are often left aside in those implementations: > 1/ they do not check OOB bytes when checking for the ff pattern, which >means they can consider a page as empty while the MTD user actually >wanted to write almost ff with a few bits to zero > 2/ they check for the ff pattern on the whole page, while ECC actually >works on smaller chunks (usually 512 or 1024 bytes chunks) > 3/ they use random bitflip thresholds to decide whether a page/chunk is >erased or not. IMO this threshold should be set to ECC strength (or >at least something correlated to this parameter) > > The approach taken in this series is to provide two helper functions to > check for bitflips in erased pages. Each driver that needs to check for > such cases can then call the nand_check_erased_ecc_chunk() function, and > rely on the common logic to decide whether a page is erased or not. > > While Brian suggested a few times to make this detection automatic for > all drivers that set a specific flag (NAND_CHECK_ERASED_BITFLIPS?), here > is a few reasons I think this is not such a good idea: > 1/ some (a lot of) drivers do not properly implement the raw access >functions, and since we need to check for raw data and OOB bytes this >makes the automatic detection unusable for most drivers unless they >decide to correctly implement those methods (which would be a good >thing BTW). > 2/ as a I said earlier, this check should be made at the ECC chunk level >and not at the page level. This spots two problems: some (a lot of) >drivers do not properly specify the ecc layout information, and even >if the ecc layout is correctly defined, there is no way to attach ECC >bytes to a specific ECC chunk. > 3/ the last aspect is the perf penalty incured by this test. Automatically >doing that at the NAND core level implies reading the whole page again >in raw mode, while with the helper function approach, drivers supporting >access at the ECC chunk level can read only the faulty chunk in raw >mode. > > Regarding the bitflips threshold at which an erased pages is considered as > faulty, I have assigned it to ECC strength. As mentioned by Andrea, using > ECC strength might cause some trouble, because if you already have some > bitflips in an erased page, programming it might generate even more of > them. > In the other hand, shouldn't that be checked after (or before) programming > a page. I mean, UBI is already capable of detecting pages which are over > the configured bitflips_threshold and move data around when it detects > such pages. > If we check data after writing a page we wouldn't have to bother about > setting a weaker value for the "bitflips in erased page" case. > Another thing in favor of the ECC strength value for this "bitflips in > erased page" threshold value: if the ECC engine is generating 0xff ECC > bytes when the page is empty, then it will be able to fix ECC strength > bitflips without complaining, so why should we use different value when > we detect bitflips using the pattern match approach? Thanks for the full description here. I agree with most, if not all of this. > Best Regards, > > Boris > > Changes since v3: > - drop already applied patches > - make the generic "bitflips in erased pages" check as an opt-in flag > - split driver changes to ease review > - addressed Brian's comments > > Changes since v2: > - improve nand_check_erased_buf() implementation > - keep nand_check_erased_buf() private to nand_base.c > - patch existing ecc.correct() implementations to return consistent error > codes > - make the 'erased check' optional > - remove some custom implementations of the 'erased check' > > Changes since v1: > - fix the nand_check_erased_buf() function > - mark the bitflips > bitflips_threshold condition as unlikely > - add missing memsets in nand_check_erased_ecc_chunk() > > > Boris Brezillon (5): > mtd: nand: return consistent error codes in ecc.correct() > implementations > mtd: nand: use nand_check_erased_ecc_chunk in default ECC read > functions > mtd: nand: davinci: remove custom 'erased check' implementation > mtd: nand: diskonchip: remove custom 'erased check' implementation > mtd: nand: jz4740: remove custom 'erased check' implementation Pushed the rest of the series. If someone ends up reviewing/testing the last 2 (I'm not counting on it), then we can revisit them. Thanks, Brian > drivers/mtd/nand/atmel_nand.c | 2 +- > drivers/mtd/nand/bf5xx_nand.c | 20 +++- > drivers/mtd/nand/davinci_nand.c | 15 >
Re: [PATCH] trace: correct start_index in find_next
On 2015/12/31 13:11, Qiu, PeiyangX wrote: > From: Qiu Peiyang > > When we do cat /sys/kernel/debug/tracing/printk_formats, we hit kernel > panic at t_show. > > general protection fault: [#1] PREEMPT SMP > CPU: 0 PID: 2957 Comm: sh Tainted: G W O 3.14.55-x86_64-01062-gd4acdc7 #2 > RIP: 0010:[] > [] t_show+0x22/0xe0 > RSP: :88002b4ebe80 EFLAGS: 00010246 > RAX: RBX: RCX: 0004 > RDX: 0004 RSI: 81fd26a6 RDI: 880032f9f7b1 > RBP: 88002b4ebe98 R08: 1000 R09: ffec > R10: R11: 000f R12: 880004d9b6c0 > R13: 7365725f6d706400 R14: 880004d9b6c0 R15: 82020570 > FS: () GS:88003aa0(0063) knlGS:f776bc40 > CS: 0010 DS: 002b ES: 002b CR0: 80050033 > CR2: f6c02ff0 CR3: 2c2b3000 CR4: 001007f0 > Call Trace: > [] seq_read+0x2f6/0x3e0 > [] vfs_read+0x9b/0x160 > [] SyS_read+0x49/0xb0 > [] ia32_do_call+0x13/0x13 > ---[ end trace 5bd9eb630614861e ]--- > Kernel panic - not syncing: Fatal exception > > When the first time find_next calls find_next_mod_format, it should > iterate the trace_bprintk_fmt_list to find the first print format of > the module. However in current code, start_index is smaller than *pos > at first, and code will not iterate the list. Latter container_of will > get the wrong address with former v, which will cause mod_fmt be a > meaningless object and so is the returned mod_fmt->fmt. > > This patch will fix it by correcting the start_index. After fixed, > when the first time calls find_next_mod_format, start_index will be > equal to *pos, and code will iterate the trace_bprintk_fmt_list to > get the right module printk format, so is the returned mod_fmt->fmt. > > Signed-off-by: Qiu Peiyang > --- > kernel/trace/trace_printk.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c > index 1c2b285..64f0a26 100644 > --- a/kernel/trace/trace_printk.c > +++ b/kernel/trace/trace_printk.c > @@ -273,6 +273,7 @@ static const char **find_next(void *v, loff_t *pos) > if (*pos < last_index + start_index) > return __start___tracepoint_str + (*pos - last_index); > > + start_index += last_index; > return find_next_mod_format(start_index, v, fmt, pos); > } Rusty, Steven, How is this patch? It fixes a kernel panic. Yanmin -- 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 3/5] mtd: nand: davinci: remove custom 'erased check' implementation
On Wed, Dec 30, 2015 at 08:32:05PM +0100, Boris Brezillon wrote: > The davinci drivers is manually checking for 'erased pages' while > correcting ECC bytes. > This logic can now done by the core infrastructure, and can thus be removed > from this drivers. > > Signed-off-by: Boris Brezillon Pushed patch 3 to l2-mtd.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 1/3] NTB: Add AMD PCI-Express NTB driver
> > > >> > +#define ndev_pdev(ndev) ((ndev)->ntb.pdev) #define > ndev_name(ndev) > >> > +pci_name(ndev_pdev(ndev)) #define ndev_dev(ndev) > >> > +(_pdev(ndev)->dev) #define ntb_ndev(ntb) container_of(ntb, > >> > +struct amd_ntb_dev, ntb) #define hb_ndev(work) container_of(work, > >> > +struct amd_ntb_dev, > >> hb_timer.work) > >> > +#define ntb_hotplug_ndev(context) (container_of((context), \ > >> > + struct ntb_acpi_hotplug_context, hp)->ndev) > >> > >> Seems like these are hiding things too. Please use them directly (or > >> at least put them in the C file and not the header file). > > > > I like these macros for up/down casting. Putting them close to the > structure definition seems appropriate to me, too. I would rather see them > moved to right below the definition of struct amd_ntb_dev, instead of to the > c file. That is my opinion, but Jon can make the final decision on it. > > My opinion wasn't super strong on these. If Allen is fine with them, then > good enough for me :) Agree with Allen's opinion. > > > However, these in particular are buggy: > > > >> > +#define ntb_ndev(ntb) container_of(ntb, struct amd_ntb_dev, ntb) > >> > +#define hb_ndev(work) container_of(work, struct amd_ntb_dev, > >> hb_timer.work) > > > > Note: "ntb" will be replaced in all occurrences to the right. This only > > works > if the name "ntb" is passed as the argument. If the argument is named "foo", > it will either fail at compile time to find the member "foo" in struct > amd_ntb_dev, or worse, it will hide a bug accessing the wrong member of > the struct. > > > > Rename the macro parameter __ntb. > > Good call. Please make the necessary mods Xiangliang. Ok
Re: [PATCH v4 00/78] More fixes, cleanup and modernization for NCR5380 drivers
> "Finn" == Finn Thain writes: Finn> Like my previous work on the NCR5380 drivers, this patch series Finn> has bug fixes, code cleanup and modernization. These drivers Finn> suffer from mistakes, poor style and neglect and this long series Finn> addresses the worst of it, covering all ten wrapper drivers and Finn> both of the core driver forks. The combined size of the drivers is Finn> reduced by over 700 LoC. I have staged this for inclusion in a separate branch. Will pull it into the main queue unless kbuild complains. http://git.kernel.org/cgit/linux/kernel/git/mkp/scsi.git/log/?h=4.5/ncr5380 -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.2.y-ckt 009/211] xhci: don't finish a TD if we get a short transfer event mid TD
On Wed, 2016-01-06 at 11:55 -0800, Kamal Mostafa wrote: > On Wed, 2016-01-06 at 17:05 +, Ben Hutchings wrote: > > On Tue, 2016-01-05 at 11:41 -0800, Kamal Mostafa wrote: > > > 4.2.8-ckt1 -stable review patch. If anyone has any objections, please > > > let me know. > > > > > > -- > > > > > > From: Mathias Nyman > > > > > > commit e210c422b6fdd2dc123bedc588f399aefd8bf9de upstream. > > > > > > If the difference is big enough between the bytes asked and received > > > in a bulk transfer we can get a short transfer event pointing to a TRB in > > > the middle of the TD. We don't want to handle the TD yet as we will anyway > > > receive a new event for the last TRB in the TD. > > > > > > Hold off from finishing the TD and removing it from the list until we > > > receive an event for the last TRB in the TD > > > > > > Signed-off-by: Mathias Nyman > > > Signed-off-by: Greg Kroah-Hartman > > > [ kamal: backport to 4.2-stable: context ] > > > Signed-off-by: Kamal Mostafa > > [...] > > > > This causes regressions (see https://bugs.debian.org/808602 and > > https://bugs.debian.org/808953 ) so please hold off until there's a > > complete fix upstream. > > Thanks for the heads-up, Ben. I'll defer it for 4.2-stable. > > I'm thinking that it should also be reverted from the stable kernels > that already carry it (3.2, 3.13, 3.16, 3.19), unless that complete > upstream fix is really imminent. Is it? Normally if there's a regression that affects both mainline and stable branches, we wait for it to be fixed in mainline first. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
RE: [PATCH V2 1/3] NTB: Add AMD PCI-Express NTB driver
> > +
> > +#definePCI_DEVICE_ID_AMD_NTB 0x145B
>
> This looks like a tab and not a space
I'll update it.
>
> > +#define AMD_LINK_HB_TIMEOUTmsecs_to_jiffies(1000)
> > +#define AMD_LINK_STATUS_OFFSET 0x68
> > +#define NTB_LIN_STA_ACTIVE_BIT 0x0002
> > +#define NTB_LNK_STA_SPEED_MASK 0x000F
> > +#define NTB_LNK_STA_WIDTH_MASK 0x03F0
> > +#define NTB_LNK_STA_ACTIVE(x) (!!((x) & NTB_LIN_STA_ACTIVE_BIT))
> > +#define NTB_LNK_STA_SPEED(x) (((x) & NTB_LNK_STA_SPEED_MASK) >>
> 16)
> > +#define NTB_LNK_STA_WIDTH(x) (((x) &
> NTB_LNK_STA_WIDTH_MASK) >> 20)
> > +
> > +#ifndef ioread64
> > +#ifdef readq
> > +#define ioread64 readq
> > +#else
> > +#define ioread64 _ioread64
> > +static inline u64 _ioread64(void __iomem *mmio)
> > +{
> > + u64 low, high;
> > +
> > + low = ioread32(mmio);
> > + high = ioread32(mmio + sizeof(u32));
> > + return low | (high << 32);
> > +}
> > +#endif
> > +#endif
> > +
> > +#ifndef iowrite64
> > +#ifdef writeq
> > +#define iowrite64 writeq
> > +#else
> > +#define iowrite64 _iowrite64
> > +static inline void _iowrite64(u64 val, void __iomem *mmio)
> > +{
> > + iowrite32(val, mmio);
> > + iowrite32(val >> 32, mmio + sizeof(u32));
> > +}
> > +#endif
> > +#endif
> >
How about put ioread64/iowrite64 macro into ntb.h file? So low level driver can
avoid to define these macro.
> > +#define NTB_READ_REG(base, r) (ioread32(base + AMD_ ## r ##
> _OFFSET))
> > +#define NTB_WRITE_REG(base, val, r) (iowrite32(val, base + \
> > + AMD_ ## r ## _OFFSET))
> > +#define NTB_READ_OFFSET(base, r, of) (ioread32(base + of + \
> > + AMD_ ## r ## _OFFSET))
> > +#define NTB_WRITE_OFFSET(base, val, r, of) (iowrite32(val, base + \
> > + of + AMD_ ## r ## _OFFSET))
>
> Please do not use marcos to hide ioread/iowrite. Call iorwad/iowrite
> directly.
I don't see any wrong to hide ioread/iowrite, and I think the macros can make
code readable and easy to maintain.
Re: [PATCH v4 2/5] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions
On Wed, Dec 30, 2015 at 08:32:04PM +0100, Boris Brezillon wrote: > The default NAND read functions are relying on the underlying controller > driver to correct bitflips, but some of those controllers cannot properly > fix bitflips in erased pages. > Check for bitflips in erased pages in default core functions if the driver > delegated the this check by setting the NAND_ECC_GENERIC_ERASED_CHECK flag. > > Signed-off-by: Boris Brezillon Pushed to l2-mtd.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/5] mtd: nand: return consistent error codes in ecc.correct() implementations
On Wed, Dec 30, 2015 at 08:32:03PM +0100, Boris Brezillon wrote: > The error code returned by the ecc.correct() are not consistent over the > all implementations. > > Document the expected behavior in include/linux/mtd/nand.h and fix > offending implementations. > > Signed-off-by: Boris Brezillon > --- > drivers/mtd/nand/atmel_nand.c | 2 +- > drivers/mtd/nand/bf5xx_nand.c | 20 ++-- > drivers/mtd/nand/davinci_nand.c | 6 +++--- > drivers/mtd/nand/jz4740_nand.c | 4 ++-- > drivers/mtd/nand/mxc_nand.c | 4 ++-- > drivers/mtd/nand/nand_bch.c | 2 +- > drivers/mtd/nand/nand_ecc.c | 2 +- > drivers/mtd/nand/omap2.c| 6 +++--- > drivers/mtd/nand/r852.c | 4 ++-- > include/linux/mtd/nand.h| 8 +++- > include/linux/mtd/nand_bch.h| 2 +- > 11 files changed, 37 insertions(+), 23 deletions(-) Pushed patch 1, with added commentary about the bf5xx_nand bugfix. Brian -- 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-next: build failure after merge of the drm tree
Hi all,
On Thu, 31 Dec 2015 21:31:24 +1100 Stephen Rothwell
wrote:
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c: In function
> 'tonga_fan_ctrl_get_fan_speed_percent':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c:84:2: error:
> implicit declaration of function 'do_div'
> [-Werror=implicit-function-declaration]
> do_div(tmp64, duty100);
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c: In function
> 'fiji_fan_ctrl_get_fan_speed_percent':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c:78:2: error:
> implicit declaration of function 'do_div'
> [-Werror=implicit-function-declaration]
> do_div(tmp64, duty100);
> ^
>
> Caused by commit
>
> 1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for tonga.")
>
> [I notice that that commit does not have a Signed-off-by from its
> committer (Alex)]
>
> I applied the following fix patch for today:
>
> From: Stephen Rothwell
> Date: Thu, 31 Dec 2015 21:20:20 +1100
> Subject: [PATCH] drm/amdgpu/powerplay: include asm/div64.h for do_div()
>
> Fixes: 1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for
> tonga.")
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c | 2 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> index def57d0675ed..e76a7de9aa32 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> @@ -20,7 +20,7 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> *
> */
> -
> +#include
> #include "fiji_thermal.h"
> #include "fiji_hwmgr.h"
> #include "fiji_smumgr.h"
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> index 2e159b003e71..a188174747c9 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> @@ -20,7 +20,7 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> *
> */
> -
> +#include
> #include "tonga_thermal.h"
> #include "tonga_hwmgr.h"
> #include "tonga_smumgr.h"
> --
> 2.6.4
Ping? I am still applying that patch ...
--
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/
[GIT PULL] Last MTD fixes for v4.4
Hi Linus, The following changes since commit e488ca9f8d4f62c2dc36bfa5c32f68e7f05ab381: doc: dt: mtd: partitions: add compatible property to "partitions" node (2015-12-08 17:10:20 -0800) are available in the git repository at: git://git.infradead.org/linux-mtd.git tags/for-linus-20160106 for you to fetch changes up to a32d5b726ff8cf32bf491522b0ac8ae2545a063e: mtd: spi-nor: fix stm_is_locked_sr() parameters (2016-01-05 16:00:41 -0800) Three last MTD fixes for v4.4. These are all fixes for regressions and bugs reported mid cycle. Unfortunately, some of them took a bit long to get proper testing and feedback. * Assign the default MTD name earlier in the registration process, so partition parsers (like cmdlinepart) see the right name. Without this, some systems may come up with unpartitioned flash. This was a v4.4-rc1 regression. * Revert some new Winbond SPI NOR flash unlocking/locking support; new code in v4.4 caused regressions on some Spansion flash. * Fix mis-typed parameter ordering in SPI NOR unlock function; this bug was introduced in v4.4-rc1. Brian Norris (3): mtd: fix cmdlinepart parser, early naming for auto-filled MTD mtd: spi-nor: fix Spansion regressions (aliased with Winbond) mtd: spi-nor: fix stm_is_locked_sr() parameters drivers/mtd/mtdcore.c | 26 +- drivers/mtd/spi-nor/spi-nor.c | 10 -- include/linux/mtd/spi-nor.h | 2 +- 3 files changed, 22 insertions(+), 16 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 v2] Add support for usbfs zerocopy.
On Wed, Nov 25, 2015 at 7:19 PM, Steinar H. Gunderson wrote: > Add a new interface for userspace to preallocate memory that can be > used with usbfs. This gives two primary benefits: I got this when trying to allocate a little bit large buffer (~4MB) using the new userspace libusb_dev_mem_alloc(): > [ 1706.212407] usb 2-1.1: reset SuperSpeed USB device number 3 using xhci_hcd > [ 1706.234823] xhci_hcd :00:14.0: swiotlb buffer is full (sz: 4325376 > bytes) > [ 1706.234827] swiotlb: coherent allocation failed for device :00:14.0 > size=4325376 > [ 1706.234830] CPU: 1 PID: 3233 Comm: Protonect Tainted: G U W > 4.4.0-rc8-amd64 #1 Debian 4.4~rc8-1~exp1 > [ 1706.234831] Hardware name: LENOVO 20ALCTO1WW/20ALCTO1WW, BIOS GIET76WW > (2.26 ) 08/27/2014 > [ 1706.234833] 0f50c266 812e6019 > > [ 1706.234836] 8130dc45 8802000b 0042 > 81a2a0e0 > [ 1706.234838] 880206263d80 88021c892f40 > 00420040 > [ 1706.234841] Call Trace: > [ 1706.234847] [] ? dump_stack+0x40/0x57 > [ 1706.234851] [] ? swiotlb_alloc_coherent+0x135/0x150 > [ 1706.234867] [] ? hcd_buffer_alloc+0xb1/0x130 [usbcore] > [ 1706.234875] [] ? usbdev_mmap+0xa5/0x1b0 [usbcore] > [ 1706.234880] [] ? > tty_insert_flip_string_fixed_flag+0x85/0xe0 > [ 1706.234885] [] ? mmap_region+0x3e7/0x660 > [ 1706.234888] [] ? do_mmap+0x336/0x420 > [ 1706.234892] [] ? vm_mmap_pgoff+0xaf/0xf0 > [ 1706.234895] [] ? SyS_mmap_pgoff+0x1ad/0x270 > [ 1706.234898] [] ? SyS_write+0x76/0xc0 > [ 1706.234903] [] ? system_call_fast_compare_end+0xc/0x67 I understand there are some requirements on the allocation such that large blocks are not always available. But what is the proper way to determine the upper limit of the size such that the user can avoid generating warnings like this? (Also, the application really wants to be able to allocate large buffers, maybe tune swiotlb=?.) Test results: Basic testing with smaller buffer size shows the patch works well with Kinect v2 (~260MB/s isochronous). Tests were performed on top of 4.4-rc8 with Debian config. I'm still trying to verify whether this patch fixes page allocation failure, but is having some trouble reproducing memory fragmentation. I will later test it on the original machine which had the problem. Regards, Lingzhu -- 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 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
On 01/07/16 at 10:14am, Xunlei Pang wrote:
> >> +static int
> >> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
> >> +{
> >> + struct page *page;
> >> + unsigned int nr_pages;
> >> +
> >> + /* For physical range: [start, end] */
> >> + if (!start || !end || start > end)
> >> + return 0;
> > Hi, Xunlei.
> >
> > if (start > end)
> > return 0;
>
> If both start and end are zero, we want to return directly, so the two
> more check doesn't hurt.
How about if the start is equal to 0, and end is larger than 0? It is
better to make code more robust, although it never happen in currect
kexec code.
>
> > See the below comment.
> >> +
> >> + page = pfn_to_page(start >> PAGE_SHIFT);
> >> + nr_pages = (end + PAGE_SIZE - start) >> PAGE_SHIFT;
> > As I commented in last version, it is better to cover the case if the
> > range from start to end acrosses two pages.
>
> right.
>
> >> + if (protect)
> >> + return set_pages_ro(page, nr_pages);
> >> + else
> >> + return set_pages_rw(page, nr_pages);
> >> +}
> >> +
> >> +static void kexec_mark_crashkres(bool protect)
> >> +{
> >> + unsigned long control;
> >> +
> >> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
> > Adding the following if test to test crashk_low_res is better. Then we
> > do not need to test if start or end is equal to 0 in kexec_mark_range.
> >
> > if (crashk_low_res.start != crashk_low_res.end) {
> > kexec_mark_range(crashk_low_res.start,
> > crashk_low_res.end, protect);
> > }
>
> The checks in kexec_mark_range() will handle the case, it's not
> performance-critical path and will make the code less clean.
>
> >> +
> >> + /* Don't touch the control code page used in crash_kexec().*/
> >> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
> >> + /* Control code page is located in the 2nd page. */
> >> + kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
> >> + kexec_mark_range(control + 2 * PAGE_SIZE, crashk_res.end, protect);
> > I think it is more readable, if we use MACRO KEXEC_CONTROL_PAGE_SIZE,
> > instead of using 2*PAGE_SIZE directly.
>
> OK.
>
> How about the following update:
> +static void kexec_mark_crashkres(bool protect)
> +{
> + unsigned long control;
> +
> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
> +
> + /* Don't touch the control code page used in crash_kexec().*/
> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
> + /* Control code page is located in the 2nd page. */
> + kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
> + control += KEXEC_CONTROL_PAGE_SIZE;
> + kexec_mark_range(control, crashk_res.end, protect);
> +}
I'm fine with this.
Thanks
Minfei
--
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/4] x86/amd: add accessor for number of cores per compute unit
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in both x86 perf and
fam15h driver.
Signed-off-by: Huang Rui
---
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/cpu/amd.c| 17 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 6752225..9bf48b2 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
extern u16 amd_get_nb_id(int cpu);
extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_cores_per_cu(void);
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
{
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 97db1b6..d6e320f 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -27,6 +27,9 @@
*/
static u32 nodes_per_socket = 1;
+/* cores_per_cu: stores the number of cores per compute unit */
+static u32 cores_per_cu = 1;
+
static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
{
u32 gprs[8] = { 0 };
@@ -299,7 +302,6 @@ static int nearby_node(int apicid)
#ifdef CONFIG_SMP
static void amd_get_topology(struct cpuinfo_x86 *c)
{
- u32 cores_per_cu = 1;
u8 node_id;
int cpu = smp_processor_id();
@@ -313,7 +315,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
/* get compute unit information */
smp_num_siblings = ((ebx >> 8) & 3) + 1;
c->compute_unit_id = ebx & 0xff;
- cores_per_cu += ((ebx >> 8) & 3);
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
@@ -391,6 +392,13 @@ u32 amd_get_nodes_per_socket(void)
}
EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);
+/* this function returns the number of cores per compute unit */
+u32 amd_get_cores_per_cu(void)
+{
+ return cores_per_cu;
+}
+EXPORT_SYMBOL_GPL(amd_get_cores_per_cu);
+
static void srat_detect_node(struct cpuinfo_x86 *c)
{
#ifdef CONFIG_NUMA
@@ -523,10 +531,11 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
use_mwaitx_delay();
if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
- u32 ecx;
+ u32 eax, ebx, ecx, edx;
- ecx = cpuid_ecx(0x801e);
+ cpuid(0x801e, , , , );
nodes_per_socket = ((ecx >> 8) & 7) + 1;
+ cores_per_cu = ((ebx >> 8) & 3) + 1;
} else if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) {
u64 value;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] perf/x86/amd/power: Add AMD accumulated power reporting mechanism
Introduce an AMD accumlated power reporting mechanism for Carrizo (Family 15h, Model 60h) processor that should be used to calculate the average power consumed by a processor during a measurement interval. The feature of accumulated power mechanism is indicated by CPUID Fn8000_0007_EDX[12]. - * Tsample: compute unit power accumulator sample period * Tref: the PTSC counter period * PTSC: performance timestamp counter * N: the ratio of compute unit power accumulator sample period to the PTSC period * Jmax: max compute unit accumulated power which is indicated by MaxCpuSwPwrAcc MSR C001007b * Jx/Jy: compute unit accumulated power which is indicated by CpuSwPwrAcc MSR C001007a * Tx/Ty: the value of performance timestamp counter which is indicated by CU_PTSC MSR C0010280 * PwrCPUave: CPU average power i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007. N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]]. ii. Read the full range of the cumulative energy value from the new MSR MaxCpuSwPwrAcc. Jmax = value returned. iii. At time x, SW reads CpuSwPwrAcc MSR and samples the PTSC. Jx = value read from CpuSwPwrAcc and Tx = value read from PTSC. iv. At time y, SW reads CpuSwPwrAcc MSR and samples the PTSC. Jy = value read from CpuSwPwrAcc and Ty = value read from PTSC. v. Calculate the average power consumption for a compute unit over time period (y-x). Unit of result is uWatt. if (Jy < Jx) // Rollover has occurred Jdelta = (Jy + Jmax) - Jx else Jdelta = Jy - Jx PwrCPUave = N * Jdelta * 1000 / (Ty - Tx) -- This feature will be implemented both on hwmon and perf that discussed in mail list before. At current design, it provides one event to report per package/processor power consumption by counting each compute unit power value. Simple example: root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' make -j4 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h SKIPPED include/generated/compile.h Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#40) MODPOST 4225 modules Performance counter stats for 'system wide': 183.44 mWatts power/power-pkg/ 341.837270111 seconds time elapsed root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' sleep 10 Performance counter stats for 'system wide': 0.18 mWatts power/power-pkg/ 10.012551815 seconds time elapsed Reference: http://lkml.kernel.org/r/20150831160622.ga29...@nazgul.tnic Suggested-by: Peter Zijlstra Suggested-by: Ingo Molnar Suggested-by: Borislav Petkov Signed-off-by: Huang Rui Cc: Guenter Roeck --- arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/perf_event_amd_power.c | 531 + 2 files changed, 532 insertions(+) create mode 100644 arch/x86/kernel/cpu/perf_event_amd_power.c diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 5803130..97f3413 100644 --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_PERF_EVENTS) += perf_event.o ifdef CONFIG_PERF_EVENTS obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd.o perf_event_amd_uncore.o +obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_power.o ifdef CONFIG_AMD_IOMMU obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd_iommu.o endif diff --git a/arch/x86/kernel/cpu/perf_event_amd_power.c b/arch/x86/kernel/cpu/perf_event_amd_power.c new file mode 100644 index 000..6932755 --- /dev/null +++ b/arch/x86/kernel/cpu/perf_event_amd_power.c @@ -0,0 +1,531 @@ +/* + * Performance events - AMD Processor Power Reporting Mechanism + * + * Copyright (C) 2016 Advanced Micro Devices, Inc. + * + * Author: Huang Rui + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include "perf_event.h" + +#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a +#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b +#define MSR_F15H_PTSC 0xc0010280 + +/* + * event code: LSB 8 bits, passed in attr->config + * any other bit is reserved + */ +#define AMD_POWER_EVENT_MASK 0xFFULL + +#define MAX_CUS8 + +/* + * Acc power status counters + */ +#define AMD_POWER_PKG_ID 0 +#define AMD_POWER_EVENTSEL_PKG 1 + +/* + * the
[PATCH 1/4] x86/amd: move nodes_per_socket into bsp_init_amd
nodes_per_socket is static and it needn't be initialized many times
during every cpu core init. So move nodes_per_socket initialization
into bsp_init_amd.
Signed-off-by: Huang Rui
---
arch/x86/kernel/cpu/amd.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index e229640..97db1b6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -308,7 +308,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
u32 eax, ebx, ecx, edx;
cpuid(0x801e, , , , );
- nodes_per_socket = ((ecx >> 8) & 7) + 1;
node_id = ecx & 7;
/* get compute unit information */
@@ -319,7 +318,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
u64 value;
rdmsrl(MSR_FAM10H_NODE_ID, value);
- nodes_per_socket = ((value >> 3) & 7) + 1;
node_id = value & 7;
} else
return;
@@ -523,6 +521,18 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
if (cpu_has(c, X86_FEATURE_MWAITX))
use_mwaitx_delay();
+
+ if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
+ u32 ecx;
+
+ ecx = cpuid_ecx(0x801e);
+ nodes_per_socket = ((ecx >> 8) & 7) + 1;
+ } else if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) {
+ u64 value;
+
+ rdmsrl(MSR_FAM10H_NODE_ID, value);
+ nodes_per_socket = ((value >> 3) & 7) + 1;
+ }
}
static void early_init_amd(struct cpuinfo_x86 *c)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] x86/cpufeature: add AMD Accumulated Power Mechanism feature flag
AMD CPU family 15h model 0x60 introduces accumulated power mechanism. It is used to report the processor power consumption and indicated by CPUID Fn8000_0007_EDX[12]. Signed-off-by: Huang Rui --- arch/x86/include/asm/cpufeature.h | 2 +- arch/x86/kernel/cpu/amd.c | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index f7ba9fb..0adce8f 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -85,7 +85,7 @@ #define X86_FEATURE_P4 ( 3*32+ 7) /* "" P4 */ #define X86_FEATURE_CONSTANT_TSC ( 3*32+ 8) /* TSC ticks at a constant rate */ #define X86_FEATURE_UP ( 3*32+ 9) /* smp kernel running on up */ -/* free, was #define X86_FEATURE_FXSAVE_LEAK ( 3*32+10) * "" FXSAVE leaks FOP/FIP/FOP */ +#define X86_FEATURE_ACC_POWER ( 3*32+10) /* AMD Accumulated Power Mechanism */ #define X86_FEATURE_ARCH_PERFMON ( 3*32+11) /* Intel Architectural PerfMon */ #define X86_FEATURE_PEBS ( 3*32+12) /* Precise-Event Based Sampling */ #define X86_FEATURE_BTS( 3*32+13) /* Branch Trace Store */ diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index d6e320f..97d4ce2 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -559,6 +559,10 @@ static void early_init_amd(struct cpuinfo_x86 *c) set_sched_clock_stable(); } + /* Bit 12 of 8000_0007 edx is accumulated power mechanism. */ + if (c->x86_power & BIT(12)) + set_cpu_cap(c, X86_FEATURE_ACC_POWER); + #ifdef CONFIG_X86_64 set_cpu_cap(c, X86_FEATURE_SYSCALL32); #else -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] perf/x86/power: Introduce AMD accumlated power reporting mechanism
Hi, This series of patches introduces the perf implementation of accumulated power reporting algorithm. It will calculate the average power consumption for the processor. The CPU feature flag is CPUID.8000_0007H:EDX[12]. Simple example: root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' make -j4 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h SKIPPED include/generated/compile.h Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#40) MODPOST 4225 modules Performance counter stats for 'system wide': 183.44 mWatts power/power-pkg/ 341.837270111 seconds time elapsed root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' sleep 10 Performance counter stats for 'system wide': 0.18 mWatts power/power-pkg/ 10.012551815 seconds time elapsed Reference: http://lkml.kernel.org/r/20150831160622.ga29...@nazgul.tnic Thanks, Rui Huang Rui (4): x86/amd: move nodes_per_socket into bsp_init_amd x86/amd: add accessor for number of cores per compute unit x86/cpufeature: add AMD Accumulated Power Mechanism feature flag perf/x86/amd/power: Add AMD accumulated power reporting mechanism arch/x86/include/asm/cpufeature.h | 2 +- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/amd.c | 31 +- arch/x86/kernel/cpu/perf_event_amd_power.c | 531 + 5 files changed, 561 insertions(+), 5 deletions(-) create mode 100644 arch/x86/kernel/cpu/perf_event_amd_power.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 2/3] NTB: Add AMD NTB support in Kconfig and Makefile
> > drivers/ntb/hw/Kconfig | 1 + > > drivers/ntb/hw/Makefile | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/drivers/ntb/hw/Kconfig b/drivers/ntb/hw/Kconfig index > > 4d5535c..0c5c2a6 100644 > > --- a/drivers/ntb/hw/Kconfig > > +++ b/drivers/ntb/hw/Kconfig > > @@ -1 +1,2 @@ > > source "drivers/ntb/hw/intel/Kconfig" > > +source "drivers/ntb/hw/amd/Kconfig" > > diff --git a/drivers/ntb/hw/Makefile b/drivers/ntb/hw/Makefile index > > 175d7c9..636be7d 100644 > > --- a/drivers/ntb/hw/Makefile > > +++ b/drivers/ntb/hw/Makefile > > @@ -1 +1,2 @@ > > obj-$(CONFIG_NTB_INTEL)+= intel/ > > +obj-$(CONFIG_NTB_AMD) += amd/ > > -- > > 1.9.1 > > > > This should be part of the first patch. Ok.
Re: [PATCH v2 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
On 01/07/2016 at 10:14 AM, Xunlei Pang wrote:
> On 01/07/2016 at 01:08 AM, Minfei Huang wrote:
>> On 01/06/16 at 05:50pm, Xunlei Pang wrote:
>>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>>> b/arch/x86/kernel/machine_kexec_64.c
>>> index 819ab3f..cda867d 100644
>>> --- a/arch/x86/kernel/machine_kexec_64.c
>>> +++ b/arch/x86/kernel/machine_kexec_64.c
>>> @@ -536,3 +536,44 @@ overflow:
>>> return -ENOEXEC;
>>> }
>>> #endif /* CONFIG_KEXEC_FILE */
>>> +
>>> +static int
>>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>>> +{
>>> + struct page *page;
>>> + unsigned int nr_pages;
>>> +
>>> + /* For physical range: [start, end] */
>>> + if (!start || !end || start > end)
>>> + return 0;
>> Hi, Xunlei.
>>
>> if (start > end)
>> return 0;
> If both start and end are zero, we want to return directly, so the two
> more check doesn't hurt.
>
>> See the below comment.
>>> +
>>> + page = pfn_to_page(start >> PAGE_SHIFT);
>>> + nr_pages = (end + PAGE_SIZE - start) >> PAGE_SHIFT;
>> As I commented in last version, it is better to cover the case if the
>> range from start to end acrosses two pages.
> right.
>
>>> + if (protect)
>>> + return set_pages_ro(page, nr_pages);
>>> + else
>>> + return set_pages_rw(page, nr_pages);
>>> +}
>>> +
>>> +static void kexec_mark_crashkres(bool protect)
>>> +{
>>> + unsigned long control;
>>> +
>>> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
>> Adding the following if test to test crashk_low_res is better. Then we
>> do not need to test if start or end is equal to 0 in kexec_mark_range.
>>
>> if (crashk_low_res.start != crashk_low_res.end) {
>> kexec_mark_range(crashk_low_res.start,
>> crashk_low_res.end, protect);
>> }
> The checks in kexec_mark_range() will handle the case, it's not
> performance-critical path and will make the code less clean.
>
>>> +
>>> + /* Don't touch the control code page used in crash_kexec().*/
>>> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>>> + /* Control code page is located in the 2nd page. */
>>> + kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
>>> + kexec_mark_range(control + 2 * PAGE_SIZE, crashk_res.end, protect);
>> I think it is more readable, if we use MACRO KEXEC_CONTROL_PAGE_SIZE,
>> instead of using 2*PAGE_SIZE directly.
> OK.
>
> How about the following update:
>
> +static int
> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
> +{
> + struct page *page;
> + unsigned int nr_pages;
> +
> + /* For physical range: [start, end] */
> + if (!start || !end || start > end)
> + return 0;
> +
> + page = pfn_to_page(start >> PAGE_SHIFT);
> + nr_pages = (end >> PAGE_SHIFT) - (start >> PAGE_SHIFT) + 1;
> + if (protect)
> + return set_pages_ro(page, nr_pages);
> + else
> + return set_pages_rw(page, nr_pages);
> +}
> +
> +static void kexec_mark_crashkres(bool protect)
> +{
> + unsigned long control;
> +
> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
> +
> + /* Don't touch the control code page used in crash_kexec().*/
> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
> + /* Control code page is located in the 2nd page. */
> + kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
> + control += KEXEC_CONTROL_PAGE_SIZE;
In fact, control code page is only 1 page, using control + 2*PAGE_SIZE is
clearer.
For example, if we have more other type pages following it. Anyway this is not
that important.
Regards,
Xunlei
> + kexec_mark_range(control, crashk_res.end, protect);
> +}
> +
> +void arch_kexec_protect_crashkres(void)
> +{
> + kexec_mark_crashkres(true);
> +}
> +
> +void arch_kexec_unprotect_crashkres(void)
> +{
> + kexec_mark_crashkres(false);
> +}
>
>> Thanks
>> Minfei
>>
>> ___
>> kexec mailing list
>> ke...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: exynos_defconfig: Enable s5p-secss driver
The Exynos SoC provides a Security SubSystem block for accelerating some cryptographic operations. Enable the driver for it - s5p-secss to utilize the hardware acceleration. Currently the s5p-secss driver supports AES in CBC and ECB modes. However on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412) boards this change introduces one booting error: alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: ret=22 The cbc-aes-s5p properly registers itself and passes self-tests. Signed-off-by: Krzysztof Kozlowski --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 0aee1e035be9..c47c7e069873 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -240,6 +240,7 @@ CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_USER=y +CONFIG_CRYPTO_DEV_S5P=y CONFIG_ARM_CRYPTO=y CONFIG_CRYPTO_SHA1_ARM_NEON=m CONFIG_CRYPTO_SHA256_ARM=m -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: exynos_defconfig: Enable NEON, accelerated crypto and cpufreq stats
Enable the kernel NEON mode and asm/NEON accelerated crypto algorithms which should bring performance benefits on Exynos SoCs. Enable these as modules because they are optional, not essential anyhow for platform booting nor related directly to Exynos Soc. All accelerated algorithms pass booting self-tests on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412). Additionally enable cpufreq statistics as they are useful for debugging. Signed-off-by: Krzysztof Kozlowski --- arch/arm/configs/exynos_defconfig | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 24dcd2bb1215..0aee1e035be9 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -26,12 +26,14 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M console=ttySAC1,115200 init=/linuxrc mem=256M" CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPUFREQ_DT=y CONFIG_CPU_IDLE=y CONFIG_ARM_EXYNOS_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y +CONFIG_KERNEL_MODE_NEON=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -238,7 +240,11 @@ CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_USER=y -CONFIG_CRYPTO_SHA256=y +CONFIG_ARM_CRYPTO=y +CONFIG_CRYPTO_SHA1_ARM_NEON=m +CONFIG_CRYPTO_SHA256_ARM=m +CONFIG_CRYPTO_SHA512_ARM=m +CONFIG_CRYPTO_AES_ARM_BS=m CONFIG_CRC_CCITT=y CONFIG_FONTS=y CONFIG_FONT_7x14=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK keyring
On Thu, 2016-01-07 at 00:34 +, David Howells wrote: > David Howells wrote: > > > Partially revert commit 41c89b64d7184a780f12f2cccdabe65cb2408893: > > > > Author: Petko Manolov > > Date: Wed Dec 2 17:47:55 2015 +0200 > > IMA: create machine owner and blacklist keyrings > > > > The problem is that prep->trusted is a simple boolean and the additional > > x509_validate_trust() call doesn't therefore distinguish levels of > > trustedness, but is just OR'd with the result of validation against the > > system trusted keyring. > > > > However, setting the trusted flag means that this key may be added to *any* > > trusted-only keyring - including the system trusted keyring. Hm, I'm not able to add a key to the system keyring that is signed by a key on either the system or the IMA MOK keyrings. The system keyring seems to be "locked". A key that is signed by either a key on the system or the IMA MOK keyring can be added to the IMA keyring. keyctl show %keyring:.system_keyring Keyring 973688077 ---lswrv 0 0 keyring: .system_keyring evmctl import m1-cert-signed.der 973688077 add_key failed errno: Permission denied (13) Mimi > > Whilst I appreciate what the patch is trying to do, I don't think this is > > quite the right solution. > Please apply this to security/next. > > Thanks, > David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
On 01/07/2016 at 01:08 AM, Minfei Huang wrote:
> On 01/06/16 at 05:50pm, Xunlei Pang wrote:
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 819ab3f..cda867d 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -536,3 +536,44 @@ overflow:
>> return -ENOEXEC;
>> }
>> #endif /* CONFIG_KEXEC_FILE */
>> +
>> +static int
>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>> +{
>> +struct page *page;
>> +unsigned int nr_pages;
>> +
>> +/* For physical range: [start, end] */
>> +if (!start || !end || start > end)
>> +return 0;
> Hi, Xunlei.
>
> if (start > end)
> return 0;
If both start and end are zero, we want to return directly, so the two
more check doesn't hurt.
> See the below comment.
>> +
>> +page = pfn_to_page(start >> PAGE_SHIFT);
>> +nr_pages = (end + PAGE_SIZE - start) >> PAGE_SHIFT;
> As I commented in last version, it is better to cover the case if the
> range from start to end acrosses two pages.
right.
>> +if (protect)
>> +return set_pages_ro(page, nr_pages);
>> +else
>> +return set_pages_rw(page, nr_pages);
>> +}
>> +
>> +static void kexec_mark_crashkres(bool protect)
>> +{
>> +unsigned long control;
>> +
>> +kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
> Adding the following if test to test crashk_low_res is better. Then we
> do not need to test if start or end is equal to 0 in kexec_mark_range.
>
> if (crashk_low_res.start != crashk_low_res.end) {
> kexec_mark_range(crashk_low_res.start,
> crashk_low_res.end, protect);
> }
The checks in kexec_mark_range() will handle the case, it's not
performance-critical path and will make the code less clean.
>> +
>> +/* Don't touch the control code page used in crash_kexec().*/
>> +control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>> +/* Control code page is located in the 2nd page. */
>> +kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
>> +kexec_mark_range(control + 2 * PAGE_SIZE, crashk_res.end, protect);
> I think it is more readable, if we use MACRO KEXEC_CONTROL_PAGE_SIZE,
> instead of using 2*PAGE_SIZE directly.
OK.
How about the following update:
+static int
+kexec_mark_range(unsigned long start, unsigned long end, bool protect)
+{
+ struct page *page;
+ unsigned int nr_pages;
+
+ /* For physical range: [start, end] */
+ if (!start || !end || start > end)
+ return 0;
+
+ page = pfn_to_page(start >> PAGE_SHIFT);
+ nr_pages = (end >> PAGE_SHIFT) - (start >> PAGE_SHIFT) + 1;
+ if (protect)
+ return set_pages_ro(page, nr_pages);
+ else
+ return set_pages_rw(page, nr_pages);
+}
+
+static void kexec_mark_crashkres(bool protect)
+{
+ unsigned long control;
+
+ kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
+
+ /* Don't touch the control code page used in crash_kexec().*/
+ control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
+ /* Control code page is located in the 2nd page. */
+ kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
+ control += KEXEC_CONTROL_PAGE_SIZE;
+ kexec_mark_range(control, crashk_res.end, protect);
+}
+
+void arch_kexec_protect_crashkres(void)
+{
+ kexec_mark_crashkres(true);
+}
+
+void arch_kexec_unprotect_crashkres(void)
+{
+ kexec_mark_crashkres(false);
+}
> Thanks
> Minfei
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
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-next: build failure after merge of the vfs tree
On Thu, Jan 07, 2016 at 11:42:53AM +1100, Stephen Rothwell wrote:
> > This patch now looks like this (after changes to the orangefs tree):
> >
Guys, just set inode->i_link to ORANGEFS_I(dentry->d_inode)->link_target and
have ->get_link = simple_get_link. Killing orangefs_{follow,get}_link()
entirely.
--
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: dm ioctl: Access user-land memory through safe functions.
On Wed, Jan 06 2016 at 8:22pm -0500,
Scotty Bauer wrote:
>
>
> On 01/05/2016 02:13 PM, Mike Snitzer wrote:
> > On Tue, Jan 05 2016 at 3:16pm -0500,
> > Mike Snitzer wrote:
> >
> >> On Tue, Dec 08 2015 at 1:26pm -0500,
> >> Scotty Bauer wrote:
> >>
> >>> Friendly ping, is anyone interested in this?
> >>
> >> The passed @user argument is flagged via __user so it can be
> >> deferenced directly. It does look like directly deferencing
> >> user->version is wrong.
> >>
> >> But even if such indirect access is needed (because __user flag is only
> >> applicable to @user arg, not the contained version member) we could more
> >> easily just do something like this no?:
> >>
> >> uint32_t __user *versionp = (uint32_t __user *)user->version;
> >> ...
> >> if (copy_from_user(version, versionp, sizeof(version)))
> >> return -EFAULT;
> >>
> >> I've staged the following, thanks:
> >> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.5=bffc9e237a0c3176712bcd93fc6a184a61e0df26
> >
> > Alasdair helped me understand that we do need your original fix.
> > I've staged it for 4.5 (and stable@) here:
> > https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.5=ead3db62bf10fe143bec99e7b7ff370d7a6d23ef
> >
> > Thanks again,
> > Mike
> > --
>
> This broke linux-next because I'm dumb and didn't test it. I thought it was a
> trivial enough of a patch that I wouldn't screw it up, but I did.
>
> I incorrectly assumed that user->version was essentially a pointer in
> userland, not a flat chunk of memory. Ie it was a pointer to some malloc'd
> region, not an inlined version[3].
>
> I thought it was this:
> struct dm_ioctl {
>
> uint32_t *version;
> ...
> }
>
> It is really this:
>
> struct dm_ioctl {
>
> uint32_t version[3];
>
> }
>
> I was trying to get the values out of *version, which would have been a
> pointer, but instead what the code ended up doing was actually getting 8
> bytes of the version (think 4,3,1) out and trying to access that version as a
> memory address, oops.
>
> It turns out that the original code is correct and doesn't actually touch
> user memory without a copy_from_user(). Gcc is smart enough to see that
> version[3] is inlined, and it can emit code which simply takes the userland
> pointer (struct dm_ioctl __user user), and calculates on offset based on the
> pointer, thus no actual user dereference occurs. Had the struct looked like
> the first example I believe the patch would work.
>
> I'm wondering now if we should switch the code a bit to make it less
> ambiguous, so someone like me doesn't come along again thinking the code
> dereferences userland memory and waste everyones time.
>
> I've attached a patch based off linux-next-20150616 which reverts my broken
> code but adds an & to the front of user->version so it looks like the code is
> doing the right thing.
>
> If I should be basing my patch off something other than linux-next let me
> know and I'll rewrite it, or we can just revert the old patch and ignore this
> one.
>
> Thanks and very sorry for the confusion and breakage.
You're fine, no worries.
But I've just dropped the offending original commit from linux-next and
it obviously won't be included in 4.5
I'll revisit whether we need to bother with the extra & change you're
suggesting while coming to terms with why I was able to be lulled into
thinking your original patch was 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 v2 1/5] devicetree: bindings: Document qcom board compatible format
On 11/23/15 16:47, Stephen Boyd wrote: > On 11/22, Rob Herring wrote: >> >> Much more reasonable now. I do find the '/' in it a bit strange though. > I can remove the backslash if you like. Is a dash more preferred? > >> Acked-by: Rob Herring >> > and if so can I keep the ack? I'll resend with that change and > add the ack. > I'll take no answer as "let's not change anything", so can someone pickup this patch as is? Perhaps Andy can do that? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] ftrace/module: Call clean up function when module init fails early
Steven Rostedt writes: > [ Bah, I forgot to commit the ftrace.h part, lucky I test on another > box than what I compile test on ;-) ] Acked-by: Rusty Russell Cheers, Rusty. -- 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] mfd: qcom-spmi-pmic: Don't access non-existing registers
On 11/17/15 16:06, Stephen Boyd wrote: > From: "Ivan T. Ivanov" > > Revision ID registers are available only on devices with > Slave IDs that are even, so don't make access to unavailable > registers. > > Signed-off-by: Ivan T. Ivanov > [sb...@codeaurora.org: Consider all slave ids that are even] > Signed-off-by: Stephen Boyd > --- Ping? > drivers/mfd/qcom-spmi-pmic.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c > index af6ac1c4b45c..8653e8b9bb4f 100644 > --- a/drivers/mfd/qcom-spmi-pmic.c > +++ b/drivers/mfd/qcom-spmi-pmic.c > @@ -127,7 +127,9 @@ static int pmic_spmi_probe(struct spmi_device *sdev) > if (IS_ERR(regmap)) > return PTR_ERR(regmap); > > - pmic_spmi_show_revid(regmap, >dev); > + /* Only the first slave id for a PMIC contains this information */ > + if (sdev->usid % 2 == 0) > + pmic_spmi_show_revid(regmap, >dev); > > return of_platform_populate(root, NULL, NULL, >dev); > } -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] driver-core: platform: Add platform_irq_count()
On Wed, Jan 06, 2016 at 05:12:47PM -0800, Stephen Boyd wrote: > A recent patch added calls to of_irq_count() in the qcom pinctrl > drivers and that caused module build failures because > of_irq_count() is not an exported symbol. We shouldn't export > of_irq_count() to modules because it's an internal OF API that > shouldn't be used by drivers. Platform drivers should use > platform device APIs instead. Therefore, add a platform_irq_count() > API that mirrors the of_irq_count() API so that platform drivers > can stay DT agnostic. > > Cc: Rob Herring > Cc: Greg Kroah-Hartman > Cc: Andy Gross > Signed-off-by: Stephen Boyd > --- > drivers/base/platform.c | 20 > include/linux/platform_device.h | 1 + > 2 files changed, 21 insertions(+) Acked-by: Greg Kroah-Hartman http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel
On Wed, Jan 06, 2016 at 03:36:57PM +0100, Jiri Kosina wrote: > On Mon, 4 Jan 2016, Benjamin Tissoires wrote: > > > Jiri, I *think* this commit still is in your next pull request for > > Linus. We might want to drop it before it hits Linus' tree. > > What exactly would be the reasoning for dropping it? It is wrong. Aside form the fact that IMO xpad.c is the wrong place for this code to be in, why are we waiting for the input device to be opened by userspace before we do the switch instead of doing it immediately? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] patch about "don't reset vcpu_info on a cancelled suspend"
On 2016/1/4 19:54, David Vrabel wrote: > On 29/12/15 05:49, Ouyangzhaowei (Charles) wrote: >> Hi David, >> >> This patch has been applied to for-linus-4.1b, and we wonder if this patch >> will be applied to linux kernel, or does >> it still needs more test to apply to linux kernel? > > Sorry, it looks like I forgot to send a pull request for this patch. > I'd applied it to for-linus-4.5 and tagged it for stable. OK, thanks! > > David > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v5 5/6] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping
Hi Richard,
This all sounds fine. Thanks for the feedback. I'll roll this into the
next patchset.
Chris
On Tue, 05 Jan 2016 07:27:32 -0800, Richard Cochran
wrote:
On Mon, Jan 04, 2016 at 04:45:22AM -0800, Christopher S. Hall wrote:
+ case PTP_SYS_OFFSET_PRECISE:
+ if (!ptp->info->getsynctime) {
+ err = -EINVAL;
-EOPNOTSUPP would be better here.
+ precise_offset.sys_real.sec =
+ div_u64_rem(ktime_to_ns(xtstamp.sys_realtime),
+ NSEC_PER_SEC, );
+ precise_offset.sys_real.nsec = rem;
How about this instead:
ts = ktime_to_timespec64(xtstamp.sys_realtime);
precise_offset.sys_real.sec = ts.tv_sec;
precise_offset.sys_real.nsec = ts.tv_nsec;
+ precise_offset.sys_raw.sec =
+ div_u64_rem(ktime_to_ns(xtstamp.sys_monoraw),
+ NSEC_PER_SEC, );
+ precise_offset.sys_raw.nsec = rem;
+ precise_offset.dev.sec =
+ div_u64_rem(ktime_to_ns(xtstamp.device), NSEC_PER_SEC,
+ );
+ precise_offset.dev.nsec = rem;
And for these as well.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
