Re: [Gta04-owner] [PATCH 3/4] usb: phy: twl4030: add support for reading restore on ID pin.
On Wed, 4 Mar 2015 07:54:41 +0100 "Dr. H. Nikolaus Schaller"
wrote:
>
> Am 04.03.2015 um 07:35 schrieb NeilBrown :
>
> > On Mon, 2 Mar 2015 22:04:31 +0100 Pavel Machek wrote:
> >
> >> Hi!
> >>
> >>> The twl4030 phy can measure, with low precision, the
> >>> resistance-to-ground of the ID pin.
> >>>
> >>> Add a function to read the value, and export the result
> >>> via sysfs.
> >>>
> >>> If the read fails, which it does sometimes, try again in 50msec.
> >>>
> >>> Signed-off-by: NeilBrown
> >>> ---
> >>> drivers/phy/phy-twl4030-usb.c | 63
> >>> +
> >>> 1 file changed, 63 insertions(+)
> >>>
> >>> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
> >>> index 023fe150c7a1..759950898df9 100644
> >>> --- a/drivers/phy/phy-twl4030-usb.c
> >>> +++ b/drivers/phy/phy-twl4030-usb.c
> >>> @@ -374,6 +374,56 @@ static void twl4030_i2c_access(struct twl4030_usb
> >>> *twl, int on)
> >>> }
> >>> }
> >>>
> >>> +enum twl4030_id_status {
> >>> + TWL4030_GROUND,
> >>> + TWL4030_102K,
> >>> + TWL4030_200K,
> >>> + TWL4030_440K,
> >>> + TWL4030_FLOATING,
> >>> + TWL4030_ID_UNKNOWN,
> >>> +};
> >>> +static char *twl4030_id_names[] = {
> >>> + "ground",
> >>> + "102k",
> >>> + "200k",
> >>> + "440k",
> >>
> >> New /sys files should be documented somewhere...?
> >
> > Preferably with the code...
> >
> >>
> >> Does it make sense to change "440k" -> "440KOhm"?
> >
> > Interesting question. I prefer to avoid including units in files - bare
> > numbers is better. But there is no number to match "floating" unless I
> > spell
> > it out as "infinity", and wouldn't be helpful.
> >
> > Certainly "K" would be preferred over "k“,
>
> The international standard for kilo = 1000 is a lower case k.
> While it is (non-standard) to use K for 1024:
>
> http://en.wikipedia.org/wiki/Kilobyte
>
> So I would keep the string constants lower case to avoid this potential
> confusion.
Yes, I got that backwards, didn't I.
I think I'll leave it as lower-case.
I won't include the word "ohm" - it is very uncommon to have units explicit
in sysfs attribute values.
Thanks,
NeilBrown
pgpAAlXf6q1UC.pgp
Description: OpenPGP digital signature
[PATCH v3 2/3] powerpc/powernv: Move cpuidle related code from setup.c to new file
This is a cleanup patch; doesn't change any functionality. Moves
all cpuidle related code from setup.c to a new file.
Signed-off-by: Shreyas B. Prabhu
---
This patch is new in v3
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/idle.c | 186
arch/powerpc/platforms/powernv/setup.c | 166
3 files changed, 187 insertions(+), 167 deletions(-)
create mode 100644 arch/powerpc/platforms/powernv/idle.c
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index 6f3c5d3..560ee54 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,4 +1,4 @@
-obj-y += setup.o opal-wrappers.o opal.o opal-async.o
+obj-y += setup.o opal-wrappers.o opal.o opal-async.o idle.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o
opal-sensor.o
obj-y += opal-msglog.o opal-hmi.o opal-power.o
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
new file mode 100644
index 000..77992f6
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -0,0 +1,186 @@
+/*
+ * PowerNV cpuidle code
+ *
+ * Copyright 2015 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "powernv.h"
+#include "subcore.h"
+
+static u32 supported_cpuidle_states;
+
+int pnv_save_sprs_for_winkle(void)
+{
+ int cpu;
+ int rc;
+
+ /*
+* hid0, hid1, hid4, hid5, hmeer and lpcr values are symmetric accross
+* all cpus at boot. Get these reg values of current cpu and use the
+* same accross all cpus.
+*/
+ uint64_t lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
+ uint64_t hid0_val = mfspr(SPRN_HID0);
+ uint64_t hid1_val = mfspr(SPRN_HID1);
+ uint64_t hid4_val = mfspr(SPRN_HID4);
+ uint64_t hid5_val = mfspr(SPRN_HID5);
+ uint64_t hmeer_val = mfspr(SPRN_HMEER);
+
+ for_each_possible_cpu(cpu) {
+ uint64_t pir = get_hard_smp_processor_id(cpu);
+ uint64_t hsprg0_val = (uint64_t)&paca[cpu];
+
+ /*
+* HSPRG0 is used to store the cpu's pointer to paca. Hence last
+* 3 bits are guaranteed to be 0. Program slw to restore HSPRG0
+* with 63rd bit set, so that when a thread wakes up at 0x100 we
+* can use this bit to distinguish between fastsleep and
+* deep winkle.
+*/
+ hsprg0_val |= 1;
+
+ rc = opal_slw_set_reg(pir, SPRN_HSPRG0, hsprg0_val);
+ if (rc != 0)
+ return rc;
+
+ rc = opal_slw_set_reg(pir, SPRN_LPCR, lpcr_val);
+ if (rc != 0)
+ return rc;
+
+ /* HIDs are per core registers */
+ if (cpu_thread_in_core(cpu) == 0) {
+
+ rc = opal_slw_set_reg(pir, SPRN_HMEER, hmeer_val);
+ if (rc != 0)
+ return rc;
+
+ rc = opal_slw_set_reg(pir, SPRN_HID0, hid0_val);
+ if (rc != 0)
+ return rc;
+
+ rc = opal_slw_set_reg(pir, SPRN_HID1, hid1_val);
+ if (rc != 0)
+ return rc;
+
+ rc = opal_slw_set_reg(pir, SPRN_HID4, hid4_val);
+ if (rc != 0)
+ return rc;
+
+ rc = opal_slw_set_reg(pir, SPRN_HID5, hid5_val);
+ if (rc != 0)
+ return rc;
+ }
+ }
+
+ return 0;
+}
+
+static void pnv_alloc_idle_core_states(void)
+{
+ int i, j;
+ int nr_cores = cpu_nr_cores();
+ u32 *core_idle_state;
+
+ /*
+* core_idle_state - First 8 bits track the idle state of each thread
+* of the core. The 8th bit is the lock bit. Initially all thread bits
+* are set. They are cleared when the thread enters deep idle state
+* like sleep and winkle. Initially the lock bit is cleared.
+* The lock bit has 2 purposes
+* a. While the first thread is restoring core state, it prevents
+* other threads in the core from switching to process context.
+* b. While the last thread in the core is saving the core state, it
+* prevents a different thread from waking up.
+*/
+ fo
[PATCH v3 3/3] powerpc/powernv: Introduce sysfs control for fastsleep workaround behavior
Fastsleep is one of the idle state which cpuidle subsystem currently
uses on power8 machines. In this state L2 cache is brought down to a
threshold voltage. Therefore when the core is in fastsleep, the
communication between L2 and L3 needs to be fenced. But there is a bug
in the current power8 chips surrounding this fencing.
OPAL provides a workaround which precludes the possibility of hitting
this bug. But running with this workaround applied causes checkstop
if any correctable error in L2 cache directory is detected. Hence OPAL
also provides a way to undo the workaround.
In the existing implementation, workaround is applied by the last thread
of the core entering fastsleep and undone by the first thread waking up.
But this has a performance cost. These OPAL calls account for roughly
4000 cycles everytime the core has to enter or wakeup from fastsleep.
This patch introduces a sysfs attribute (fastsleep_workaround_state)
to choose the behavior of this workaround.
By default, fastsleep_workaround_state = 0. In this case, workaround
is applied/undone everytime the core enters/exits fastsleep.
fastsleep_workaround_state = 1. In this case the workaround is applied
once on all the cores and never undone. This can be triggered by
echo 1 > /sys/devices/system/cpu/fastsleep_workaround_state
For simplicity this attribute can be modified only once. Implying, once
fastsleep_workaround_state is changed to 1, it cannot be reverted to
the default state.
Signed-off-by: Shreyas B. Prabhu
---
Changes in V3-
Kernel parameter changed to sysfs attribute
Modified commmit message
arch/powerpc/include/asm/opal.h| 8 +++
arch/powerpc/platforms/powernv/idle.c | 83 +-
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
3 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9ee0a30..8bea8fc 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -180,6 +180,13 @@ struct opal_sg_list {
#define OPAL_PM_WINKLE_ENABLED 0x0004
#define OPAL_PM_SLEEP_ENABLED_ER1 0x0008
+/*
+ * OPAL_CONFIG_CPU_IDLE_STATE parameters
+ */
+#define OPAL_CONFIG_IDLE_FASTSLEEP 1
+#define OPAL_CONFIG_IDLE_UNDO 0
+#define OPAL_CONFIG_IDLE_APPLY 1
+
#ifndef __ASSEMBLY__
#include
@@ -924,6 +931,7 @@ int64_t opal_handle_hmi(void);
int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
int64_t opal_unregister_dump_region(uint32_t id);
int64_t opal_slw_set_reg(uint64_t cpu_pir, uint64_t sprn, uint64_t val);
+int64_t opal_config_cpu_idle_state(uint64_t state, uint64_t flag);
int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t
pe_number);
int64_t opal_ipmi_send(uint64_t interface, struct opal_ipmi_msg *msg,
uint64_t msg_len);
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 77992f6..79157b9 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -136,6 +138,77 @@ u32 pnv_get_supported_cpuidle_states(void)
}
EXPORT_SYMBOL_GPL(pnv_get_supported_cpuidle_states);
+static void pnv_fastsleep_workaround_apply(void *info)
+{
+ opal_config_cpu_idle_state(OPAL_CONFIG_IDLE_FASTSLEEP,
+ OPAL_CONFIG_IDLE_APPLY);
+}
+
+/*
+ * Used to store fastsleep workaround state
+ * 0 - Workaround applied/undone at fastsleep entry/exit path (Default)
+ * 1 - Workaround applied once, never undone.
+ */
+static u8 fastsleep_workaround_state;
+
+static ssize_t show_fastsleep_workaround_state(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%u\n", fastsleep_workaround_state);
+}
+
+static ssize_t store_fastsleep_workaround_state(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
+{
+ u32 val;
+ cpumask_t primary_thread_mask;
+
+ /*
+* fastsleep_workaround_state is write-once parameter.
+* Once it has been set to 1, it cannot be undone.
+*/
+ if (fastsleep_workaround_state == 1)
+ return -EINVAL;
+
+ if (kstrtou32(buf, 0, &val))
+ return -EINVAL;
+
+ if (val > 1)
+ return -EINVAL;
+
+ fastsleep_workaround_state = 1;
+ /*
+* fastsleep_workaround_state = 1 implies fastsleep workaround needs to
+* be left in 'applied' state on all the cores. Do this by-
+* 1. Patching out the call to 'undo' workaround in fastsleep exit path
+* 2. Sending ipi to all the cores which have atleast one online thread
+* 3. Patching out the call to 'apply' workaround in fastsleep entry
+* path
+* There is no need to send ipi to c
[PATCH v3 1/3] powerpc: Fix cpu_online_cores_map to return only online threads mask
Currently, cpu_online_cores_map returns a mask, which for every core
that has atleast one online thread, has the first-cpu-of-that-core's bit
set. But the first cpu itself may not be online always. In such cases, if
the returned mask is used for IPI, then it'll cause IPIs to be skipped
on cores where the first thread is offline.
Fix this by setting first-online-cpu-of-the-core's bit in the mask.
This is done by fixing this in the underlying function
cpu_thread_mask_to_cores.
Signed-off-by: Shreyas B. Prabhu
---
This patch is new in v3
In an example scenario where all the threads of 1st core are offline
and argument to cpu_thread_mask_to_cores is cpu_possible_mask,
with this implementation, return value will not have any bit
corresponding to 1st core set. I think that should be okay. Any thoughts?
arch/powerpc/include/asm/cputhreads.h | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cputhreads.h
b/arch/powerpc/include/asm/cputhreads.h
index 2bf8e93..9e8485c 100644
--- a/arch/powerpc/include/asm/cputhreads.h
+++ b/arch/powerpc/include/asm/cputhreads.h
@@ -31,9 +31,9 @@ extern cpumask_t threads_core_mask;
/* cpu_thread_mask_to_cores - Return a cpumask of one per cores
*hit by the argument
*
- * @threads: a cpumask of threads
+ * @threads: a cpumask of online threads
*
- * This function returns a cpumask which will have one "cpu" (or thread)
+ * This function returns a cpumask which will have one online cpu's
* bit set for each core that has at least one thread set in the argument.
*
* This can typically be used for things like IPI for tlb invalidations
@@ -42,13 +42,16 @@ extern cpumask_t threads_core_mask;
static inline cpumask_t cpu_thread_mask_to_cores(const struct cpumask *threads)
{
cpumask_t tmp, res;
- int i;
+ int i, cpu;
cpumask_clear(&res);
for (i = 0; i < NR_CPUS; i += threads_per_core) {
cpumask_shift_left(&tmp, &threads_core_mask, i);
- if (cpumask_intersects(threads, &tmp))
- cpumask_set_cpu(i, &res);
+ if (cpumask_intersects(threads, &tmp)) {
+ cpu = cpumask_next_and(-1, &tmp, cpu_online_mask);
+ if (cpu < nr_cpu_ids)
+ cpumask_set_cpu(cpu, &res);
+ }
}
return res;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
Hi Jonathan, On Fri, Mar 20, 2015 at 05:57:25PM -0700, Jonathan Richardson wrote: > +config TOUCHSCREEN_IPROC > + tristate "IPROC touch panel driver support" I think this should depend on ARCH_BCM_IPROC || COMPILE_TEST, right? (No need to resubmit). 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: [PATCH 1/1] cifs: potential memory leaks when parsing mnt opts
On Sat, Mar 21, 2015 at 10:23 PM, Taesoo Kim wrote: > On 03/21/15 at 09:10pm, Scott Lovenberg wrote: >> On Sat, Mar 21, 2015 at 6:08 PM, Taesoo Kim wrote: >> >> > Althouhg mkfs.cifs in userspace performs a bit of sanitization >> > (e.g., forcing one user option), current implementation is not >> > robust. Other options such as iocharset and domainanme are similary >> > vulnerable. >> > >> >> I assume you mean mount.cifs? :-) Anyways, good catch. > > Right. FYI, I've tried mangling password field (e.g., pass=a,user=A > &c); Skimming through the code (just a few minutes), there are a few > potential places that don't sanitize its string, unlike passwd. But > don't have much time to play with for now :) > > Thanks, > Taesoo > >> -- >> Peace and Blessings, >> -Scott. Without even looking at the code, I can tell you that's probably my fault if you're talking about the code in mount.cifs. I was pretty paranoid about the password field but not so paranoid about the other parameters. I'll take a look late tonight or some time tomorrow and try to patch over my shame. :) -- Peace and Blessings, -Scott. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.
On Fri, 20 Mar 2015 20:41:50 +0100 Pavel Machek wrote:
> Hi!
>
> (And yes, I now see dts examples, sorry for the noise.)
>
> Acked-by: Pavel Machek
>
> Minor nits below.
>
> > --- /dev/null
> > +++ b/drivers/tty/slave/tty_slave_core.c
> > @@ -0,0 +1,136 @@
> > +/*
> > + * tty-slave-core - device bus for tty slaves
>
> Filename actually uses underscores.
The filename uses underscores because all the filenames in drivers/tty do.
And this isn't a file name, it is more like a module name, and the module
tools treat '-' and '_' as equivalent.
And I prefer hyphen
I looked at other files in drivers/tty and decided noticed that they use
spaces to separate words in this context (novel concept :-) so I've done the
same.
>
> > + container_of(parent, struct tty_slave, dev);
> > + tty->ops = &dev->ops;
> > + }
> > +}
> > +EXPORT_SYMBOL(tty_slave_activate);
>
> Not "_GPL"?
Other exports in the files are just EXPORT_SYMBOL, so I copied.
I don't feel strongly (the code is GPL anyway) so just follow what
surrounding code does.
>
> > +postcore_initcall(tty_slave_init);
> > +module_exit(tty_slave_exit);
>
> Should it have MODULE_LICENSE tag?
Yes. Added.
>
>
> > +int tty_register_finalize(struct tty_driver *driver, struct device *dev)
> > +{
> > + int retval;
> > + bool cdev = false;
> > + int index = dev->devt - MKDEV(driver->major,
> > + driver->minor_start);
> > + printk("REGISTER %d %d 0x%x %d\n", driver->major, driver->minor_start,
> > dev->devt, index);
>
> That printk should probably be removed for merge?
Gone.
>
> > + if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> > + retval = tty_cdev_add(driver,
> > + dev->devt,
> > + index, 1);
>
> You can put this on one line.
Indeed. Done.
>
> > --- /dev/null
> > +++ b/include/linux/tty_slave.h
> > @@ -0,0 +1,26 @@
> > +
> > +struct tty_slave {
> > + struct device *tty_dev;
> > + struct tty_driver *tty_drv;
> > + struct tty_operations ops;
> > + struct device dev;
> > +};
>
> Header files usually have #include guards, and some kind of comment on
> top.
>
> Pavel
Of 1996 files in include/linux, 1851 seem to do that. That's enough to
convince me. I've done it too.
Thanks,
NeilBrown
pgpAJHzwlM30_.pgp
Description: OpenPGP digital signature
[PATCH] Input: ALPS - fix max coordinates for v5 and v7 protocols
Commit 3296f71cd2fde7a2ad52e66a27eae419f6328066 ("Input: ALPS - consolidate
setting protocol parameters") inadvertently moved call to
alps_dolphin_get_device_area() from v5 to v7 protocol, causing both
protocols report incorrect maximum values for X and Y axes which resulted
in crash in Synaptics X driver.
Reported-by: Santiago Gala
Reported-by: Pali Rohár
Signed-off-by: Dmitry Torokhov
---
drivers/input/mouse/alps.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 1bd15eb..33198b9 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2281,10 +2281,12 @@ static int alps_set_protocol(struct psmouse *psmouse,
priv->set_abs_params = alps_set_abs_params_mt;
priv->nibble_commands = alps_v3_nibble_commands;
priv->addr_command = PSMOUSE_CMD_RESET_WRAP;
- priv->x_max = 1360;
- priv->y_max = 660;
priv->x_bits = 23;
priv->y_bits = 12;
+
+ if (alps_dolphin_get_device_area(psmouse, priv))
+ return -EIO;
+
break;
case ALPS_PROTO_V6:
@@ -2303,9 +2305,8 @@ static int alps_set_protocol(struct psmouse *psmouse,
priv->set_abs_params = alps_set_abs_params_mt;
priv->nibble_commands = alps_v3_nibble_commands;
priv->addr_command = PSMOUSE_CMD_RESET_WRAP;
-
- if (alps_dolphin_get_device_area(psmouse, priv))
- return -EIO;
+ priv->x_max = 0xfff;
+ priv->y_max = 0x7ff;
if (priv->fw_ver[1] != 0xba)
priv->flags |= ALPS_BUTTONPAD;
--
2.2.0.rc0.207.ga3a616c
--
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: [PATCH 2/3] TTY: add support for tty_slave devices.
On Wed, 18 Mar 2015 10:11:35 +0100 Paul Bolle wrote: > Just two nits to look into once you get to fix up all the smaller > issues. Thanks. I've fixed both those nits. NeilBrown > > NeilBrown schreef op wo 18-03-2015 om 16:58 [+1100]: > > --- /dev/null > > +++ b/drivers/tty/slave/Kconfig > > @@ -0,0 +1,7 @@ > > +menuconfig TTY_SLAVE > > + tristate "TTY slave devices" > > + depends on OF > > + help > > + Devices which attach via a uart, but need extra > > + driver support for power management etc. > > + > > This blank line makes "git am" whine: "new blank line at EOF". > > > --- /dev/null > > +++ b/drivers/tty/slave/tty_slave_core.c > > [...] > > This file doesn't have a MODULE_LICENSE() macro. So I think that, if > this driver is built as a module and loaded, kernel/module.c will set > its license to "unspecified" and taint the kernel. > > > Paul Bolle > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ pgpmjdgrYInxg.pgp Description: OpenPGP digital signature
Re: [PATCH 1/1] cifs: potential memory leaks when parsing mnt opts
On 03/21/15 at 09:10pm, Scott Lovenberg wrote: > On Sat, Mar 21, 2015 at 6:08 PM, Taesoo Kim wrote: > > > Althouhg mkfs.cifs in userspace performs a bit of sanitization > > (e.g., forcing one user option), current implementation is not > > robust. Other options such as iocharset and domainanme are similary > > vulnerable. > > > > I assume you mean mount.cifs? :-) Anyways, good catch. Right. FYI, I've tried mangling password field (e.g., pass=a,user=A &c); Skimming through the code (just a few minutes), there are a few potential places that don't sanitize its string, unlike passwd. But don't have much time to play with for now :) Thanks, Taesoo > -- > Peace and Blessings, > -Scott. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Net: ethernet: rocker: fixed a space coding style issue
On Sat, Mar 21, 2015 at 11:02 AM, Andrei Maresu wrote: > Fixed a space coding style issue found by checkpatch.pl in rocker.c > > Signed-off-by: Andrei Maresu Signed-off-by: Scott Feldman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch.pl: Add warning for harmful goto labels
On Sat, 2015-03-21 at 23:12 +0100, Richard Weinberger wrote: > Am 21.03.2015 um 23:06 schrieb L. Alberto Giménez: > > There are a lot of cases where a too generic goto label for cleanup > > causes a bug or makes debugging harder. [] > > If something is already in the kernel code, does that mean that it's OK? > > I honestly don't think so, and I think that goto labels for cleanup exit > > paths should be a little more descriptive. > > I disagree. out and exit are perfectly fine labels. I agree with you Richard. While the form of the patch is fine, but content is not. There might be a case for a coccinelle style patch that looks for more than a single label in a function and looks at the label name choices, but I think it'd be pretty dubious at best. > > It's just a proposal for a warning. If it is really not needed, it won't > > be applied and life will go on :) In that case, it'd be nicer to preface the patch subject with RFC > checkpatch.pl is already more than annoying. It used to be a nice tool but > it becomes more and more an harassment for guys who actually work on the > kernel. Richard, what sub-optimal messages do you think checkpatch produces by default? cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ptp/clcok:Introduce the setktime/getktime interfaces with "ktime_t" type
On Saturday 21 March 2015, Richard Cochran wrote: > On Sat, Mar 21, 2015 at 02:16:41AM +0100, Arnd Bergmann wrote: > > This was the first idea, but it seems a bit silly when all the drivers > > use a 64-bit nanosecond value just like ktime_t. > > Not true of all drivers. In fact, the most capable devices (phyter > and i210) have a split representation. Ok, sorry for missing those earlier, I thought I'd looked at all of them and not found any that did it like this. > > but it is not any more > > or less efficient than the previous method. > > Right, so no point in changing it. > > > Of course, but it would be rather bad style. > > Introducing useless code just to remove it again is also bad style. > > I disagree with the approach presented here. The problem at hand is > the 2038 issue. Let's fix that first, in the easiest way, with the > least churn, namely by using timespec64 in place of timespec. Once > that is done, we can change over to ktime_t, if and when the need > arises. Ok, fair enough. I only saw this mail now after replying on the longer series, consider my comment on ktime_t withdrawn. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V2 00/23] ptp: get ready for 2038
On Saturday 21 March 2015, Richard Cochran wrote: > This series converts the core driver methods of the PTP Hardware Clock > (PHC) subsystem to use the 64 bit version of the timespec structure, > making the core API ready for the year 2038. > > In addition, I reviewed how each driver and device represents the time > value at the hardware register level. Most of the drivers are ready, > but a few will need some work before the year 2038, as shown: > >Patch Driver > >12 drivers/net/ethernet/intel/igb/igb_ptp.c >15 ?drivers/net/ethernet/sfc/ptp.c >16 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c >18 ?drivers/net/ethernet/tile/tilegx.c >19 drivers/net/phy/dp83640.c > > The commit log message documents how each driver is ready or why it is > not ready. For patches 15 and 18, I could not easily find out the > hardware representation of the time value, so I would ask the > maintainers for a review. Very nice, thanks for joining in with the effort. I've commented on a few smaller issues on individual patches. Overall, I think we'd be slightly better off changing the type to ktime_t for the interface, the main downside of that being that we'd need to change a bit more code. You'd still need to do the same kind of conversion, so the difference would be very minor in the end though, so I'm fine with whichever way you decide as the subsystem maintainer. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V2 13/23] ptp: igb: convert to the 64 bit get/set time methods.
On Saturday 21 March 2015, Richard Cochran wrote: > @@ -269,13 +270,13 @@ static int igb_ptp_adjtime_i210(struct ptp_clock_info > *ptp, s64 delta) > struct igb_adapter *igb = container_of(ptp, struct igb_adapter, >ptp_caps); > unsigned long flags; > - struct timespec now, then = ns_to_timespec(delta); > + struct timespec64 now, then = ns_to_timespec64(delta); > > spin_lock_irqsave(&igb->tmreg_lock, flags); > > igb_ptp_read_i210(igb, &now); > - now = timespec_add(now, then); > - igb_ptp_write_i210(igb, (const struct timespec *)&now); > + now = timespec64_add(now, then); > + igb_ptp_write_i210(igb, (const struct timespec64 *)&now); > > spin_unlock_irqrestore(&igb->tmreg_lock, flags); > This is one of the functions that would actually become more efficient if the argument type gets changed to ktime_t. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V2 20/23] ptp: dp83640: convert to the 64 bit get/set time methods.
On Saturday 21 March 2015, Richard Cochran wrote: > mutex_lock(&clock->extreg_lock); > > - err = tdr_write(1, phydev, ts, PTP_LOAD_CLK); > + err = tdr_write(1, phydev, &ts, PTP_LOAD_CLK); > > mutex_unlock(&clock->extreg_lock); I don't see the change to the tdr_write() function that changes the argument from 'struct timespec ts' to 'struct timespec64 *', so this looks wrong to me. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/18] net: dsa: HW bridging, EEE support
On 03/21/2015 07:14 PM, David Miller wrote: From: Guenter Roeck Date: Sat, 21 Mar 2015 16:12:30 -0700 Yes, agreed. It is on the to-do list. Should we be more aggressive ? Since I'll have to resubmit anyway, we could start by adding defines for all constants used in this patch set, not just some of them. As long as you'll really take care of this afterwards, you can take care of the defines after this series is integrated. Definitely. But I agree with Andrew, I would prefer to do it after this and Andrew's next set of patches has been accepted. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V2 04/23] ptp: blackfin: convert to the 64 bit get/set time methods.
On Saturday 21 March 2015, Richard Cochran wrote:
> -static int bfin_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
> +static int bfin_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64
> *ts)
> {
> u64 ns;
> u32 remainder;
I think it would be good to replace the open-coded
ns = ts->tv_sec * 10ULL;
ns += ts->tv_nsec;
here with a call to ns_to_timespec64(), here and in other drivers that you
are already touching.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Driver for pxa architectures
On Saturday 21 March 2015, Robert Jarzmik wrote: > It is as well one of the last steps (or so I hope) for pxa architure to be > part > of the multiplatform ARM architecture, and at the same time keep its legacy > platforms operational. It will kill arch/arm/plat-pxa/dma.c in the long term. > Hi Robert, as much as I like this series, I think you still have a long way to go before PXA can really be multiplatform. Other parts that would need to be solved include the various cpu_is_pxa*() checks in drivers, the per-board header files, the way that the I/O space is mapped in the PCMCIA drivers and the XIP support. I think all of them are theoretically doable, but I wasn't expecting to ever get there. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/18] net: dsa: HW bridging, EEE support
From: Guenter Roeck Date: Sat, 21 Mar 2015 16:12:30 -0700 > Yes, agreed. It is on the to-do list. Should we be more aggressive ? > Since I'll have to resubmit anyway, we could start by adding defines > for all constants used in this patch set, not just some of them. As long as you'll really take care of this afterwards, you can take care of the defines after this series is integrated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Drbd-dev] [PATCH] drbd: use bitmap_weight()
2015-03-21 0:14 GMT+09:00 Lars Ellenberg : > On Sat, Mar 14, 2015 at 10:12:56AM +0900, Akinobu Mita wrote: >> Use bitmap_weight to count the total number of bits set in bitmap. >> This change just simplifies the code a bit. > > "Simplifies", not sure about that, but ok, maybe. > > For the "bm_set_full_words_within_one_page", I disagree. > I think it is more cpu cache friendly to hweight_long then set to ~0UL > each word in turn, than to first bitmap_weight() all words, then > bitmap_fill() all words. I see. I'll remove the change in bm_set_full_words_within_one_page(). > Thanks, > > Lars Ellenberg > > BTW, you swapped names and email addresses of phil and me. Are those > listed incorrectly somewhere, or was that just a mishap on your part? It's just my mistake. I copied your names from MAINTAINERS, but it doesn't list your email addresses then I incorrectly swapped while retrieving email addrsses from git log. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] cifs: potential memory leaks when parsing mnt opts
On Sat, Mar 21, 2015 at 6:08 PM, Taesoo Kim wrote: > Althouhg mkfs.cifs in userspace performs a bit of sanitization > (e.g., forcing one user option), current implementation is not > robust. Other options such as iocharset and domainanme are similary > vulnerable. > I assume you mean mount.cifs? :-) Anyways, good catch. -- Peace and Blessings, -Scott. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] scsi: storvsc: Increase the tablesize based on host's capabilities
> -Original Message- > From: KY Srinivasan > Sent: Monday, March 16, 2015 4:45 PM > To: 'K. Y. Srinivasan'; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; > jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org; > a...@canonical.com; vkuzn...@redhat.com > Subject: RE: [PATCH 0/3] scsi: storvsc: Increase the tablesize based on host's > capabilities > > > > > -Original Message- > > From: K. Y. Srinivasan [mailto:k...@microsoft.com] > > Sent: Monday, March 9, 2015 8:42 PM > > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org; oher...@suse.com; > > jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org; > > a...@canonical.com; vkuzn...@redhat.com > > Cc: KY Srinivasan > > Subject: [PATCH 0/3] scsi: storvsc: Increase the tablesize based on host's > > capabilities > > > > Presently, storvsc limits the I/O size arbitrarily. Make this configurable > based > > on what the host advertises. > > > > K. Y. Srinivasan (3): > > scsi: storvsc: Retrieve information about the capability of the > > target > > scsi: storvsc: Set the tablesize based on the information given by > > the host > > scsi: storvsc: Enable clustering > > > > drivers/scsi/storvsc_drv.c | 78 > > +++- > > 1 files changed, 62 insertions(+), 16 deletions(-) > > Christoph, > > Let me know if I should resend these patches. > > Regards, Christoph, Please drop this set. I will resend the patches with a couple of additional patches that need to go in before I can enable clustering. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"
On 06.03.2015 19:20, Lino Sanfilippo wrote: > >>> >> >> Ok, I got a link to the source now. It can be found here: >> >> http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 >> > > > Sigh. Just realized that the url is not accessible. Will check that on > monday. > > Lino > Hello Dave, sorry for my late reply. But I was a few days out of office and had to contact some people which are not in my departement. The outcome is: there is no public repository in which the source code of that special (buggy) toolchain is available any more. There are newer versions already, but even for those the source code is only accessible for customers (thats what I was told). However the responsible developer could confirm that the wrong alignment I initially reported is indeed a bug in the toolchain which now is fixed in the newer versions. I really would have liked to send you the source, but unfortunately I cant. However thanks again for all your help. Regards, Lino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: mach-omap2: remove superfluous NULL pointer check
The NULL pointer check for superset->muxnames will always evaluate
true since muxnames is an array within struct omap_mux. Remove the
superfluous check to avoid warnings when using LLVM/clang.
Signed-off-by: Stefan Agner
---
For the reference, the warning generated by LLVM/clang:
arch/arm/mach-omap2/mux.c:1056:18: warning: address of array
'superset->muxnames' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (!superset->muxnames || !superset->muxnames[0]) {
~~~^~~~
arch/arm/mach-omap2/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 78064b0..176eef6 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -1053,7 +1053,7 @@ static void __init omap_mux_init_list(struct
omap_mux_partition *partition,
struct omap_mux *entry;
#ifdef CONFIG_OMAP_MUX
- if (!superset->muxnames || !superset->muxnames[0]) {
+ if (!superset->muxnames[0]) {
superset++;
continue;
}
--
2.3.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] dmaengine: ste_dma40: fix implicit conversion
The function d40_prep_sg takes the type enum dma_transfer_direction as second last parameter. However, the memcpy calls pass DMA_NONE which is of type enum dma_data_direction. Fix this by passing the actual transfer direction DMA_MEM_TO_MEM. This does not change the actual code flow since only the transfer direction DMA_MEM_TO_DEV and DMA_DEV_TO_MEM are actually used in the function d40_prep_sg. Signed-off-by: Stefan Agner --- This was uncovered by a LLVM/clang warnings: drivers/dma/ste_dma40.c:2505:48: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] return d40_prep_sg(chan, &src_sg, &dst_sg, 1, DMA_NONE, dma_flags); ~~~^~~~ drivers/dma/ste_dma40.c:2517:54: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] return d40_prep_sg(chan, src_sg, dst_sg, src_nents, DMA_NONE, dma_flags); ~~~ ^~~~ drivers/dma/ste_dma40.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c index 15d4946..ace03dc 100644 --- a/drivers/dma/ste_dma40.c +++ b/drivers/dma/ste_dma40.c @@ -2502,7 +2502,8 @@ static struct dma_async_tx_descriptor *d40_prep_memcpy(struct dma_chan *chan, sg_dma_len(&dst_sg) = size; sg_dma_len(&src_sg) = size; - return d40_prep_sg(chan, &src_sg, &dst_sg, 1, DMA_NONE, dma_flags); + return d40_prep_sg(chan, &src_sg, &dst_sg, 1, + DMA_MEM_TO_MEM, dma_flags); } static struct dma_async_tx_descriptor * @@ -2514,7 +2515,8 @@ d40_prep_memcpy_sg(struct dma_chan *chan, if (dst_nents != src_nents) return NULL; - return d40_prep_sg(chan, src_sg, dst_sg, src_nents, DMA_NONE, dma_flags); + return d40_prep_sg(chan, src_sg, dst_sg, src_nents, + DMA_MEM_TO_MEM, dma_flags); } static struct dma_async_tx_descriptor * -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: cygnus: fix const declaration bcm_cygnus_dt_compat
The const declaration for char* is actually duplicated, however
the array of strings is currently not constant. However, typically
the dt_compat array is declared as const char *const. Follow
that convention and also add the __initconst macro for constant
initialization data.
Signed-off-by: Stefan Agner
---
This was uncovered by a LLVM/clang warning:
arch/arm/mach-bcm/bcm_cygnus.c:16:19: warning: duplicate 'const' declaration
specifier [-Wduplicate-decl-specifier]
static const char const *bcm_cygnus_dt_compat[] = {
^~
1 warning generated.
arch/arm/mach-bcm/bcm_cygnus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-bcm/bcm_cygnus.c b/arch/arm/mach-bcm/bcm_cygnus.c
index 30dc58b..7ae894c 100644
--- a/arch/arm/mach-bcm/bcm_cygnus.c
+++ b/arch/arm/mach-bcm/bcm_cygnus.c
@@ -13,7 +13,7 @@
#include
-static const char const *bcm_cygnus_dt_compat[] = {
+static const char * const bcm_cygnus_dt_compat[] __initconst = {
"brcm,cygnus",
NULL,
};
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/18] net: dsa: HW bridging, EEE support
> >But this driver would be so much easier to read and understand if it > >used mnemonics instead of constants for the register offsets. > > > > Yes, agreed. It is on the to-do list. Should we be more aggressive ? > Since I'll have to resubmit anyway, we could start by adding defines > for all constants used in this patch set, not just some of them. It may make more sense to remove a lot of the duplicate code first. I have patches which centralises all the switch reset and PHY access. It should also be possible to centralise the statistics code. At a rough guess, that is going to remove 50% of each driver. Quite a bit of the remainder can also be centralised, but there is where the drivers actually start to differ, and so will take more effort. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: pxa_camera: conversion to dmaengine
From: Robert Jarzmik
Convert pxa_camera to dmaengine. This removes all DMA registers
manipulation in favor of the more generic dmaengine API.
The functional level should be the same as before. The biggest change is
in the videobuf_sg_splice() function, which splits a videobuf-dma into
several scatterlists for 3 planes captures (Y, U, V).
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 428 -
1 file changed, 211 insertions(+), 217 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 8b39f44..8644022 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -38,7 +41,6 @@
#include
-#include
#include
#define PXA_CAM_VERSION "0.0.6"
@@ -175,21 +177,16 @@ enum pxa_camera_active_dma {
DMA_V = 0x4,
};
-/* descriptor needed for the PXA DMA engine */
-struct pxa_cam_dma {
- dma_addr_t sg_dma;
- struct pxa_dma_desc *sg_cpu;
- size_t sg_size;
- int sglen;
-};
-
/* buffer for one video frame */
struct pxa_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
u32 code;
/* our descriptor lists for Y, U and V channels */
- struct pxa_cam_dma dmas[3];
+ struct dma_async_tx_descriptor *descs[3];
+ dma_cookie_tcookie[3];
+ struct scatterlist *sg[3];
+ int sg_len[3];
int inwork;
enum pxa_camera_active_dma active_dma;
};
@@ -207,7 +204,7 @@ struct pxa_camera_dev {
void __iomem*base;
int channels;
- unsigned intdma_chans[3];
+ struct dma_chan *dma_chans[3];
struct pxacamera_platform_data *pdata;
struct resource *res;
@@ -222,7 +219,6 @@ struct pxa_camera_dev {
spinlock_t lock;
struct pxa_buffer *active;
- struct pxa_dma_desc *sg_tail[3];
struct tasklet_struct task_eof;
u32 save_cicr[5];
@@ -259,7 +255,6 @@ static int pxa_videobuf_setup(struct videobuf_queue *vq,
unsigned int *count,
static void free_buffer(struct videobuf_queue *vq, struct pxa_buffer *buf)
{
struct soc_camera_device *icd = vq->priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct videobuf_dmabuf *dma = videobuf_to_dma(&buf->vb);
int i;
@@ -276,41 +271,82 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
if (buf->vb.state == VIDEOBUF_NEEDS_INIT)
return;
- for (i = 0; i < ARRAY_SIZE(buf->dmas); i++) {
- if (buf->dmas[i].sg_cpu)
- dma_free_coherent(ici->v4l2_dev.dev,
- buf->dmas[i].sg_size,
- buf->dmas[i].sg_cpu,
- buf->dmas[i].sg_dma);
- buf->dmas[i].sg_cpu = NULL;
+ for (i = 0; i < 3 && buf->descs[i]; i++) {
+ async_tx_ack(buf->descs[i]);
+ dmaengine_tx_release(buf->descs[i]);
+ kfree(buf->sg[i]);
+ buf->descs[i] = NULL;
+ buf->sg[i] = NULL;
+ buf->sg_len[i] = 0;
}
videobuf_dma_unmap(vq->dev, dma);
videobuf_dma_free(dma);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
+
+ dev_dbg(icd->parent, "%s end (vb=0x%p) 0x%08lx %d\n", __func__,
+ &buf->vb, buf->vb.baddr, buf->vb.bsize);
}
-static int calculate_dma_sglen(struct scatterlist *sglist, int sglen,
- int sg_first_ofs, int size)
+static struct scatterlist *videobuf_sg_splice(struct scatterlist *sglist,
+ int sglen, int offset, int size,
+ int *new_sg_len)
{
- int i, offset, dma_len, xfer_len;
- struct scatterlist *sg;
+ struct scatterlist *sg0, *sg, *sg_first = NULL;
+ int i, dma_len, dropped_xfer_len, dropped_remain, remain;
+ int nfirst = -1, nfirst_offset = 0, xfer_len;
- offset = sg_first_ofs;
+ *new_sg_len = 0;
+ dropped_remain = offset;
+ remain = size;
for_each_sg(sglist, sg, sglen, i) {
dma_len = sg_dma_len(sg);
-
/* PXA27x Developer's Manual 27.4.4.1: round up to 8 bytes */
- xfer_len = roundup(min(dma_len - offset, size), 8);
+ dropped_xfer_len = roundup(min(dma_len, dropped_remain), 8);
+ if (dropped_remain)
[PATCH v3 1/3] iio: adc: vf610: use ADC clock within specification
Depending on conversion mode used, the ADC clock (ADCK) needs
to be below a maximum frequency. According to Vybrid's data
sheet this is 20MHz for the low power conversion mode.
The ADC clock is depending on input clock, which is the bus
clock by default. Vybrid SoC are typically clocked at at 400MHz
or 500MHz, which leads to 66MHz or 83MHz bus clock respectively.
Hence, a divider of 8 is required to stay below the specified
maximum clock of 20MHz.
Due to the different bus clock speeds, the resulting sampling
frequency is not static. Hence use the ADC clock and calculate
the actual available sampling frequency dynamically.
This fixes bogous values observed on some 500MHz clocked Vybrid
SoC. The resulting value usually showed Bit 9 being stuck at 1,
or 0, which lead to a value of +/-512.
Acked-by: Fugang Duan
Signed-off-by: Stefan Agner
---
drivers/iio/adc/vf610_adc.c | 91 ++---
1 file changed, 61 insertions(+), 30 deletions(-)
diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
index 8ec353c..e63b8e7 100644
--- a/drivers/iio/adc/vf610_adc.c
+++ b/drivers/iio/adc/vf610_adc.c
@@ -141,9 +141,13 @@ struct vf610_adc {
struct regulator *vref;
struct vf610_adc_feature adc_feature;
+ u32 sample_freq_avail[5];
+
struct completion completion;
};
+static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
+
#define VF610_ADC_CHAN(_idx, _chan_type) { \
.type = (_chan_type), \
.indexed = 1, \
@@ -180,35 +184,47 @@ static const struct iio_chan_spec
vf610_adc_iio_channels[] = {
/* sentinel */
};
-/*
- * ADC sample frequency, unit is ADCK cycles.
- * ADC clk source is ipg clock, which is the same as bus clock.
- *
- * ADC conversion time = SFCAdder + AverageNum x (BCT + LSTAdder)
- * SFCAdder: fixed to 6 ADCK cycles
- * AverageNum: 1, 4, 8, 16, 32 samples for hardware average.
- * BCT (Base Conversion Time): fixed to 25 ADCK cycles for 12 bit mode
- * LSTAdder(Long Sample Time): fixed to 3 ADCK cycles
- *
- * By default, enable 12 bit resolution mode, clock source
- * set to ipg clock, So get below frequency group:
- */
-static const u32 vf610_sample_freq_avail[5] =
-{1941176, 559332, 286957, 145374, 73171};
+static inline void vf610_adc_calculate_rates(struct vf610_adc *info)
+{
+ unsigned long adck_rate, ipg_rate = clk_get_rate(info->clk);
+ int i;
+
+ /*
+* Calculate ADC sample frequencies
+* Sample time unit is ADCK cycles. ADCK clk source is ipg clock,
+* which is the same as bus clock.
+*
+* ADC conversion time = SFCAdder + AverageNum x (BCT + LSTAdder)
+* SFCAdder: fixed to 6 ADCK cycles
+* AverageNum: 1, 4, 8, 16, 32 samples for hardware average.
+* BCT (Base Conversion Time): fixed to 25 ADCK cycles for 12 bit mode
+* LSTAdder(Long Sample Time): fixed to 3 ADCK cycles
+*/
+ adck_rate = ipg_rate / info->adc_feature.clk_div;
+ for (i = 0; i < ARRAY_SIZE(vf610_hw_avgs); i++)
+ info->sample_freq_avail[i] =
+ adck_rate / (6 + vf610_hw_avgs[i] * (25 + 3));
+}
static inline void vf610_adc_cfg_init(struct vf610_adc *info)
{
+ struct vf610_adc_feature *adc_feature = &info->adc_feature;
+
/* set default Configuration for ADC controller */
- info->adc_feature.clk_sel = VF610_ADCIOC_BUSCLK_SET;
- info->adc_feature.vol_ref = VF610_ADCIOC_VR_VREF_SET;
+ adc_feature->clk_sel = VF610_ADCIOC_BUSCLK_SET;
+ adc_feature->vol_ref = VF610_ADCIOC_VR_VREF_SET;
+
+ adc_feature->calibration = true;
+ adc_feature->ovwren = true;
+
+ adc_feature->res_mode = 12;
+ adc_feature->sample_rate = 1;
+ adc_feature->lpm = true;
- info->adc_feature.calibration = true;
- info->adc_feature.ovwren = true;
+ /* Use a save ADCK which is below 20MHz on all devices */
+ adc_feature->clk_div = 8;
- info->adc_feature.clk_div = 1;
- info->adc_feature.res_mode = 12;
- info->adc_feature.sample_rate = 1;
- info->adc_feature.lpm = true;
+ vf610_adc_calculate_rates(info);
}
static void vf610_adc_cfg_post_set(struct vf610_adc *info)
@@ -290,12 +306,10 @@ static void vf610_adc_cfg_set(struct vf610_adc *info)
cfg_data = readl(info->regs + VF610_REG_ADC_CFG);
- /* low power configuration */
cfg_data &= ~VF610_ADC_ADLPC_EN;
if (adc_feature->lpm)
cfg_data |= VF610_ADC_ADLPC_EN;
- /* disable high speed */
cfg_data &= ~VF610_ADC_ADHSC_EN;
writel(cfg_data, info->regs + VF610_REG_ADC_CFG);
@@ -435,10 +449,27 @@ static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("1941176, 559332, 286957, 145374,
73171");
+static ssize_t vf610_show
[PATCH 2/4] media: pxa_camera: move interrupt to tasklet
From: Robert Jarzmik
In preparation for dmaengine conversion, move the camera interrupt
handling into a tasklet. This won't change the global flow, as this
interrupt is only used to detect the end of frame and activate DMA fifos
handling.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 44 +-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 3ca33f0..c0c0f0f 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -223,6 +223,7 @@ struct pxa_camera_dev {
struct pxa_buffer *active;
struct pxa_dma_desc *sg_tail[3];
+ struct tasklet_struct task_eof;
u32 save_cicr[5];
};
@@ -605,6 +606,7 @@ static void pxa_camera_start_capture(struct pxa_camera_dev
*pcdev)
unsigned long cicr0;
dev_dbg(pcdev->soc_host.v4l2_dev.dev, "%s\n", __func__);
+ __raw_writel(__raw_readl(pcdev->base + CISR), pcdev->base + CISR);
/* Enable End-Of-Frame Interrupt */
cicr0 = __raw_readl(pcdev->base + CICR0) | CICR0_ENB;
cicr0 &= ~CICR0_EOFM;
@@ -922,13 +924,35 @@ static void pxa_camera_deactivate(struct pxa_camera_dev
*pcdev)
clk_disable_unprepare(pcdev->clk);
}
-static irqreturn_t pxa_camera_irq(int irq, void *data)
+static void pxa_camera_eof(unsigned long arg)
{
- struct pxa_camera_dev *pcdev = data;
- unsigned long status, cifr, cicr0;
+ struct pxa_camera_dev *pcdev = (struct pxa_camera_dev *)arg;
+ unsigned long cifr;
struct pxa_buffer *buf;
struct videobuf_buffer *vb;
+ dev_dbg(pcdev->soc_host.v4l2_dev.dev,
+ "Camera interrupt status 0x%x\n",
+ __raw_readl(pcdev->base + CISR));
+
+ /* Reset the FIFOs */
+ cifr = __raw_readl(pcdev->base + CIFR) | CIFR_RESET_F;
+ __raw_writel(cifr, pcdev->base + CIFR);
+
+ pcdev->active = list_first_entry(&pcdev->capture,
+struct pxa_buffer, vb.queue);
+ vb = &pcdev->active->vb;
+ buf = container_of(vb, struct pxa_buffer, vb);
+ pxa_videobuf_set_actdma(pcdev, buf);
+
+ pxa_dma_start_channels(pcdev);
+}
+
+static irqreturn_t pxa_camera_irq(int irq, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+ unsigned long status, cicr0;
+
status = __raw_readl(pcdev->base + CISR);
dev_dbg(pcdev->soc_host.v4l2_dev.dev,
"Camera interrupt status 0x%lx\n", status);
@@ -939,20 +963,9 @@ static irqreturn_t pxa_camera_irq(int irq, void *data)
__raw_writel(status, pcdev->base + CISR);
if (status & CISR_EOF) {
- /* Reset the FIFOs */
- cifr = __raw_readl(pcdev->base + CIFR) | CIFR_RESET_F;
- __raw_writel(cifr, pcdev->base + CIFR);
-
- pcdev->active = list_first_entry(&pcdev->capture,
- struct pxa_buffer, vb.queue);
- vb = &pcdev->active->vb;
- buf = container_of(vb, struct pxa_buffer, vb);
- pxa_videobuf_set_actdma(pcdev, buf);
-
- pxa_dma_start_channels(pcdev);
-
cicr0 = __raw_readl(pcdev->base + CICR0) | CICR0_EOFM;
__raw_writel(cicr0, pcdev->base + CICR0);
+ tasklet_schedule(&pcdev->task_eof);
}
return IRQ_HANDLED;
@@ -1834,6 +1847,7 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->soc_host.priv= pcdev;
pcdev->soc_host.v4l2_dev.dev= &pdev->dev;
pcdev->soc_host.nr = pdev->id;
+ tasklet_init(&pcdev->task_eof, pxa_camera_eof, (unsigned long)pcdev);
err = soc_camera_host_register(&pcdev->soc_host);
if (err)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] iio: adc: vf610: implement configurable conversion modes
Support configurable conversion mode through sysfs. So far, the
mode used was low-power, which is enabled by default now. Beside
that, the modes normal and high-speed are selectable as well.
Use the new device tree property which specifies the maximum ADC
conversion clock frequencies. Depending on the mode used, the
available resulting conversion frequency are calculated
dynamically.
Acked-by: Fugang Duan
Signed-off-by: Stefan Agner
---
Documentation/ABI/testing/sysfs-bus-iio-vf610 | 7 ++
drivers/iio/adc/vf610_adc.c | 146 ++
2 files changed, 111 insertions(+), 42 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-vf610
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-vf610
b/Documentation/ABI/testing/sysfs-bus-iio-vf610
new file mode 100644
index 000..85fd0ecd5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-vf610
@@ -0,0 +1,7 @@
+What: /sys/bus/iio/devices/iio:deviceX/conversion_mode
+KernelVersion: 4.1
+Contact: linux-...@vger.kernel.org
+Description:
+ Specifies the hardware conversion mode used. The three
+ available modes are "normal", "high-speed" and "low-power",
+ whereas the last is the default mode.
diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
index e63b8e7..b5f94ab8 100644
--- a/drivers/iio/adc/vf610_adc.c
+++ b/drivers/iio/adc/vf610_adc.c
@@ -118,15 +118,21 @@ enum average_sel {
VF610_ADC_SAMPLE_32,
};
+enum conversion_mode_sel {
+ VF610_ADC_CONV_NORMAL,
+ VF610_ADC_CONV_HIGH_SPEED,
+ VF610_ADC_CONV_LOW_POWER,
+};
+
struct vf610_adc_feature {
enum clk_selclk_sel;
enum vol_refvol_ref;
+ enum conversion_mode_sel conv_mode;
int clk_div;
int sample_rate;
int res_mode;
- boollpm;
boolcalibration;
boolovwren;
};
@@ -139,6 +145,8 @@ struct vf610_adc {
u32 vref_uv;
u32 value;
struct regulator *vref;
+
+ u32 max_adck_rate[3];
struct vf610_adc_feature adc_feature;
u32 sample_freq_avail[5];
@@ -148,46 +156,22 @@ struct vf610_adc {
static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
-#define VF610_ADC_CHAN(_idx, _chan_type) { \
- .type = (_chan_type), \
- .indexed = 1, \
- .channel = (_idx), \
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) | \
- BIT(IIO_CHAN_INFO_SAMP_FREQ), \
-}
-
-#define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
- .type = (_chan_type), \
- .channel = (_idx), \
- .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
-}
-
-static const struct iio_chan_spec vf610_adc_iio_channels[] = {
- VF610_ADC_CHAN(0, IIO_VOLTAGE),
- VF610_ADC_CHAN(1, IIO_VOLTAGE),
- VF610_ADC_CHAN(2, IIO_VOLTAGE),
- VF610_ADC_CHAN(3, IIO_VOLTAGE),
- VF610_ADC_CHAN(4, IIO_VOLTAGE),
- VF610_ADC_CHAN(5, IIO_VOLTAGE),
- VF610_ADC_CHAN(6, IIO_VOLTAGE),
- VF610_ADC_CHAN(7, IIO_VOLTAGE),
- VF610_ADC_CHAN(8, IIO_VOLTAGE),
- VF610_ADC_CHAN(9, IIO_VOLTAGE),
- VF610_ADC_CHAN(10, IIO_VOLTAGE),
- VF610_ADC_CHAN(11, IIO_VOLTAGE),
- VF610_ADC_CHAN(12, IIO_VOLTAGE),
- VF610_ADC_CHAN(13, IIO_VOLTAGE),
- VF610_ADC_CHAN(14, IIO_VOLTAGE),
- VF610_ADC_CHAN(15, IIO_VOLTAGE),
- VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
- /* sentinel */
-};
-
static inline void vf610_adc_calculate_rates(struct vf610_adc *info)
{
+ struct vf610_adc_feature *adc_feature = &info->adc_feature;
unsigned long adck_rate, ipg_rate = clk_get_rate(info->clk);
- int i;
+ int divisor, i;
+
+ adck_rate = info->max_adck_rate[adc_feature->conv_mode];
+
+ if (adck_rate) {
+ /* calculate clk divider which is within specification */
+ divisor = ipg_rate / adck_rate;
+ adc_feature->clk_div = 1 << fls(divisor + 1);
+ } else {
+ /* fall-back value using a safe divisor */
+ adc_feature->clk_div = 8;
+ }
/*
* Calculate ADC sample frequencies
@@ -219,10 +203,8 @@ static inline void vf610_adc_cfg_init(struct vf610_adc
*info)
adc_feature->res_mode = 12;
adc_feature->sample_rate = 1;
- adc_feature->lpm = true;
- /* Use a save ADCK which is below 20MHz on all devices */
- adc_feature->clk_div = 8;
+ adc_feature->conv_mode = VF610_ADC_CONV_LOW_POWER;
vf610_adc_calculate_rates(info);
}
@@ -307,10 +289,12 @@ static void vf610_adc_cfg_set(struct vf610_adc *info)
cfg_data = readl(info->regs + VF610_REG_ADC_CFG);
Re: [PATCH v6 09/30] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
On 3/8/15 21:34, Yijing Wang wrote:
This patch separate pci_host_bridge creation out
of pci_create_root_bus(), and try to make a generic
pci_host_bridge, then we could place generic PCI
infos like domain number in it. Also Ripping out
pci_host_bridge creation from pci_create_root_bus()
make code more better readability. Further more,
we could use the generic pci_host_bridge to hold
host bridge specific operations like
pcibios_root_bridge_prepare(). The changes are
transparent to platform host bridge drivers.
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
---
drivers/pci/host-bridge.c | 55 ++
drivers/pci/pci.h |3 +
drivers/pci/probe.c | 114 -
include/linux/pci.h |1 +
4 files changed, 109 insertions(+), 64 deletions(-)
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 39b2dbe..3bd45e7 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -8,6 +8,61 @@
#include "pci.h"
+static void pci_release_host_bridge_dev(struct device *dev)
+{
+ struct pci_host_bridge *bridge = to_pci_host_bridge(dev);
+
+ if (bridge->release_fn)
+ bridge->release_fn(bridge);
+
+ pci_free_resource_list(&bridge->windows);
+ kfree(bridge);
+}
+
+struct pci_host_bridge *pci_create_host_bridge(
+ struct device *parent, u32 db, struct list_head *resources)
+{
+ int error;
+ int bus = PCI_BUSNUM(db);
+ int domain = PCI_DOMAIN(db);
+ struct pci_host_bridge *host;
+ struct resource_entry *window, *n;
+
+ host = kzalloc(sizeof(*host), GFP_KERNEL);
+ if (!host)
+ return NULL;
+
+ host->busnum = bus;
+ host->domain = domain;
+ /* If support CONFIG_PCI_DOMAINS_GENERIC, use
+* pci_host_assign_domain_nr() to assign domain
+* number instead PCI_DOMAIN(db).
+*/
+ pci_host_assign_domain_nr(host);
At this point, host->dev.parent has not been assigned. However, when
calling pci_host_assign_domain_nr(host), it calls
pci_assign_domain_nr(host->dev.parent), which uses parent->of_node
directly w/o checking if parent is NULL. This ended up causing NULL
pointer exception when I do the test.
I think we need to moveo host->dev.parent = parent before calling
pci_host_assign_domain_nr(host).
Thanks,
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/
[PATCH v3 3/3] ARM: dts: add property for maximum ADC clock frequencies
The ADC clock frequency is limited depending on modes used. Add
device tree property which allow to set the mode used and the
maximum frequency ratings for the instance. These allows to
set the ADC clock to a frequency which is within specification
according to the actual mode used.
Acked-by: Fugang Duan
Signed-off-by: Stefan Agner
---
Documentation/devicetree/bindings/iio/adc/vf610-adc.txt | 9 +
arch/arm/boot/dts/vfxxx.dtsi| 4
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
index 1a4a43d..3eb40e2 100644
--- a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
@@ -11,6 +11,13 @@ Required properties:
- clock-names: Must contain "adc", matching entry in the clocks property.
- vref-supply: The regulator supply ADC reference voltage.
+Recommended properties:
+- fsl,adck-max-frequency: Maximum frequencies according to datasheets operating
+ requirements. Three values are required, depending on conversion mode:
+ - Frequency in normal mode (ADLPC=0, ADHSC=0)
+ - Frequency in high-speed mode (ADLPC=0, ADHSC=1)
+ - Frequency in low-power mode (ADLPC=1, ADHSC=0)
+
Example:
adc0: adc@4003b000 {
compatible = "fsl,vf610-adc";
@@ -18,5 +25,7 @@ adc0: adc@4003b000 {
interrupts = <0 53 0x04>;
clocks = <&clks VF610_CLK_ADC0>;
clock-names = "adc";
+ fsl,adck-max-frequency = <3000>, <4000>,
+ <2000>;
vref-supply = <®_vcc_3v3_mcu>;
};
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a29c7ce..c6609bd 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -189,6 +189,8 @@
clocks = <&clks VF610_CLK_ADC0>;
clock-names = "adc";
status = "disabled";
+ fsl,adck-max-frequency = <3000>, <4000>,
+ <2000>;
};
wdoga5: wdog@4003e000 {
@@ -387,6 +389,8 @@
clocks = <&clks VF610_CLK_ADC1>;
clock-names = "adc";
status = "disabled";
+ fsl,adck-max-frequency = <3000>, <4000>,
+ <2000>;
};
esdhc1: esdhc@400b2000 {
--
2.3.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/4] media: pxa_camera: trivial move of dma irq functions
From: Robert Jarzmik
This moves the dma irq handling functions up in the source file, so that
they are available before DMA preparation functions. It prepares the
conversion to DMA engine, where the descriptors are populated with these
functions as callbacks.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 40 ++
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index c0c0f0f..8b39f44 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -311,6 +311,28 @@ static int calculate_dma_sglen(struct scatterlist *sglist,
int sglen,
BUG_ON(size != 0);
return i + 1;
+static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
+ enum pxa_camera_active_dma act_dma);
+
+static void pxa_camera_dma_irq_y(void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_Y);
+}
+
+static void pxa_camera_dma_irq_u(void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_U);
+}
+
+static void pxa_camera_dma_irq_v(void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_V);
}
/**
@@ -810,24 +832,6 @@ out:
spin_unlock_irqrestore(&pcdev->lock, flags);
}
-static void pxa_camera_dma_irq_y(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_Y);
-}
-
-static void pxa_camera_dma_irq_u(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_U);
-}
-
-static void pxa_camera_dma_irq_v(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_V);
-}
-
static struct videobuf_queue_ops pxa_videobuf_ops = {
.buf_setup = pxa_videobuf_setup,
.buf_prepare= pxa_videobuf_prepare,
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] iio: adc: vf610: respect ADC clocking limitations
Respect ADC clocking limitations which lead to bogous reading on 500MHz clocked Vybrid SoC's. Additionally, also implement a sysfs-property to configure the conversion mode available in this ADC peripherial. Changes since v2: - Add sysfs ABI documentation - Fix commit message spelling errors Changes since v1: - Use ext_info for conversion mode Stefan Agner (3): iio: adc: vf610: use ADC clock within specification iio: adc: vf610: implement configurable conversion modes ARM: dts: add property for maximum ADC clock frequencies Documentation/ABI/testing/sysfs-bus-iio-vf610 | 7 + .../devicetree/bindings/iio/adc/vf610-adc.txt | 9 + arch/arm/boot/dts/vfxxx.dtsi | 4 + drivers/iio/adc/vf610_adc.c| 225 +++-- 4 files changed, 179 insertions(+), 66 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-vf610 -- 2.3.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 0/4] media: pxa_camera conversion to dmaengine
Hi Guennadi, I've been cooking this since 2012. At that time, I thought the dmaengine API was not rich enough to support the pxa_camera subtleties (or complexity). I was wrong. I submitted a driver to Vinod for a dma pxa driver which would support everything needed to make pxa_camera work normally. As a consequence, I wrote this serie. Should the pxa-dma driver be accepted, then this serie will be my next move towards pxa conversion to dmaengine. And to parallelize the review work, I'll submit it right away to receive a review and fix pxa_camera so that it is ready by the time pxa-dma is also reviewed. Happy review. -- Robert Robert Jarzmik (4): media: pxa_camera: fix the buffer free path media: pxa_camera: move interrupt to tasklet media: pxa_camera: trivial move of dma irq functions media: pxa_camera: conversion to dmaengine drivers/media/platform/soc_camera/pxa_camera.c | 518 + 1 file changed, 266 insertions(+), 252 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] media: pxa_camera: fix the buffer free path
From: Robert Jarzmik
Fix the error path where the video buffer wasn't allocated nor
mapped. In this case, in the driver free path don't try to unmap memory
which was not mapped in the first place.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 8d6e343..3ca33f0 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -272,8 +272,8 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
* longer in STATE_QUEUED or STATE_ACTIVE
*/
videobuf_waiton(vq, &buf->vb, 0, 0);
- videobuf_dma_unmap(vq->dev, dma);
- videobuf_dma_free(dma);
+ if (buf->vb.state == VIDEOBUF_NEEDS_INIT)
+ return;
for (i = 0; i < ARRAY_SIZE(buf->dmas); i++) {
if (buf->dmas[i].sg_cpu)
@@ -283,6 +283,8 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
buf->dmas[i].sg_dma);
buf->dmas[i].sg_cpu = NULL;
}
+ videobuf_dma_unmap(vq->dev, dma);
+ videobuf_dma_free(dma);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/18] net: dsa: HW bridging, EEE support
On 03/21/2015 03:48 PM, David Miller wrote: From: Guenter Roeck Date: Sat, 21 Mar 2015 08:46:37 -0700 Patch 1 to 7 of this series prepare the drivers using the mv88e6xxx code for HW bridging support, without adding the code itself. For the most part this factors out common port initialization code. There is no functional change except for patch 3, which disables the message port bit for the CPU port to prevent packet duplication if HW bridging is configured. Patch 8 adds the infrastructure for hardware bridging support to the mv88e6xxx code. Patch 9 wires the MV88E6352 driver to support hardware bridging. Patches 10 to 12 add support for ndo_fdb functions to the dsa subsystem, and wire up the MV88E6352 driver to support those functions. Patches 13 to 16 add EEE support and HW bridging support to the mv88e6171 driver. This set of patches is from Andrew, applied on top of the first set of patches. Patch 17 and 18 add HW bridging support to the mv88e6131 driver. This code is untested and therefore marked RFT. The series applies to net-next as of 3/20/2015. Thanks a lot to Andrew Lunn for testing and valuable feedback. Generally this series looks good. But this driver would be so much easier to read and understand if it used mnemonics instead of constants for the register offsets. Yes, agreed. It is on the to-do list. Should we be more aggressive ? Since I'll have to resubmit anyway, we could start by adding defines for all constants used in this patch set, not just some of them. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] cifs: potential memory leaks when parsing mnt opts
For example, when mount opt is redundently specified
(e.g., "user=A,user=B,user=C"), kernel kept allocating new key/val
with kstrdup() and overwrite previous ptr (to be freed).
Althouhg mkfs.cifs in userspace performs a bit of sanitization
(e.g., forcing one user option), current implementation is not
robust. Other options such as iocharset and domainanme are similary
vulnerable.
Signed-off-by: Taesoo Kim
---
fs/cifs/connect.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index d3aa999..4cb8450 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1599,6 +1599,8 @@ cifs_parse_mount_options(const char *mountdata, const
char *devname,
pr_warn("CIFS: username too long\n");
goto cifs_parse_mount_err;
}
+
+ kfree(vol->username);
vol->username = kstrdup(string, GFP_KERNEL);
if (!vol->username)
goto cifs_parse_mount_err;
@@ -1700,6 +1702,7 @@ cifs_parse_mount_options(const char *mountdata, const
char *devname,
goto cifs_parse_mount_err;
}
+ kfree(vol->domainname);
vol->domainname = kstrdup(string, GFP_KERNEL);
if (!vol->domainname) {
pr_warn("CIFS: no memory for domainname\n");
@@ -1731,6 +1734,7 @@ cifs_parse_mount_options(const char *mountdata, const
char *devname,
}
if (strncasecmp(string, "default", 7) != 0) {
+ kfree(vol->iocharset);
vol->iocharset = kstrdup(string,
GFP_KERNEL);
if (!vol->iocharset) {
--
2.3.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 5/5] dmaengine: pxa_dma: add support for legacy transition
In order to achieve smooth transition of pxa drivers from old legacy dma
handling to new dmaengine, introduce a function to "hide" dma physical
channels from dmaengine.
This is temporary situation where pxa dma will be handled in 2 places :
- arch/arm/plat-pxa/dma.c
- drivers/dma/pxa_dma.c
The resources, ie. dma channels, will be controlled by pxa_dma. The
legacy code will request or release a channel with
pxad_toggle_reserved_channel().
This is not very pretty, but it ensures both legacy and dmaengine
consumers can live in the same kernel until the conversion is done.
Signed-off-by: Robert Jarzmik
---
drivers/dma/pxa_dma.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index aec3e71..9b8ca68 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -417,6 +417,15 @@ static inline void pxad_init_debugfs(struct pxad_device
*pdev) {}
static inline void pxad_cleanup_debugfs(struct pxad_device *pdev) {}
#endif
+/*
+ * In the transition phase where legacy pxa handling is done at the same time
as
+ * mmp_dma, the DMA physical channel split between the 2 DMA providers is done
+ * through legacy_reserved. Legacy code reserves DMA channels by settings
+ * corresponding bits in legacy_reserved.
+ */
+static u32 legacy_reserved;
+static u32 legacy_unavailable;
+
static struct pxad_phy *lookup_phy(struct pxad_chan *pchan)
{
int prio, i;
@@ -437,10 +446,14 @@ static struct pxad_phy *lookup_phy(struct pxad_chan
*pchan)
for (i = 0; i < pdev->nr_chans; i++) {
if (prio != (i & 0xf) >> 2)
continue;
+ if ((i < 32) && (legacy_reserved & BIT(i)))
+ continue;
phy = &pdev->phys[i];
if (!phy->vchan) {
phy->vchan = pchan;
found = phy;
+ if (i < 32)
+ legacy_unavailable |= BIT(i);
goto out_unlock;
}
}
@@ -458,6 +471,7 @@ static void pxad_free_phy(struct pxad_chan *chan)
struct pxad_device *pdev = to_pxad_dev(chan->vc.chan.device);
unsigned long flags;
u32 reg;
+ int i;
chan_dbg(chan, "freeing\n");
if (!chan->phy)
@@ -468,6 +482,9 @@ static void pxad_free_phy(struct pxad_chan *chan)
writel_relaxed(0, chan->phy->base + reg);
spin_lock_irqsave(&pdev->phy_lock, flags);
+ for (i = 0; i < 32; i++)
+ if (chan->phy == &pdev->phys[i])
+ legacy_unavailable &= ~BIT(i);
chan->phy->vchan = NULL;
chan->phy = NULL;
spin_unlock_irqrestore(&pdev->phy_lock, flags);
@@ -689,6 +706,8 @@ static irqreturn_t pxad_int_handler(int irq, void *dev_id)
i = __ffs(dint);
dint &= (dint - 1);
phy = &pdev->phys[i];
+ if ((i < 32) && (legacy_reserved & BIT(i)))
+ continue;
if (pxad_chan_handler(irq, phy) == IRQ_HANDLED)
ret = IRQ_HANDLED;
}
@@ -1440,6 +1459,15 @@ bool pxad_filter_fn(struct dma_chan *chan, void *param)
}
EXPORT_SYMBOL_GPL(pxad_filter_fn);
+int pxad_toggle_reserved_channel(int legacy_channel)
+{
+ if (legacy_unavailable & (BIT(legacy_channel)))
+ return -EBUSY;
+ legacy_reserved ^= BIT(legacy_channel);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pxad_toggle_reserved_channel);
+
module_platform_driver(pxad_driver);
MODULE_DESCRIPTION("Marvell PXA Peripheral DMA Driver");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: execve and sigreturn syscalls must return via iret
Both the execve and sigreturn family of syscalls have the ability to change
registers in ways that may not be compatabile with the syscall path they
were called from. In particular, sysret and sysexit can't handle non-default
%cs and %ss, and some bits in eflags. These syscalls have stubs that are
hardcoded to jump to the iret path, and not return to the original syscall
path. Commit 76f5df43cab5e765c0bd42289103e8f625813ae1 (Always allocate a
complete "struct pt_regs" on the kernel stack) recently changed this for
some 32-bit compat syscalls, but introduced a bug where execve from a 32-bit
program to a 64-bit program would fail because it still returned via sysretl.
This caused Wine to fail when built for both 32-bit and 64-bit.
This patch sets TIF_NOTIFY_RESUME for execve and sigreturn so that the iret
path is always taken on exit to userspace.
Signed-off-by: Brian Gerst
Cc: Ingo Molnar
Cc: Denys Vlasenko
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Linus Torvalds
---
arch/x86/ia32/ia32_signal.c| 2 ++
arch/x86/include/asm/ptrace.h | 2 +-
arch/x86/include/asm/thread_info.h | 7 +++
arch/x86/kernel/process_32.c | 6 +-
arch/x86/kernel/process_64.c | 1 +
arch/x86/kernel/signal.c | 2 ++
6 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index d0165c9..1f5e2b0 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -203,6 +203,8 @@ static int ia32_restore_sigcontext(struct pt_regs *regs,
err |= restore_xstate_sig(buf, 1);
+ force_iret();
+
return err;
}
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 74bb2e0..83b874d 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -251,7 +251,7 @@ static inline unsigned long
regs_get_kernel_stack_nth(struct pt_regs *regs,
*/
#define arch_ptrace_stop_needed(code, info)\
({ \
- set_thread_flag(TIF_NOTIFY_RESUME); \
+ force_iret(); \
false; \
})
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index ba115eb..861c1dd 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -260,6 +260,13 @@ static inline bool is_ia32_task(void)
#endif
return false;
}
+
+/*
+ * force syscall return via iret by making it look as if there was
+ * some work pending.
+*/
+#define force_iret() set_thread_flag(TIF_NOTIFY_RESUME)
+
#endif /* !__ASSEMBLY__ */
#ifndef __ASSEMBLY__
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 1b9963f..26c596d 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -206,11 +206,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip,
unsigned long new_sp)
regs->ip= new_ip;
regs->sp= new_sp;
regs->flags = X86_EFLAGS_IF;
- /*
-* force it to the iret return path by making it look as if there was
-* some work pending.
-*/
- set_thread_flag(TIF_NOTIFY_RESUME);
+ force_iret();
}
EXPORT_SYMBOL_GPL(start_thread);
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 97f5658..da8b745 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -239,6 +239,7 @@ start_thread_common(struct pt_regs *regs, unsigned long
new_ip,
regs->cs= _cs;
regs->ss= _ss;
regs->flags = X86_EFLAGS_IF;
+ force_iret();
}
void
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index edcb862..eaa2c5e 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -108,6 +108,8 @@ int restore_sigcontext(struct pt_regs *regs, struct
sigcontext __user *sc,
err |= restore_xstate_sig(buf, config_enabled(CONFIG_X86_32));
+ force_iret();
+
return err;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/asm] x86/asm/entry/64: Always allocate a complete " struct pt_regs" on the kernel stack
On Wed, Mar 4, 2015 at 5:53 PM, tip-bot for Denys Vlasenko wrote: > Commit-ID: 76f5df43cab5e765c0bd42289103e8f625813ae1 > Gitweb: http://git.kernel.org/tip/76f5df43cab5e765c0bd42289103e8f625813ae1 > Author: Denys Vlasenko > AuthorDate: Thu, 26 Feb 2015 14:40:27 -0800 > Committer: Ingo Molnar > CommitDate: Wed, 4 Mar 2015 22:50:49 +0100 > > x86/asm/entry/64: Always allocate a complete "struct pt_regs" on the kernel > stack > > The 64-bit entry code was using six stack slots less by not > saving/restoring registers which are callee-preserved according > to the C ABI, and was not allocating space for them. > > Only when syscalls needed a complete "struct pt_regs" was > the complete area allocated and filled in. > > As an additional twist, on interrupt entry a "slightly less > truncated pt_regs" trick is used, to make nested interrupt > stacks easier to unwind. > > This proved to be a source of significant obfuscation and subtle > bugs. For example, 'stub_fork' had to pop the return address, > extend the struct, save registers, and push return address back. > Ugly. 'ia32_ptregs_common' pops return address and "returns" via > jmp insn, throwing a wrench into CPU return stack cache. > > This patch changes the code to always allocate a complete > "struct pt_regs" on the kernel stack. The saving of registers > is still done lazily. > > "Partial pt_regs" trick on interrupt stack is retained. > > Macros which manipulate "struct pt_regs" on stack are reworked: > > - ALLOC_PT_GPREGS_ON_STACK allocates the structure. > > - SAVE_C_REGS saves to it those registers which are clobbered >by C code. > > - SAVE_EXTRA_REGS saves to it all other registers. > > - Corresponding RESTORE_* and REMOVE_PT_GPREGS_FROM_STACK macros >reverse it. > > 'ia32_ptregs_common', 'stub_fork' and friends lost their ugly dance > with the return pointer. > > LOAD_ARGS32 in ia32entry.S now uses symbolic stack offsets > instead of magic numbers. > > 'error_entry' and 'save_paranoid' now use SAVE_C_REGS + > SAVE_EXTRA_REGS instead of having it open-coded yet again. > > Patch was run-tested: 64-bit executables, 32-bit executables, > strace works. > > Timing tests did not show measurable difference in 32-bit > and 64-bit syscalls. > > Signed-off-by: Denys Vlasenko > Signed-off-by: Andy Lutomirski > Cc: Alexei Starovoitov > Cc: Borislav Petkov > Cc: Frederic Weisbecker > Cc: H. Peter Anvin > Cc: Kees Cook > Cc: Linus Torvalds > Cc: Oleg Nesterov > Cc: Will Drewry > Link: > http://lkml.kernel.org/r/1423778052-21038-2-git-send-email-dvlas...@redhat.com > Link: > http://lkml.kernel.org/r/b89763d354aa23e670b9bdf3a40ae320320a7c2e.1424989793.git.l...@amacapital.net > Signed-off-by: Ingo Molnar > @@ -492,7 +496,6 @@ GLOBAL(stub32_clone) > > ALIGN > ia32_ptregs_common: > - popq %r11 > CFI_ENDPROC > CFI_STARTPROC32 simple > CFI_SIGNAL_FRAME > @@ -507,9 +510,9 @@ ia32_ptregs_common: > /* CFI_REL_OFFSET rflags,EFLAGS-ARGOFFSET*/ > CFI_REL_OFFSET rsp,RSP-ARGOFFSET > /* CFI_REL_OFFSET ss,SS-ARGOFFSET*/ > - SAVE_REST > + SAVE_EXTRA_REGS 8 > call *%rax > - RESTORE_REST > - jmp ia32_sysret/* misbalances the return cache */ > + RESTORE_EXTRA_REGS 8 > + ret > CFI_ENDPROC > END(ia32_ptregs_common) This change is causing Wine to fail when it's built to support both 32-bit and 64-bit code: [ 523.657406] wineserver[1605]: segfault at 453a7c90 ip 453a7c90 sp b3c6ad10 error 14 in ld-2.21.so[7fad453a7000+21000] It tries to exec the 64-bit wineserver from 32-bit code and faults because %rip is truncated. This is because simply returning to the caller will exit via sysretl which doesn't change %cs to 64-bit mode. We need to set a thread flag to enter the slow path and return via iret instead. Patch coming to fix it. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Documentation: dmaengine: pxa-dma design
Document the new design of the pxa dma driver. Signed-off-by: Robert Jarzmik --- Documentation/dmaengine/pxa_dma.txt | 157 1 file changed, 157 insertions(+) create mode 100644 Documentation/dmaengine/pxa_dma.txt diff --git a/Documentation/dmaengine/pxa_dma.txt b/Documentation/dmaengine/pxa_dma.txt new file mode 100644 index 000..63db9fe --- /dev/null +++ b/Documentation/dmaengine/pxa_dma.txt @@ -0,0 +1,157 @@ +PXA/MMP - DMA Slave controller +== + +Constraints +--- + a) Transfers hot queuing + A driver submitting a transfer and issuing it should be granted the transfer + is queued even on a running DMA channel. + This implies that the queuing doesn't wait for the previous transfer end, + and that the descriptor chaining is not only done in the irq/tasklet code + triggered by the end of the transfer. + + b) All transfers having asked for confirmation should be signaled + Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback call. + This implies that even if an irq/tasklet is triggered by end of tx1, but + at the time of irq/dma tx2 is already finished, tx1->complete() and + tx2->complete() should be called. + + c) Channel residue calculation + A channel should be able to report how much advanced is a transfer. The + granularity is still descriptor based. + + d) Channel running state + A driver should be able to query if a channel is running or not. For the + multimedia case, such as video capture, if a transfer is submitted and then + a check of the DMA channel reports a "stopped channel", the transfer should + not be issued until the next "start of frame interrupt", hence the need to + know if a channel is in running or stopped state. + + e) Bandwidth guarantee + The PXA architecture has 4 levels of DMAs priorities : high, normal, low. + The high prorities get twice as much bandwidth as the normal, which get twice + as much as the low priorities. + A driver should be able to request a priority, especially the real-time + ones such as pxa_camera with (big) throughputs. + + f) Transfer reusability + An issued and finished transfer should be "reusable". The choice of + "DMA_CTRL_ACK" should be left to the client, not the dma driver. + +Design +-- + a) Virtual channels + Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual + channel" linked to the requestor line, and the physical DMA channel is + assigned on the fly when the transfer is issued. + + b) Transfer anatomy for a scatter-gather transfer + ++-+---++-+ + | desc-sg[0] | ... | desc-sg[last] | status updater | finisher/linker | + ++-+---++-+ + + This structure is pointed by dma->sg_cpu. + The descriptors are used as follows : + - desc-sg[i]: i-th descriptor, transferring the i-th sg +element to the video buffer scatter gather + - status updater +Transfers a single u32 to a well known dma coherent memory to leave +a trace that this transfer is done. The "well known" is unique per +physical channel, meaning that a read of this value will tell which +is the last finished transfer at that point in time. + - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN + - linker: has ddadr= desc-sg[0] of next transfer, dcmd=0 + + b) Transfers hot-chaining + Suppose the running chain is : + Buffer 1 Buffer 2 + +-++---+ ++++---+ + | d0 | .. | dN | l | | d0 | .. | dN | f | + +-++-|-+ ^+++---+ + || + ++ + + After a call to dmaengine_submit(b3), the chain will look like : + Buffer 1 Buffer 2 Buffer 3 + +-++---+ ++++---+ ++++---+ + | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | + +-++-|-+ ^+++-|-+ ^+++---+ + |||| + ++++ + new_link + + If while new_link was created the DMA channel stopped, it is _not_ + restarted. Hot-chaining doesn't break the assumption that + dma_async_issue_pending() is to be used to ensure the transfer is actually started. + + One exception to this rule : + - if Buffer1 and Buffer2 had all their addresses 8 bytes aligned + - and if Buffer3 has at least one address not 4 bytes aligned + - then hot-chaining cannot happen, as the channel must be stopped, the + "align bit" must be set, and the channel restarted As a consequence, + such a transfer tx_submit() will be queued on the s
[PATCH 4/5] dmaengine: pxa_dma: add debug information
Reuse the debugging features which were available in pxa architecture.
This is a copy of the code from arch/arm/plat-pxa/dma, which is doomed
to disappear once the conversion is completed towards dmaengine.
This is a transfer of the commit "[ARM] pxa/dma: add debugfs
entries" (d294948c2ce4e1c85f452154469752cc9b8e876d).
Signed-off-by: Robert Jarzmik
---
drivers/dma/pxa_dma.c | 240 ++
1 file changed, 240 insertions(+)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index fd4a48c..aec3e71 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -128,6 +128,11 @@ struct pxad_device {
void __iomem*base;
struct pxad_phy *phys;
spinlock_t phy_lock; /* Phy association */
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *dbgfs_root;
+ struct dentry *dbgfs_state;
+ struct dentry **dbgfs_chan;
+#endif
};
#define tx_to_pxad_desc(tx)\
@@ -178,6 +183,239 @@ struct pxad_device {
} while (0)
/*
+ * Debug fs
+ */
+#ifdef CONFIG_DEBUG_FS
+#include
+#include
+#include
+
+static int dbg_show_requester_chan(struct seq_file *s, void *p)
+{
+ int pos = 0;
+ struct pxad_phy *phy = s->private;
+ int i;
+ u32 drcmr;
+
+ pos += seq_printf(s, "DMA channel %d requester :\n", phy->idx);
+ for (i = 0; i < 70; i++) {
+ drcmr = readl_relaxed(phy->base + DRCMR(i));
+ if ((drcmr & DRCMR_CHLNUM) == phy->idx)
+ pos += seq_printf(s, "\tRequester %d (MAPVLD=%d)\n", i,
+ !!(drcmr & DRCMR_MAPVLD));
+ }
+ return pos;
+}
+
+static inline int dbg_burst_from_dcmd(u32 dcmd)
+{
+ int burst = (dcmd >> 16) & 0x3;
+
+ return burst ? 4 << burst : 0;
+}
+
+static int is_phys_valid(unsigned long addr)
+{
+ return pfn_valid(__phys_to_pfn(addr));
+}
+
+#define DCSR_STR(flag) (dcsr & DCSR_##flag ? #flag" " : "")
+#define DCMD_STR(flag) (dcmd & DCMD_##flag ? #flag" " : "")
+
+static int dbg_show_descriptors(struct seq_file *s, void *p)
+{
+ struct pxad_phy *phy = s->private;
+ int i, max_show = 20, burst, width;
+ u32 dcmd;
+ unsigned long phys_desc, ddadr;
+ struct pxad_desc_hw *desc;
+
+ phys_desc = ddadr = _phy_readl_relaxed(phy, DDADR);
+
+ seq_printf(s, "DMA channel %d descriptors :\n", phy->idx);
+ seq_printf(s, "[%03d] First descriptor unknown\n", 0);
+ for (i = 1; i < max_show && is_phys_valid(phys_desc); i++) {
+ desc = phys_to_virt(phys_desc);
+ dcmd = desc->dcmd;
+ burst = dbg_burst_from_dcmd(dcmd);
+ width = (1 << ((dcmd >> 14) & 0x3)) >> 1;
+
+ seq_printf(s, "[%03d] Desc at %08lx(virt %p)\n",
+ i, phys_desc, desc);
+ seq_printf(s, "\tDDADR = %08x\n", desc->ddadr);
+ seq_printf(s, "\tDSADR = %08x\n", desc->dsadr);
+ seq_printf(s, "\tDTADR = %08x\n", desc->dtadr);
+ seq_printf(s, "\tDCMD = %08x (%s%s%s%s%s%s%sburst=%d width=%d
len=%d)\n",
+ dcmd,
+ DCMD_STR(INCSRCADDR), DCMD_STR(INCTRGADDR),
+ DCMD_STR(FLOWSRC), DCMD_STR(FLOWTRG),
+ DCMD_STR(STARTIRQEN), DCMD_STR(ENDIRQEN),
+ DCMD_STR(ENDIAN), burst, width,
+ dcmd & DCMD_LENGTH);
+ phys_desc = desc->ddadr;
+ }
+ if (i == max_show)
+ seq_printf(s, "[%03d] Desc at %08lx ... max display reached\n",
+ i, phys_desc);
+ else
+ seq_printf(s, "[%03d] Desc at %08lx is %s\n",
+ i, phys_desc, phys_desc == DDADR_STOP ?
+ "DDADR_STOP" : "invalid");
+
+ return 0;
+}
+
+static int dbg_show_chan_state(struct seq_file *s, void *p)
+{
+ struct pxad_phy *phy = s->private;
+ u32 dcsr, dcmd;
+ int burst, width;
+ static const char * const str_prio[] = {
+ "high", "normal", "low", "invalid"
+ };
+
+ dcsr = _phy_readl_relaxed(phy, DCSR);
+ dcmd = _phy_readl_relaxed(phy, DCMD);
+ burst = dbg_burst_from_dcmd(dcmd);
+ width = (1 << ((dcmd >> 14) & 0x3)) >> 1;
+
+ seq_printf(s, "DMA channel %d\n", phy->idx);
+ seq_printf(s, "\tPriority : %s\n",
+ str_prio[(phy->idx & 0xf) / 4]);
+ seq_printf(s, "\tUnaligned transfer bit: %s\n",
+ _phy_readl_relaxed(phy, DALGN) & BIT(phy->idx) ?
+ "yes" : "no");
+ seq_printf(s, "\tDCSR = %08x (%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s)\n",
+ dcsr, DCSR_STR(RUN), DCSR_STR(NODESC),
+ D
[PATCH 2/5] MAINTAINERS: add pxa dma driver to pxa architecture
Add the pxa dma driver as maintained by the pxa architecture maintainers, as it is part of the core IP. Signed-off-by: Robert Jarzmik --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9a76a40..35062a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7873,6 +7873,7 @@ T:git git://github.com/hzhuang1/linux.git T: git git://github.com/rjarzmik/linux.git S: Maintained F: arch/arm/mach-pxa/ +F: drivers/dma/pxa* F: drivers/pcmcia/pxa2xx* F: drivers/spi/spi-pxa2xx* F: drivers/usb/gadget/udc/pxa2* -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] dmaengine: pxa: add pxa dmaengine driver
This is a new driver for pxa SoCs, which is also compatible with the former mmp_pdma. The rationale behind a new driver (as opposed to incremental patching) was : - the new driver relies on virt-dma, which obsoletes all the internal structures of mmp_pdma (sw_desc, hw_desc, ...), and by consequence all the functions - mmp_pdma allocates dma coherent descriptors containing not only hardware descriptors but linked list information The new driver only puts the dma hardware descriptors (ie. 4 u32) into the dma pool allocated memory. This changes completely the way descriptors are handled - the architecture behind the interrupt/tasklet management was rewritten to be more conforming to virt-dma - the buffers alignment is handled differently The former driver assumed that the DMA channel stopped between each descriptor. The new one chains descriptors to let the channel running. This is a necessary guarantee for real-time high bandwidth usecases such as video capture on "old" architectures such as pxa. - hot chaining / cold chaining / no chaining Whenever possible, submitting a descriptor "hot chains" it to a running channel. There is still no guarantee that the descriptor will be issued, as the channel might be stopped just before the descriptor is submitted. Yet this allows to submit several video buffers, and resubmit a buffer while another is under handling. As before, dma_async_issue_pending() is the only guarantee to have all the buffers issued. When an alignment issue is detected (ie. one address in a descriptor is not a multiple of 8), if the already running channel is in "aligned mode", the channel will stop, and restarted in "misaligned mode" to finished the issued list. - descriptors reusing A submitted, issued and completed descriptor can be reused, ie resubmitted if it was prepared with the proper flag (DMA_PREP_ACK). Only a channel resources release will in this case release that buffer. This allows a rolling ring of buffers to be reused, where there are several thousands of hardware descriptors used (video buffer for example). Additionally, a set of more casual features is introduced : - debugging traces - lockless way to know if a descriptor is terminated or not The driver was tested on zylonite board (pxa3xx) and mioa701 (pxa27x), with dmatest, pxa_camera and pxamci. Signed-off-by: Robert Jarzmik --- drivers/dma/Kconfig | 11 + drivers/dma/Makefile|1 + drivers/dma/pxa_dma.c | 1207 +++ include/linux/dma/pxa-dma.h | 27 + 4 files changed, 1246 insertions(+) create mode 100644 drivers/dma/pxa_dma.c create mode 100644 include/linux/dma/pxa-dma.h diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index a874b6e..87804f0 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -162,6 +162,17 @@ config MX3_IPU_IRQS To avoid bloating the irq_desc[] array we allocate a sufficient number of IRQ slots and map them dynamically to specific sources. +config PXA_DMA + bool "PXA DMA support" + depends on (ARCH_MMP || ARCH_PXA) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + help + Support the DMA engine for PXA. It is also compatible with MMP PDMA + platform. The internal DMA IP of all PXA variants is supported, with + 16 to 32 channels for peripheral to memory or memory to memory + transfers. + config TXX9_DMAC tristate "Toshiba TXx9 SoC DMA support" depends on MACH_TX49XX || MACH_TX39XX diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index f915f61..07ef9e2 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -25,6 +25,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/ obj-$(CONFIG_IMX_SDMA) += imx-sdma.o obj-$(CONFIG_IMX_DMA) += imx-dma.o obj-$(CONFIG_MXS_DMA) += mxs-dma.o +obj-$(CONFIG_PXA_DMA) += pxa_dma.o obj-$(CONFIG_TIMB_DMA) += timb_dma.o obj-$(CONFIG_SIRF_DMA) += sirf-dma.o obj-$(CONFIG_TI_EDMA) += edma.o diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c new file mode 100644 index 000..fd4a48c --- /dev/null +++ b/drivers/dma/pxa_dma.c @@ -0,0 +1,1207 @@ +/* + * Copyright 2015 Robert Jarzmik + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "dmaengine.h" +#include "virt-dma.h" + +#define DCSR(n)(0x + ((n) << 2)) +#define DALGN(n) 0x00a0 +#define DINT 0x00f0 +#define DDADR(n) (0x0200 + ((n) << 4)) +#define DSADR(n) (0x0204 + ((n) << 4)) +#define DTADR(n) (0x0208 + ((n) << 4)) +#define DCMD(n)
[PATCH 0/5] Driver for pxa architectures
Hi Vinod, This serie introduces a new driver for Marvell pxa architectures. There is a full rationale explanation in patch 3/5 on why mmp_pdma was not reused nor patched incrementally. This new driver provides all the capabilities to port all the drivers of pxa architecture to dmaengine. It was tested against the most dma advanced user I know (pxa_camera), as well a more casual ones (pxamci and dmatest). This is big piece of code, so I expect the review will take time. If we converge on it, it will be maintained as well as part of the pxa architeture maintainance. It is as well one of the last steps (or so I hope) for pxa architure to be part of the multiplatform ARM architecture, and at the same time keep its legacy platforms operational. It will kill arch/arm/plat-pxa/dma.c in the long term. Cheers. -- Robert Robert Jarzmik (5): Documentation: dmaengine: pxa-dma design MAINTAINERS: add pxa dma driver to pxa architecture dmaengine: pxa: add pxa dmaengine driver dmaengine: pxa_dma: add debug information dmaengine: pxa_dma: add support for legacy transition Documentation/dmaengine/pxa_dma.txt | 157 MAINTAINERS |1 + drivers/dma/Kconfig | 11 + drivers/dma/Makefile|1 + drivers/dma/pxa_dma.c | 1475 +++ include/linux/dma/pxa-dma.h | 27 + 6 files changed, 1672 insertions(+) create mode 100644 Documentation/dmaengine/pxa_dma.txt create mode 100644 drivers/dma/pxa_dma.c create mode 100644 include/linux/dma/pxa-dma.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/18] net: dsa: HW bridging, EEE support
From: Guenter Roeck Date: Sat, 21 Mar 2015 08:46:37 -0700 > Patch 1 to 7 of this series prepare the drivers using the mv88e6xxx code > for HW bridging support, without adding the code itself. For the most part > this factors out common port initialization code. There is no functional > change except for patch 3, which disables the message port bit for the > CPU port to prevent packet duplication if HW bridging is configured. > > Patch 8 adds the infrastructure for hardware bridging support to the > mv88e6xxx code. > > Patch 9 wires the MV88E6352 driver to support hardware bridging. > > Patches 10 to 12 add support for ndo_fdb functions to the dsa subsystem, and > wire up the MV88E6352 driver to support those functions. > > Patches 13 to 16 add EEE support and HW bridging support to the mv88e6171 > driver. This set of patches is from Andrew, applied on top of the first > set of patches. > > Patch 17 and 18 add HW bridging support to the mv88e6131 driver. This code > is untested and therefore marked RFT. > > The series applies to net-next as of 3/20/2015. > > Thanks a lot to Andrew Lunn for testing and valuable feedback. Generally this series looks good. But this driver would be so much easier to read and understand if it used mnemonics instead of constants for the register offsets. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/18] net: dsa: mv88e6xxx: Provide function for common port initialization
On 03/21/2015 08:46 AM, Guenter Roeck wrote:
Provide mv88e6xxx_setup_port_common() for common port initialization.
Currently only write Port 1 Control and VLAN configuration since
this will be needed for hardware bridging. More can be added later
if desired/needed.
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6xxx.c | 39 +++
drivers/net/dsa/mv88e6xxx.h | 1 +
2 files changed, 40 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 6496beb..3c2cb45 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -700,6 +700,45 @@ int mv88e6xxx_set_eee(struct dsa_switch *ds, int port,
return 0;
}
+int mv88e6xxx_setup_port_common(struct dsa_switch *ds, int port)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int reg;
+
+ mutex_lock(&ps->smi_mutex);
+
+ /* Port Control 1: disable trunking. Also, if this is the
+* CPU port, enable learn messages to be sent to this port.
+*/
+ ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), 0x05,
+ dsa_is_cpu_port(ds, port) ? 0x8000 : 0x);
This fails to compile. It is fixed in a later commit which is why I didn't see
it.
Too much reordering, I guess. Sorry for that.
Just a heads up; I'll wait for comments before resubmitting.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cx82310_eth: wait for firmware to become ready
From: Ondrej Zary Date: Sat, 21 Mar 2015 11:29:37 +0100 > When the device is powered up, some (older) firmware versions fail to work > properly if we send commands before the boot is complete (everything is OK > when the device is hot-plugged). The firmware indicates its ready status by > putting the link up. > Newer firmwares delay the first command so they don't suffer from this > problem. > They also report the link being always up. > > Wait for firmware to become ready (link up) before sending any commands and/or > data. > > This also allows lowering CMD_TIMEOUT value to a reasonable time. > > Tested with 4.1.0.9 (old) and 4.1.0.30 (new) firmware versions. > > Signed-off-by: Ondrej Zary Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: sdhci-msm: Add support for vendor capabilities registers
On Sat, Mar 21, 2015 at 7:50 AM, Georgi Djakov wrote: > Some versions of this controller do not advertise their 3.0v and > 8bit bus-width support capabilities. It is required to explicitly > set these capabilities for the specific controller versions. > [..] > diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c [..] > + > +#define CORE_VENDOR_SPEC_CAPABILITIES0 0x11c > +#define CORE_8_BIT_SUPPORT BIT(18) > +#define CORE_3_0V_SUPPORT BIT(25) The $11c register is specified to drive the lower capability register directly, hence you should use the sdhci defines for these bits instead of duplicating them here; SDHCI_CAN_DO_8BIT and SDHCI_CAN_VDD_300 that is. I'm sorry for missing this when looking at v1 :/ Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 virtio-input driver.
On Fri, Mar 20, 2015 at 01:39:29PM +0100, Gerd Hoffmann wrote:
> virtio-input is basically evdev-events-over-virtio, so this driver isn't
> much more than reading configuration from config space and forwarding
> incoming events to the linux input layer.
>
> Signed-off-by: Gerd Hoffmann
> ---
> MAINTAINERS | 6 +
> drivers/virtio/Kconfig| 10 ++
> drivers/virtio/Makefile | 1 +
> drivers/virtio/virtio_input.c | 335
> ++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/virtio_ids.h | 1 +
> include/uapi/linux/virtio_input.h | 75 +
> 7 files changed, 429 insertions(+)
> create mode 100644 drivers/virtio/virtio_input.c
> create mode 100644 include/uapi/linux/virtio_input.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0e1abe8..585e6cd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10435,6 +10435,12 @@ S: Maintained
> F: drivers/vhost/
> F: include/uapi/linux/vhost.h
>
> +VIRTIO INPUT DRIVER
> +M: Gerd Hoffmann
> +S: Maintained
> +F: drivers/virtio/virtio_input.c
> +F: include/uapi/linux/virtio_input.h
> +
> VIA RHINE NETWORK DRIVER
> M: Roger Luethi
> S: Maintained
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index b546da5..cab9f3f 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -48,6 +48,16 @@ config VIRTIO_BALLOON
>
>If unsure, say M.
>
> +config VIRTIO_INPUT
> + tristate "Virtio input driver"
> + depends on VIRTIO
> + depends on INPUT
> + ---help---
> + This driver supports virtio input devices such as
> + keyboards, mice and tablets.
> +
> + If unsure, say M.
> +
> config VIRTIO_MMIO
> tristate "Platform bus driver for memory mapped virtio devices"
> depends on HAS_IOMEM
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index d85565b..41e30e3 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
> virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
> obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
> +obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
> new file mode 100644
> index 000..dd3215e
> --- /dev/null
> +++ b/drivers/virtio/virtio_input.c
> @@ -0,0 +1,335 @@
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +struct virtio_input {
> + struct virtio_device *vdev;
> + struct input_dev *idev;
> + char name[64];
> + char serial[64];
> + char phys[64];
> + struct virtqueue *evt, *sts;
> + struct virtio_input_event evts[64];
> + struct mutex lock;
> +};
> +
> +static ssize_t serial_show(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + struct input_dev *idev = to_input_dev(dev);
> + struct virtio_input *vi = input_get_drvdata(idev);
> +
> + return sprintf(buf, "%s\n", vi->serial);
> +}
> +static DEVICE_ATTR_RO(serial);
> +
> +static struct attribute *dev_attrs[] = {
> + &dev_attr_serial.attr,
> + NULL
> +};
> +
> +static umode_t dev_attrs_are_visible(struct kobject *kobj,
> + struct attribute *a, int n)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct input_dev *idev = to_input_dev(dev);
> + struct virtio_input *vi = input_get_drvdata(idev);
> +
> + if (a == &dev_attr_serial.attr && !strlen(vi->serial))
> + return 0;
> +
> + return a->mode;
> +}
> +
> +static struct attribute_group dev_attr_grp = {
> + .attrs =dev_attrs,
> + .is_visible = dev_attrs_are_visible,
> +};
> +
> +static const struct attribute_group *dev_attr_groups[] = {
> + &dev_attr_grp,
> + NULL
> +};
> +
> +static void virtinput_queue_evtbuf(struct virtio_input *vi,
> +struct virtio_input_event *evtbuf)
> +{
> + struct scatterlist sg[1];
> +
> + sg_init_one(sg, evtbuf, sizeof(*evtbuf));
> + virtqueue_add_inbuf(vi->evt, sg, 1, evtbuf, GFP_ATOMIC);
> +}
> +
> +static void virtinput_recv_events(struct virtqueue *vq)
> +{
> + struct virtio_input *vi = vq->vdev->priv;
> + struct virtio_input_event *event;
> + unsigned int len;
> +
> + mutex_lock(&vi->lock);
> + while ((event = virtqueue_get_buf(vi->evt, &len)) != NULL) {
> + input_event(vi->idev,
> + le16_to_cpu(event->type),
> + le16_to_cpu(event->code),
> + le32_to_cpu(event->value));
> + virtinput_queue_evtbuf(vi, event);
> + }
> + virtqueue_kick(vq);
> + mutex_unlock(&vi->lo
Re: [PATCH 1/1] Add virtio-input driver.
On Fri, Mar 20, 2015 at 11:28:47AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > +static int virtinput_send_status(struct virtio_input *vi,
> > > + u16 type, u16 code, s32 value)
> > > +{
> > > + struct virtio_input_event *stsbuf;
> > > + struct scatterlist sg[1];
> > > +
> > > + stsbuf = kzalloc(sizeof(*stsbuf), GFP_ATOMIC);
> > > + if (!stsbuf)
> > > + return -ENOMEM;
> >
> > Does this return an error to userspace?
> > If so it's not a good idea I think, GFP_ATOMIC failures are
> > transient conditions and should not be reported
> > to userspace.
> > Can use GFP_KERNEL here?
>
> Waiting for an answer from the ioput guys here.
>
> > > +
> > > + stsbuf->type = cpu_to_le16(type);
> > > + stsbuf->code = cpu_to_le16(code);
> > > + stsbuf->value = cpu_to_le32(value);
> > > + sg_init_one(sg, stsbuf, sizeof(*stsbuf));
> > > + virtqueue_add_outbuf(vi->sts, sg, 1, stsbuf, GFP_ATOMIC);
> >
> > This can fail if queue is full. What prevents this from happening?
>
> Nothing. It's highly unlikely though given the throughput we have for
> input devices, not sure it is that useful to put too much effort into
> this. Except for freeing stsbuf in the error case.
>
> > > + virtqueue_kick(vi->sts);
> >
> > Also what prevents multiple virtinput_send_status calls
> > from racing with each other? Is there locking at a higher level?
>
> I think input_dev->event_lock does this.
>
> > > +static void virtinput_recv_status(struct virtqueue *vq)
> > > +{
> > > + struct virtio_input *vi = vq->vdev->priv;
> > > + struct virtio_input_event *stsbuf;
> > > + unsigned int len;
> > > +
> > > + while ((stsbuf = virtqueue_get_buf(vi->sts, &len)) != NULL)
> >
> > looks like this get_buf can race with add above.
>
> Yes, it can.
>
> > Need some locking.
>
> I'll add it.
>
> > Also pls avoid != NULL, removing it makes code less verbose.
> >
> > > + kfree(stsbuf);
> > > + virtqueue_kick(vq);
> >
> > Why are you kicking here?
>
> Hmm, it is pointless indeed.
>
> > > + if (select == VIRTIO_INPUT_CFG_EV_BITS)
> > > + set_bit(subsel, vi->idev->evbit);
> > > + for (bit = 0; bit < bitcount; bit++) {
> > > + if ((bit % 8) == 0)
> > > + virtio_cread(vi->vdev, struct virtio_input_config,
> > > + u.bitmap[bit/8], &cfg);
> >
> > coding style violations above. you need spaces around ops like / and *.
> > Please run checkpatch.pl
> >
> > > + if (cfg & (1 << (bit % 8)))
> > > + set_bit(bit, bits);
> >
> > what if not set? does something clear the mask?
>
> kzalloc?
So you are really just reading in array of bytes?
All this set bit trickery is just to convert things from LE?
> > > + }
> >
> > doesn't above just implement bitmap_copy or bitmap_or?
>
> Not fully sure how bitmaps are defined. virtio has a stream of bytes,
> first byte carries bits 0-7, second 8-15 etc. linux kernel bitmaps ops
> are operating on longs, and native byteorder longs would be something
> else ...
This still looks too complex.
At least, this needs a comment explaining what the function does,
and maybe wrap it in a helper like virtio_input_bitmap_copy or
virtio_bitmap_or.
> > > + size = virtinput_cfg_select(vi, VIRTIO_INPUT_CFG_ABS_INFO, abs);
> > > + virtio_cread(vi->vdev, struct virtio_input_config, u.abs.min, &mi);
> > > + virtio_cread(vi->vdev, struct virtio_input_config, u.abs.max, &ma);
> > > + virtio_cread(vi->vdev, struct virtio_input_config, u.abs.fuzz, &fu);
> > > + virtio_cread(vi->vdev, struct virtio_input_config, u.abs.flat, &fl);
> >
> > you read le field into u32 value.
> > Please run sparse on this code. you will get a ton
> > of warnings. Same error appears elsewhere.
>
> Indeed. IIRC that wasn't the case a while back. Guess those bitwise
> annotations have been added with the virtio 1.0 patches?
>
> In any case I'll fix it up.
I see you still didn't in v2?
> > > +static int virtinput_probe(struct virtio_device *vdev)
> > > +{
> > > + struct virtio_input *vi;
> > > + size_t size;
> > > + int abs, err;
> >
> > How about checking VERSION_1 and bailing out of not there?
>
> I don't think this is needed. There isn't a hard dependency on virtio
> 1.0. It's just that config space is relatively large and because of
> that I want it be 1.0 on the host (qemu) side to not allocate large
> portions of I/O address space for the legacy virtio pci bar.
You are doing leXXX everywhere, that's VERSION_1 dependency.
virtio_cread will do byteswaps differently without VERSION_1.
Just don't go there.
> > > + vi->idev->name = vi->name;
> > > + vi->idev->phys = vi->phys;
> > > + vi->idev->id.bustype = BUS_VIRTUAL;
> > > + vi->idev->id.vendor = 0x0001;
> > > + vi->idev->id.product = 0x0001;
> > > + vi->idev->id.version = 0x0100;
> >
> > Add comments explaining why these #s make sense?
>
> See other subthread, will be changed to be host-provided (like name).
>
> > > + err = input_register_device(vi->idev);
> >
> > Once y
Re: [PATCH] checkpatch.pl: Add warning for harmful goto labels
Am 21.03.2015 um 23:06 schrieb L. Alberto Giménez: > On Sat, Mar 21, 2015 at 10:40:46PM +0100, Richard Weinberger wrote: >> Huh? Since when? > > There are a lot of cases where a too generic goto label for cleanup > causes a bug or makes debugging harder. > > Last time was this G+ post, by Dan Carpenter: > > https://plus.google.com/106378716002406849458/posts/DfuAkt8szf2 > > >> rw@azrael:~/linux (for-v4.1/uml_misc $)> git grep -e "goto out;" | wc -l >> 26667 >> rw@azrael:~/linux (for-v4.1/uml_misc $)> git grep -e "goto fail;" | wc -l >> 3733 > > If something is already in the kernel code, does that mean that it's OK? > I honestly don't think so, and I think that goto labels for cleanup exit > paths should be a little more descriptive. I disagree. out and exit are perfectly fine labels. >> What is next? Variable name "i" considered harmful? > > No one complained about that so far. I might add that to checkpatch.pl > if needed. I *really* *really* hope you're kidding. >> Can we please stop this nonsense. > > It's just a proposal for a warning. If it is really not needed, it won't > be applied and life will go on :) checkpatch.pl is already more than annoying. It used to be a nice tool but it becomes more and more an harassment for guys who actually work on the kernel. 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/
Re: JFS readdir() issues in stable 3.2
Am 21.03.2015 um 22:58 schrieb Dave Kleikamp: > On 03/20/2015 06:33 PM, Richard Weinberger wrote: >> Hi! >> >> Mainline commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 >> (jfs: fix readdir cookie incompatibility with NFSv4) does not work as >> expected on 3.2. >> Maybe on other stable kernels too. >> >> UML stumbled over it: >> https://bugzilla.kernel.org/show_bug.cgi?id=94741 >> >> If you run the attached readdir.c on a JFS on stable 3.2.51+ readdir() will >> not >> increment the directory offset nor return NULL, hence the caller will loop >> forever. >> It looks like if the current directory offset is > 0 and you run >> seekdir(telldir()) >> the next readdir() call will not increment it. > > The backport failed to pass the proper position to filldir() for the . > and .. entries. I've attached a proposed patch to the above bug. Thanks for sorting this out! :-) //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/
Re: [PATCH] checkpatch.pl: Add warning for harmful goto labels
On Sat, Mar 21, 2015 at 05:41:04PM -0400, Peter Hurley wrote: > Hi Alberto, > > On 03/21/2015 05:16 PM, L. Alberto Giménez wrote: > > Issue a warning for too broad goto labels that may make the code to > > follow the wrong exit path, thus causing hard to debug bugs. > > What compiler allowed duplicate goto labels? Humans are bad at following code paths, and making modifications to such code may lead to errors if the code is not descriptive enough, please check my reply to Richard for an explanation. Regards, -- L. Alberto Giménez GnuPG key ID 0xDD4E27AB -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch.pl: Add warning for harmful goto labels
On Sat, Mar 21, 2015 at 10:40:46PM +0100, Richard Weinberger wrote: > Huh? Since when? There are a lot of cases where a too generic goto label for cleanup causes a bug or makes debugging harder. Last time was this G+ post, by Dan Carpenter: https://plus.google.com/106378716002406849458/posts/DfuAkt8szf2 > rw@azrael:~/linux (for-v4.1/uml_misc $)> git grep -e "goto out;" | wc -l > 26667 > rw@azrael:~/linux (for-v4.1/uml_misc $)> git grep -e "goto fail;" | wc -l > 3733 If something is already in the kernel code, does that mean that it's OK? I honestly don't think so, and I think that goto labels for cleanup exit paths should be a little more descriptive. > What is next? Variable name "i" considered harmful? No one complained about that so far. I might add that to checkpatch.pl if needed. > Can we please stop this nonsense. It's just a proposal for a warning. If it is really not needed, it won't be applied and life will go on :) -- L. Alberto Giménez GnuPG key ID 0xDD4E27AB -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: JFS readdir() issues in stable 3.2
On 03/20/2015 06:33 PM, Richard Weinberger wrote: > Hi! > > Mainline commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 > (jfs: fix readdir cookie incompatibility with NFSv4) does not work as > expected on 3.2. > Maybe on other stable kernels too. > > UML stumbled over it: > https://bugzilla.kernel.org/show_bug.cgi?id=94741 > > If you run the attached readdir.c on a JFS on stable 3.2.51+ readdir() will > not > increment the directory offset nor return NULL, hence the caller will loop > forever. > It looks like if the current directory offset is > 0 and you run > seekdir(telldir()) > the next readdir() call will not increment it. The backport failed to pass the proper position to filldir() for the . and .. entries. I've attached a proposed patch to the above bug. > > Dave, has your fix some unnamed dependencies which need backporting too? > > Thanks, > //richard Thanks! Shaggy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dmaengine: virt-dma: don't always free descriptor upon completion
This patch attempts to enhance the case of a transfer submitted multiple
times, and where the cost of creating the descriptors chain is not
negligible.
This happens with big video buffers (several megabytes, ie. several
thousands of linked descriptors in one scatter-gather list). In these
cases, a video driver would want to do :
- tx = dmaengine_prep_slave_sg()
- dma_engine_submit(tx);
- dma_async_issue_pending()
- wait for video completion
- read video data (or not, skipping a frame is also possible)
- dma_engine_submit(tx)
=> here, the descriptors chain recalculation will take time
=> the dma coherent allocation over and over might create holes in
the dma pool, which is counter-productive.
- dma_async_issue_pending()
- etc ...
In order to cope with this case, virt-dma is modified to prevent freeing
the descriptors upon completion if DMA_CTRL_ACK flag is set in the
transfer.
Signed-off-by: Robert Jarzmik
Cc: Lars-Peter Clausen
---
drivers/dma/virt-dma.c | 19 +--
drivers/dma/virt-dma.h | 13 -
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/virt-dma.c b/drivers/dma/virt-dma.c
index 6f80432..7d2c17d 100644
--- a/drivers/dma/virt-dma.c
+++ b/drivers/dma/virt-dma.c
@@ -29,7 +29,7 @@ dma_cookie_t vchan_tx_submit(struct dma_async_tx_descriptor
*tx)
spin_lock_irqsave(&vc->lock, flags);
cookie = dma_cookie_assign(tx);
- list_add_tail(&vd->node, &vc->desc_submitted);
+ list_move_tail(&vd->node, &vc->desc_submitted);
spin_unlock_irqrestore(&vc->lock, flags);
dev_dbg(vc->chan.device->dev, "vchan %p: txd %p[%x]: submitted\n",
@@ -83,8 +83,10 @@ static void vchan_complete(unsigned long arg)
cb_data = vd->tx.callback_param;
list_del(&vd->node);
-
- vc->desc_free(vd);
+ if (async_tx_test_ack(&vd->tx))
+ list_add(&vd->node, &vc->desc_allocated);
+ else
+ vc->desc_free(vd);
if (cb)
cb(cb_data);
@@ -96,9 +98,13 @@ void vchan_dma_desc_free_list(struct virt_dma_chan *vc,
struct list_head *head)
while (!list_empty(head)) {
struct virt_dma_desc *vd = list_first_entry(head,
struct virt_dma_desc, node);
- list_del(&vd->node);
- dev_dbg(vc->chan.device->dev, "txd %p: freeing\n", vd);
- vc->desc_free(vd);
+ if (async_tx_test_ack(&vd->tx)) {
+ list_move_tail(&vd->node, &vc->desc_allocated);
+ } else {
+ dev_dbg(vc->chan.device->dev, "txd %p: freeing\n", vd);
+ list_del(&vd->node);
+ vc->desc_free(vd);
+ }
}
}
EXPORT_SYMBOL_GPL(vchan_dma_desc_free_list);
@@ -108,6 +114,7 @@ void vchan_init(struct virt_dma_chan *vc, struct dma_device
*dmadev)
dma_cookie_init(&vc->chan);
spin_lock_init(&vc->lock);
+ INIT_LIST_HEAD(&vc->desc_allocated);
INIT_LIST_HEAD(&vc->desc_submitted);
INIT_LIST_HEAD(&vc->desc_issued);
INIT_LIST_HEAD(&vc->desc_completed);
diff --git a/drivers/dma/virt-dma.h b/drivers/dma/virt-dma.h
index 181b952..189e75d 100644
--- a/drivers/dma/virt-dma.h
+++ b/drivers/dma/virt-dma.h
@@ -29,6 +29,7 @@ struct virt_dma_chan {
spinlock_t lock;
/* protected by vc.lock */
+ struct list_head desc_allocated;
struct list_head desc_submitted;
struct list_head desc_issued;
struct list_head desc_completed;
@@ -55,11 +56,16 @@ static inline struct dma_async_tx_descriptor
*vchan_tx_prep(struct virt_dma_chan
struct virt_dma_desc *vd, unsigned long tx_flags)
{
extern dma_cookie_t vchan_tx_submit(struct dma_async_tx_descriptor *);
+ unsigned long flags;
dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
vd->tx.flags = tx_flags;
vd->tx.tx_submit = vchan_tx_submit;
+ spin_lock_irqsave(&vc->lock, flags);
+ list_add_tail(&vd->node, &vc->desc_allocated);
+ spin_unlock_irqrestore(&vc->lock, flags);
+
return &vd->tx;
}
@@ -122,7 +128,8 @@ static inline struct virt_dma_desc *vchan_next_desc(struct
virt_dma_chan *vc)
}
/**
- * vchan_get_all_descriptors - obtain all submitted and issued descriptors
+ * vchan_get_all_descriptors - obtain all allocated, submitted and issued
+ * descriptors
* vc: virtual channel to get descriptors from
* head: list of descriptors found
*
@@ -134,6 +141,7 @@ static inline struct virt_dma_desc *vchan_next_desc(struct
virt_dma_chan *vc)
static inline void vchan_get_all_descriptors(struct virt_dma_chan *vc,
struct list_head *head)
{
+ list_splice_tail_init(&vc->desc_allocated, head);
list_splice_tail_init(&vc->desc_submitted, head);
list_splice_tail_init(&vc->desc_issued
[PATCH net-next V2 03/23] ptp: use the 64 bit get/set time methods for the posix clock.
This patch changes the posix clock code to prefer the new methods
whenever they are implemented by the PHC drivers.
Signed-off-by: Richard Cochran
---
drivers/ptp/ptp_clock.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index 296b0ec..df50d5e 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -107,13 +107,28 @@ static int ptp_clock_getres(struct posix_clock *pc,
struct timespec *tp)
static int ptp_clock_settime(struct posix_clock *pc, const struct timespec *tp)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
- return ptp->info->settime(ptp->info, tp);
+ struct timespec64 ts = timespec_to_timespec64(*tp);
+
+ return ptp->info->settime64 ?
+ ptp->info->settime64(ptp->info, &ts) :
+ ptp->info->settime(ptp->info, tp);
}
static int ptp_clock_gettime(struct posix_clock *pc, struct timespec *tp)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
- return ptp->info->gettime(ptp->info, tp);
+ struct timespec64 ts;
+ int err;
+
+ if (ptp->info->gettime64) {
+ err = ptp->info->gettime64(ptp->info, &ts);
+ if (!err)
+ *tp = timespec64_to_timespec(ts);
+ } else {
+ err = ptp->info->gettime(ptp->info, tp);
+ }
+
+ return err;
}
static int ptp_clock_adjtime(struct posix_clock *pc, struct timex *tx)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 02/23] ptp: use the 64 bit gettime method for the SYS_OFFSET ioctl.
This patch changes the code to use the new method whenever implemented by
the PHC driver.
Signed-off-by: Richard Cochran
---
drivers/ptp/ptp_chardev.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index f8a7609..95bcf15 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -124,7 +124,8 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
struct ptp_clock_info *ops = ptp->info;
struct ptp_clock_time *pct;
- struct timespec ts;
+ struct timespec64 ts;
+ struct timespec t2;
int enable, err = 0;
unsigned int i, pin_index;
@@ -197,16 +198,21 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
}
pct = &sysoff->ts[0];
for (i = 0; i < sysoff->n_samples; i++) {
- getnstimeofday(&ts);
+ getnstimeofday64(&ts);
pct->sec = ts.tv_sec;
pct->nsec = ts.tv_nsec;
pct++;
- ptp->info->gettime(ptp->info, &ts);
+ if (ptp->info->gettime64) {
+ ptp->info->gettime64(ptp->info, &ts);
+ } else {
+ ptp->info->gettime(ptp->info, &t2);
+ ts = timespec_to_timespec64(t2);
+ }
pct->sec = ts.tv_sec;
pct->nsec = ts.tv_nsec;
pct++;
}
- getnstimeofday(&ts);
+ getnstimeofday64(&ts);
pct->sec = ts.tv_sec;
pct->nsec = ts.tv_nsec;
if (copy_to_user((void __user *)arg, sysoff, sizeof(*sysoff)))
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 00/23] ptp: get ready for 2038
This series converts the core driver methods of the PTP Hardware Clock (PHC) subsystem to use the 64 bit version of the timespec structure, making the core API ready for the year 2038. In addition, I reviewed how each driver and device represents the time value at the hardware register level. Most of the drivers are ready, but a few will need some work before the year 2038, as shown: Patch Driver 12 drivers/net/ethernet/intel/igb/igb_ptp.c 15 ?drivers/net/ethernet/sfc/ptp.c 16 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c 18 ?drivers/net/ethernet/tile/tilegx.c 19 drivers/net/phy/dp83640.c The commit log message documents how each driver is ready or why it is not ready. For patches 15 and 18, I could not easily find out the hardware representation of the time value, so I would ask the maintainers for a review. Thanks, Richard * ChangeLog ** V2 - use the new methods in the posix clock code right away (patch #3) Richard Cochran (23): ptp: introduce get/set time methods with explicit 64 bit seconds. ptp: use the 64 bit gettime method for the SYS_OFFSET ioctl. ptp: use the 64 bit get/set time methods for the posix clock. ptp: blackfin: convert to the 64 bit get/set time methods. ptp: xgbe: convert to the 64 bit get/set time methods. ptp: bnx2x: convert to the 64 bit get/set time methods. ptp: tg3: convert to the 64 bit get/set time methods. ptp: fec: convert to the 64 bit get/set time methods. ptp: gianfar: convert to the 64 bit get/set time methods. ptp: e1000e: convert to the 64 bit get/set time methods. ptp: fm10k: convert to the 64 bit get/set time methods. ptp: i40e: convert to the 64 bit get/set time methods. ptp: igb: convert to the 64 bit get/set time methods. ptp: ixgbe: convert to the 64 bit get/set time methods. ptp: mlx4: convert to the 64 bit get/set time methods. ptp: sfc: convert to the 64 bit get/set time methods. ptp: stmmac: convert to the 64 bit get/set time methods. ptp: cpts: convert to the 64 bit get/set time methods. ptp: tilegx: convert to the 64 bit get/set time methods. ptp: dp83640: convert to the 64 bit get/set time methods. ptp: ixp46x: convert to the 64 bit get/set time methods. ptp: pch: convert to the 64 bit get/set time methods. ptp: remove 32 bit get/set methods. drivers/net/ethernet/adi/bfin_mac.c |8 ++--- drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++ drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 ++--- drivers/net/ethernet/broadcom/tg3.c | 10 +++--- drivers/net/ethernet/freescale/fec_ptp.c |8 ++--- drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++ drivers/net/ethernet/intel/e1000e/ptp.c | 16 - drivers/net/ethernet/intel/fm10k/fm10k_ptp.c | 12 +++ drivers/net/ethernet/intel/i40e/i40e_ptp.c | 26 +++--- drivers/net/ethernet/intel/igb/igb_ptp.c | 41 +++--- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 drivers/net/ethernet/mellanox/mlx4/en_clock.c| 11 +++--- drivers/net/ethernet/sfc/ptp.c | 22 ++-- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8 ++--- drivers/net/ethernet/ti/cpts.c | 12 +++ drivers/net/ethernet/tile/tilegx.c | 16 + drivers/net/phy/dp83640.c| 12 --- drivers/ptp/ptp_chardev.c|8 ++--- drivers/ptp/ptp_clock.c | 12 +-- drivers/ptp/ptp_ixp46x.c |8 ++--- drivers/ptp/ptp_pch.c|8 ++--- include/linux/ptp_clock_kernel.h | 12 +++ 22 files changed, 158 insertions(+), 140 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 05/23] ptp: xgbe: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
b/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
index f326178..b03e4f5 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
@@ -179,7 +179,7 @@ static int xgbe_adjtime(struct ptp_clock_info *info, s64
delta)
return 0;
}
-static int xgbe_gettime(struct ptp_clock_info *info, struct timespec *ts)
+static int xgbe_gettime(struct ptp_clock_info *info, struct timespec64 *ts)
{
struct xgbe_prv_data *pdata = container_of(info,
struct xgbe_prv_data,
@@ -193,12 +193,13 @@ static int xgbe_gettime(struct ptp_clock_info *info,
struct timespec *ts)
spin_unlock_irqrestore(&pdata->tstamp_lock, flags);
- *ts = ns_to_timespec(nsec);
+ *ts = ns_to_timespec64(nsec);
return 0;
}
-static int xgbe_settime(struct ptp_clock_info *info, const struct timespec *ts)
+static int xgbe_settime(struct ptp_clock_info *info,
+ const struct timespec64 *ts)
{
struct xgbe_prv_data *pdata = container_of(info,
struct xgbe_prv_data,
@@ -206,7 +207,7 @@ static int xgbe_settime(struct ptp_clock_info *info, const
struct timespec *ts)
unsigned long flags;
u64 nsec;
- nsec = timespec_to_ns(ts);
+ nsec = timespec64_to_ns(ts);
spin_lock_irqsave(&pdata->tstamp_lock, flags);
@@ -236,8 +237,8 @@ void xgbe_ptp_register(struct xgbe_prv_data *pdata)
info->max_adj = pdata->ptpclk_rate;
info->adjfreq = xgbe_adjfreq;
info->adjtime = xgbe_adjtime;
- info->gettime = xgbe_gettime;
- info->settime = xgbe_settime;
+ info->gettime64 = xgbe_gettime;
+ info->settime64 = xgbe_settime;
info->enable = xgbe_enable;
clock = ptp_clock_register(info, pdata->dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 10/23] ptp: e1000e: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/intel/e1000e/ptp.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ptp.c
b/drivers/net/ethernet/intel/e1000e/ptp.c
index 1490f1e..b747a3e 100644
--- a/drivers/net/ethernet/intel/e1000e/ptp.c
+++ b/drivers/net/ethernet/intel/e1000e/ptp.c
@@ -106,7 +106,7 @@ static int e1000e_phc_adjtime(struct ptp_clock_info *ptp,
s64 delta)
* Read the timecounter and return the correct value in ns after converting
* it into a struct timespec.
**/
-static int e1000e_phc_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int e1000e_phc_gettime(struct ptp_clock_info *ptp, struct timespec64
*ts)
{
struct e1000_adapter *adapter = container_of(ptp, struct e1000_adapter,
ptp_clock_info);
@@ -133,14 +133,14 @@ static int e1000e_phc_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
* wall timer value.
**/
static int e1000e_phc_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct e1000_adapter *adapter = container_of(ptp, struct e1000_adapter,
ptp_clock_info);
unsigned long flags;
u64 ns;
- ns = timespec_to_ns(ts);
+ ns = timespec64_to_ns(ts);
/* reset the timecounter */
spin_lock_irqsave(&adapter->systim_lock, flags);
@@ -171,11 +171,11 @@ static void e1000e_systim_overflow_work(struct
work_struct *work)
struct e1000_adapter *adapter = container_of(work, struct e1000_adapter,
systim_overflow_work.work);
struct e1000_hw *hw = &adapter->hw;
- struct timespec ts;
+ struct timespec64 ts;
- adapter->ptp_clock_info.gettime(&adapter->ptp_clock_info, &ts);
+ adapter->ptp_clock_info.gettime64(&adapter->ptp_clock_info, &ts);
- e_dbg("SYSTIM overflow check at %ld.%09lu\n", ts.tv_sec, ts.tv_nsec);
+ e_dbg("SYSTIM overflow check at %lld.%09lu\n", ts.tv_sec, ts.tv_nsec);
schedule_delayed_work(&adapter->systim_overflow_work,
E1000_SYSTIM_OVERFLOW_PERIOD);
@@ -190,8 +190,8 @@ static const struct ptp_clock_info e1000e_ptp_clock_info = {
.pps= 0,
.adjfreq= e1000e_phc_adjfreq,
.adjtime= e1000e_phc_adjtime,
- .gettime= e1000e_phc_gettime,
- .settime= e1000e_phc_settime,
+ .gettime64 = e1000e_phc_gettime,
+ .settime64 = e1000e_phc_settime,
.enable = e1000e_phc_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 06/23] ptp: bnx2x: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 9677431..765667c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13278,7 +13278,7 @@ static int bnx2x_ptp_adjtime(struct ptp_clock_info
*ptp, s64 delta)
return 0;
}
-static int bnx2x_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int bnx2x_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
@@ -13295,7 +13295,7 @@ static int bnx2x_ptp_gettime(struct ptp_clock_info
*ptp, struct timespec *ts)
}
static int bnx2x_ptp_settime(struct ptp_clock_info *ptp,
-const struct timespec *ts)
+const struct timespec64 *ts)
{
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
@@ -1,8 +1,8 @@ static void bnx2x_register_phc(struct bnx2x *bp)
bp->ptp_clock_info.pps = 0;
bp->ptp_clock_info.adjfreq = bnx2x_ptp_adjfreq;
bp->ptp_clock_info.adjtime = bnx2x_ptp_adjtime;
- bp->ptp_clock_info.gettime = bnx2x_ptp_gettime;
- bp->ptp_clock_info.settime = bnx2x_ptp_settime;
+ bp->ptp_clock_info.gettime64 = bnx2x_ptp_gettime;
+ bp->ptp_clock_info.settime64 = bnx2x_ptp_settime;
bp->ptp_clock_info.enable = bnx2x_ptp_enable;
bp->ptp_clock = ptp_clock_register(&bp->ptp_clock_info, &bp->pdev->dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 08/23] ptp: fec: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/freescale/fec_ptp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c
b/drivers/net/ethernet/freescale/fec_ptp.c
index 4585895..b833993 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c
@@ -390,7 +390,7 @@ static int fec_ptp_adjtime(struct ptp_clock_info *ptp, s64
delta)
* read the timecounter and return the correct value on ns,
* after converting it into a struct timespec.
*/
-static int fec_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int fec_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct fec_enet_private *adapter =
container_of(ptp, struct fec_enet_private, ptp_caps);
@@ -417,7 +417,7 @@ static int fec_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
* wall timer value.
*/
static int fec_ptp_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct fec_enet_private *fep =
container_of(ptp, struct fec_enet_private, ptp_caps);
@@ -584,8 +584,8 @@ void fec_ptp_init(struct platform_device *pdev)
fep->ptp_caps.pps = 1;
fep->ptp_caps.adjfreq = fec_ptp_adjfreq;
fep->ptp_caps.adjtime = fec_ptp_adjtime;
- fep->ptp_caps.gettime = fec_ptp_gettime;
- fep->ptp_caps.settime = fec_ptp_settime;
+ fep->ptp_caps.gettime64 = fec_ptp_gettime;
+ fep->ptp_caps.settime64 = fec_ptp_settime;
fep->ptp_caps.enable = fec_ptp_enable;
fep->cycle_speed = clk_get_rate(fep->clk_ptp);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 09/23] ptp: gianfar: convert to the 64 bit get/set time methods.
The device features a 64 bit nanoseconds register, and so with this
patch the driver is ready for the year 2038.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c
b/drivers/net/ethernet/freescale/gianfar_ptp.c
index 77353366..04265a7 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -322,7 +322,8 @@ static int ptp_gianfar_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return 0;
}
-static int ptp_gianfar_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int ptp_gianfar_gettime(struct ptp_clock_info *ptp,
+ struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -341,7 +342,7 @@ static int ptp_gianfar_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int ptp_gianfar_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
unsigned long flags;
@@ -418,8 +419,8 @@ static struct ptp_clock_info ptp_gianfar_caps = {
.pps= 1,
.adjfreq= ptp_gianfar_adjfreq,
.adjtime= ptp_gianfar_adjtime,
- .gettime= ptp_gianfar_gettime,
- .settime= ptp_gianfar_settime,
+ .gettime64 = ptp_gianfar_gettime,
+ .settime64 = ptp_gianfar_settime,
.enable = ptp_gianfar_enable,
};
@@ -440,7 +441,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
{
struct device_node *node = dev->dev.of_node;
struct etsects *etsects;
- struct timespec now;
+ struct timespec64 now;
int err = -ENOMEM;
u32 tmr_ctrl;
unsigned long flags;
@@ -495,7 +496,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
pr_err("ioremap ptp registers failed\n");
goto no_ioremap;
}
- getnstimeofday(&now);
+ getnstimeofday64(&now);
ptp_gianfar_settime(&etsects->caps, &now);
tmr_ctrl =
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 18/23] ptp: cpts: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/ti/cpts.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index fbe42cb..074b636 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -167,7 +167,7 @@ static int cpts_ptp_adjtime(struct ptp_clock_info *ptp, s64
delta)
return 0;
}
-static int cpts_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int cpts_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -185,7 +185,7 @@ static int cpts_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int cpts_ptp_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
unsigned long flags;
@@ -216,20 +216,20 @@ static struct ptp_clock_info cpts_info = {
.pps= 0,
.adjfreq= cpts_ptp_adjfreq,
.adjtime= cpts_ptp_adjtime,
- .gettime= cpts_ptp_gettime,
- .settime= cpts_ptp_settime,
+ .gettime64 = cpts_ptp_gettime,
+ .settime64 = cpts_ptp_settime,
.enable = cpts_ptp_enable,
};
static void cpts_overflow_check(struct work_struct *work)
{
- struct timespec ts;
+ struct timespec64 ts;
struct cpts *cpts = container_of(work, struct cpts, overflow_work.work);
cpts_write32(cpts, CPTS_EN, control);
cpts_write32(cpts, TS_PEND_EN, int_enable);
cpts_ptp_gettime(&cpts->info, &ts);
- pr_debug("cpts overflow check at %ld.%09lu\n", ts.tv_sec, ts.tv_nsec);
+ pr_debug("cpts overflow check at %lld.%09lu\n", ts.tv_sec, ts.tv_nsec);
schedule_delayed_work(&cpts->overflow_work, CPTS_OVERFLOW_PERIOD);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 17/23] ptp: stmmac: convert to the 64 bit get/set time methods.
This device stores the number of seconds in a 32 bit register. So
more work is needed on this driver before the year 2038 comes around.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index c5ee79d8..172f318 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -105,7 +105,7 @@ static int stmmac_adjust_time(struct ptp_clock_info *ptp,
s64 delta)
* Description: this function will read the current time from the
* hardware clock and store it in @ts.
*/
-static int stmmac_get_time(struct ptp_clock_info *ptp, struct timespec *ts)
+static int stmmac_get_time(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct stmmac_priv *priv =
container_of(ptp, struct stmmac_priv, ptp_clock_ops);
@@ -135,7 +135,7 @@ static int stmmac_get_time(struct ptp_clock_info *ptp,
struct timespec *ts)
* hardware clock.
*/
static int stmmac_set_time(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct stmmac_priv *priv =
container_of(ptp, struct stmmac_priv, ptp_clock_ops);
@@ -168,8 +168,8 @@ static struct ptp_clock_info stmmac_ptp_clock_ops = {
.pps = 0,
.adjfreq = stmmac_adjust_freq,
.adjtime = stmmac_adjust_time,
- .gettime = stmmac_get_time,
- .settime = stmmac_set_time,
+ .gettime64 = stmmac_get_time,
+ .settime64 = stmmac_set_time,
.enable = stmmac_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 13/23] ptp: igb: convert to the 64 bit get/set time methods.
For the 82576, the driver's clock is implemented using a timecounter,
and so with this patch that device is ready for the year 2038.
However, in the case of the i210, the device stores the number of
seconds in a 32 bit register. Therefore, more work is needed on this
driver before the year 2038 comes around.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/intel/igb/igb_ptp.c | 41 +++---
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c
b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 52d01b8..0348b7e 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -116,7 +116,8 @@ static cycle_t igb_ptp_read_82580(const struct cyclecounter
*cc)
}
/* SYSTIM read access for I210/I211 */
-static void igb_ptp_read_i210(struct igb_adapter *adapter, struct timespec *ts)
+static void igb_ptp_read_i210(struct igb_adapter *adapter,
+ struct timespec64 *ts)
{
struct e1000_hw *hw = &adapter->hw;
u32 sec, nsec;
@@ -134,7 +135,7 @@ static void igb_ptp_read_i210(struct igb_adapter *adapter,
struct timespec *ts)
}
static void igb_ptp_write_i210(struct igb_adapter *adapter,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct e1000_hw *hw = &adapter->hw;
@@ -269,13 +270,13 @@ static int igb_ptp_adjtime_i210(struct ptp_clock_info
*ptp, s64 delta)
struct igb_adapter *igb = container_of(ptp, struct igb_adapter,
ptp_caps);
unsigned long flags;
- struct timespec now, then = ns_to_timespec(delta);
+ struct timespec64 now, then = ns_to_timespec64(delta);
spin_lock_irqsave(&igb->tmreg_lock, flags);
igb_ptp_read_i210(igb, &now);
- now = timespec_add(now, then);
- igb_ptp_write_i210(igb, (const struct timespec *)&now);
+ now = timespec64_add(now, then);
+ igb_ptp_write_i210(igb, (const struct timespec64 *)&now);
spin_unlock_irqrestore(&igb->tmreg_lock, flags);
@@ -283,7 +284,7 @@ static int igb_ptp_adjtime_i210(struct ptp_clock_info *ptp,
s64 delta)
}
static int igb_ptp_gettime_82576(struct ptp_clock_info *ptp,
-struct timespec *ts)
+struct timespec64 *ts)
{
struct igb_adapter *igb = container_of(ptp, struct igb_adapter,
ptp_caps);
@@ -304,7 +305,7 @@ static int igb_ptp_gettime_82576(struct ptp_clock_info *ptp,
}
static int igb_ptp_gettime_i210(struct ptp_clock_info *ptp,
- struct timespec *ts)
+ struct timespec64 *ts)
{
struct igb_adapter *igb = container_of(ptp, struct igb_adapter,
ptp_caps);
@@ -320,7 +321,7 @@ static int igb_ptp_gettime_i210(struct ptp_clock_info *ptp,
}
static int igb_ptp_settime_82576(struct ptp_clock_info *ptp,
-const struct timespec *ts)
+const struct timespec64 *ts)
{
struct igb_adapter *igb = container_of(ptp, struct igb_adapter,
ptp_caps);
@@ -340,7 +341,7 @@ static int igb_ptp_settime_82576(struct ptp_clock_info *ptp,
}
static int igb_ptp_settime_i210(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct igb_adapter *igb = container_of(ptp, struct igb_adapter,
ptp_caps);
@@ -627,11 +628,11 @@ static void igb_ptp_overflow_check(struct work_struct
*work)
{
struct igb_adapter *igb =
container_of(work, struct igb_adapter, ptp_overflow_work.work);
- struct timespec ts;
+ struct timespec64 ts;
- igb->ptp_caps.gettime(&igb->ptp_caps, &ts);
+ igb->ptp_caps.gettime64(&igb->ptp_caps, &ts);
- pr_debug("igb overflow check at %ld.%09lu\n", ts.tv_sec, ts.tv_nsec);
+ pr_debug("igb overflow check at %lld.%09lu\n", ts.tv_sec, ts.tv_nsec);
schedule_delayed_work(&igb->ptp_overflow_work,
IGB_SYSTIM_OVERFLOW_PERIOD);
@@ -989,8 +990,8 @@ void igb_ptp_init(struct igb_adapter *adapter)
adapter->ptp_caps.pps = 0;
adapter->ptp_caps.adjfreq = igb_ptp_adjfreq_82576;
adapter->ptp_caps.adjtime = igb_ptp_adjtime_82576;
- adapter->ptp_caps.gettime = igb_ptp_gettime_82576;
- adapter->ptp_caps.settime = igb_ptp_settime_82576;
+ adapter->ptp_caps.gettime64 = igb_ptp_gettime_82576;
+ adapter->ptp_caps.settime64 = igb_ptp_settime_82576;
adapter->ptp_caps.enable = igb_ptp_feat
[PATCH net-next V2 15/23] ptp: mlx4: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
index 90b5309..666e7bd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
@@ -164,7 +164,8 @@ static int mlx4_en_phc_adjtime(struct ptp_clock_info *ptp,
s64 delta)
* Read the timecounter and return the correct value in ns after converting
* it into a struct timespec.
**/
-static int mlx4_en_phc_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int mlx4_en_phc_gettime(struct ptp_clock_info *ptp,
+ struct timespec64 *ts)
{
struct mlx4_en_dev *mdev = container_of(ptp, struct mlx4_en_dev,
ptp_clock_info);
@@ -191,11 +192,11 @@ static int mlx4_en_phc_gettime(struct ptp_clock_info
*ptp, struct timespec *ts)
* wall timer value.
**/
static int mlx4_en_phc_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct mlx4_en_dev *mdev = container_of(ptp, struct mlx4_en_dev,
ptp_clock_info);
- u64 ns = timespec_to_ns(ts);
+ u64 ns = timespec64_to_ns(ts);
unsigned long flags;
/* reset the timecounter */
@@ -232,8 +233,8 @@ static const struct ptp_clock_info mlx4_en_ptp_clock_info =
{
.pps= 0,
.adjfreq= mlx4_en_phc_adjfreq,
.adjtime= mlx4_en_phc_adjtime,
- .gettime= mlx4_en_phc_gettime,
- .settime= mlx4_en_phc_settime,
+ .gettime64 = mlx4_en_phc_gettime,
+ .settime64 = mlx4_en_phc_settime,
.enable = mlx4_en_phc_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 16/23] ptp: sfc: convert to the 64 bit get/set time methods.
This patch changes the driver to use the newer API.
Depending on how the hardware represents a time value, this driver may
or may not yet be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/sfc/ptp.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ptp.c b/drivers/net/ethernet/sfc/ptp.c
index 6b861e3..a2e9aee 100644
--- a/drivers/net/ethernet/sfc/ptp.c
+++ b/drivers/net/ethernet/sfc/ptp.c
@@ -323,9 +323,9 @@ struct efx_ptp_data {
static int efx_phc_adjfreq(struct ptp_clock_info *ptp, s32 delta);
static int efx_phc_adjtime(struct ptp_clock_info *ptp, s64 delta);
-static int efx_phc_gettime(struct ptp_clock_info *ptp, struct timespec *ts);
+static int efx_phc_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts);
static int efx_phc_settime(struct ptp_clock_info *ptp,
- const struct timespec *e_ts);
+ const struct timespec64 *e_ts);
static int efx_phc_enable(struct ptp_clock_info *ptp,
struct ptp_clock_request *request, int on);
@@ -1198,8 +1198,8 @@ static const struct ptp_clock_info efx_phc_clock_info = {
.pps= 1,
.adjfreq= efx_phc_adjfreq,
.adjtime= efx_phc_adjtime,
- .gettime= efx_phc_gettime,
- .settime= efx_phc_settime,
+ .gettime64 = efx_phc_gettime,
+ .settime64 = efx_phc_settime,
.enable = efx_phc_enable,
};
@@ -1837,7 +1837,7 @@ static int efx_phc_adjtime(struct ptp_clock_info *ptp,
s64 delta)
NULL, 0, NULL);
}
-static int efx_phc_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int efx_phc_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct efx_ptp_data *ptp_data = container_of(ptp,
struct efx_ptp_data,
@@ -1859,28 +1859,28 @@ static int efx_phc_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
kt = ptp_data->nic_to_kernel_time(
MCDI_DWORD(outbuf, PTP_OUT_READ_NIC_TIME_MAJOR),
MCDI_DWORD(outbuf, PTP_OUT_READ_NIC_TIME_MINOR), 0);
- *ts = ktime_to_timespec(kt);
+ *ts = ktime_to_timespec64(kt);
return 0;
}
static int efx_phc_settime(struct ptp_clock_info *ptp,
- const struct timespec *e_ts)
+ const struct timespec64 *e_ts)
{
/* Get the current NIC time, efx_phc_gettime.
* Subtract from the desired time to get the offset
* call efx_phc_adjtime with the offset
*/
int rc;
- struct timespec time_now;
- struct timespec delta;
+ struct timespec64 time_now;
+ struct timespec64 delta;
rc = efx_phc_gettime(ptp, &time_now);
if (rc != 0)
return rc;
- delta = timespec_sub(*e_ts, time_now);
+ delta = timespec64_sub(*e_ts, time_now);
- rc = efx_phc_adjtime(ptp, timespec_to_ns(&delta));
+ rc = efx_phc_adjtime(ptp, timespec64_to_ns(&delta));
if (rc != 0)
return rc;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 14/23] ptp: ixgbe: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index bd46f5d..75b9e93 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -279,7 +279,7 @@ static int ixgbe_ptp_adjtime(struct ptp_clock_info *ptp,
s64 delta)
* read the timecounter and return the correct value on ns,
* after converting it into a struct timespec.
*/
-static int ixgbe_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int ixgbe_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct ixgbe_adapter *adapter =
container_of(ptp, struct ixgbe_adapter, ptp_caps);
@@ -306,7 +306,7 @@ static int ixgbe_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
* wall timer value.
*/
static int ixgbe_ptp_settime(struct ptp_clock_info *ptp,
-const struct timespec *ts)
+const struct timespec64 *ts)
{
struct ixgbe_adapter *adapter =
container_of(ptp, struct ixgbe_adapter, ptp_caps);
@@ -407,7 +407,7 @@ void ixgbe_ptp_overflow_check(struct ixgbe_adapter *adapter)
{
bool timeout = time_is_before_jiffies(adapter->last_overflow_check +
IXGBE_OVERFLOW_PERIOD);
- struct timespec ts;
+ struct timespec64 ts;
if (timeout) {
ixgbe_ptp_gettime(&adapter->ptp_caps, &ts);
@@ -874,8 +874,8 @@ static int ixgbe_ptp_create_clock(struct ixgbe_adapter
*adapter)
adapter->ptp_caps.pps = 1;
adapter->ptp_caps.adjfreq = ixgbe_ptp_adjfreq;
adapter->ptp_caps.adjtime = ixgbe_ptp_adjtime;
- adapter->ptp_caps.gettime = ixgbe_ptp_gettime;
- adapter->ptp_caps.settime = ixgbe_ptp_settime;
+ adapter->ptp_caps.gettime64 = ixgbe_ptp_gettime;
+ adapter->ptp_caps.settime64 = ixgbe_ptp_settime;
adapter->ptp_caps.enable = ixgbe_ptp_feature_enable;
break;
case ixgbe_mac_82599EB:
@@ -890,8 +890,8 @@ static int ixgbe_ptp_create_clock(struct ixgbe_adapter
*adapter)
adapter->ptp_caps.pps = 0;
adapter->ptp_caps.adjfreq = ixgbe_ptp_adjfreq;
adapter->ptp_caps.adjtime = ixgbe_ptp_adjtime;
- adapter->ptp_caps.gettime = ixgbe_ptp_gettime;
- adapter->ptp_caps.settime = ixgbe_ptp_settime;
+ adapter->ptp_caps.gettime64 = ixgbe_ptp_gettime;
+ adapter->ptp_caps.settime64 = ixgbe_ptp_settime;
adapter->ptp_caps.enable = ixgbe_ptp_feature_enable;
break;
default:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lguest: simplify lguest_iret
Signed-off-by: Denys Vlasenko CC: lgu...@lists.ozlabs.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/lguest/head_32.S | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/arch/x86/lguest/head_32.S b/arch/x86/lguest/head_32.S index 6ddfe4f..583732c 100644 --- a/arch/x86/lguest/head_32.S +++ b/arch/x86/lguest/head_32.S @@ -168,29 +168,28 @@ ENTRY(lg_restore_fl) * So we have to copy eflags from the stack to lguest_data.irq_enabled before * we do the "iret". * - * There are two problems with this: firstly, we need to use a register to do - * the copy and secondly, the whole thing needs to be atomic. The first - * problem is easy to solve: push %eax on the stack so we can use it, and then - * restore it at the end just before the real "iret". + * There are two problems with this: firstly, we can't clobber any registers + * and secondly, the whole thing needs to be atomic. The first problem + * is solved by using "push memory"/"pop memory" instruction pair for copying. * * The second is harder: copying eflags to lguest_data.irq_enabled will turn * interrupts on before we're finished, so we could be interrupted before we * return to userspace or wherever. Our solution to this is to surround the * code with lguest_noirq_start: and lguest_noirq_end: labels. We tell the * Host that it is *never* to interrupt us there, even if interrupts seem to be - * enabled. + * enabled. (It's not necessary to protect pop instruction, since + * data gets updated only after it completes, so we end up surrounding + * just one instruction, iret). */ ENTRY(lguest_iret) - pushl %eax - movl12(%esp), %eax -lguest_noirq_start: + pushl 2*4(%esp) /* * Note the %ss: segment prefix here. Normal data accesses use the * "ds" segment, but that will have already been restored for whatever * we're returning to (such as userspace): we can't trust it. The %ss: * prefix makes sure we use the stack segment, which is still valid. */ - movl%eax,%ss:lguest_data+LGUEST_DATA_irq_enabled - popl%eax + popl%ss:lguest_data+LGUEST_DATA_irq_enabled +lguest_noirq_start: iret lguest_noirq_end: -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 20/23] ptp: dp83640: convert to the 64 bit get/set time methods.
This device stores the number of seconds in a 32 bit register. So
more work is needed on this driver before the year 2038 comes around.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/phy/dp83640.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index e22e602..1a88235 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -427,7 +427,8 @@ static int ptp_dp83640_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return err;
}
-static int ptp_dp83640_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int ptp_dp83640_gettime(struct ptp_clock_info *ptp,
+ struct timespec64 *ts)
{
struct dp83640_clock *clock =
container_of(ptp, struct dp83640_clock, caps);
@@ -452,16 +453,17 @@ static int ptp_dp83640_gettime(struct ptp_clock_info
*ptp, struct timespec *ts)
}
static int ptp_dp83640_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts64)
{
struct dp83640_clock *clock =
container_of(ptp, struct dp83640_clock, caps);
struct phy_device *phydev = clock->chosen->phydev;
+ struct timespec ts = timespec64_to_timespec(*ts64);
int err;
mutex_lock(&clock->extreg_lock);
- err = tdr_write(1, phydev, ts, PTP_LOAD_CLK);
+ err = tdr_write(1, phydev, &ts, PTP_LOAD_CLK);
mutex_unlock(&clock->extreg_lock);
@@ -998,8 +1000,8 @@ static void dp83640_clock_init(struct dp83640_clock
*clock, struct mii_bus *bus)
clock->caps.pps = 0;
clock->caps.adjfreq = ptp_dp83640_adjfreq;
clock->caps.adjtime = ptp_dp83640_adjtime;
- clock->caps.gettime = ptp_dp83640_gettime;
- clock->caps.settime = ptp_dp83640_settime;
+ clock->caps.gettime64 = ptp_dp83640_gettime;
+ clock->caps.settime64 = ptp_dp83640_settime;
clock->caps.enable = ptp_dp83640_enable;
clock->caps.verify = ptp_dp83640_verify;
/*
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 22/23] ptp: pch: convert to the 64 bit get/set time methods.
The device has a 64 bit clock register, where each clock tick is 32
nanoseconds, and so with this patch the driver is ready for the year
2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/ptp/ptp_pch.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index 2554872..3aa22ae 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -449,7 +449,7 @@ static int ptp_pch_adjtime(struct ptp_clock_info *ptp, s64
delta)
return 0;
}
-static int ptp_pch_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int ptp_pch_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -467,7 +467,7 @@ static int ptp_pch_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int ptp_pch_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
unsigned long flags;
@@ -518,8 +518,8 @@ static struct ptp_clock_info ptp_pch_caps = {
.pps= 0,
.adjfreq= ptp_pch_adjfreq,
.adjtime= ptp_pch_adjtime,
- .gettime= ptp_pch_gettime,
- .settime= ptp_pch_settime,
+ .gettime64 = ptp_pch_gettime,
+ .settime64 = ptp_pch_settime,
.enable = ptp_pch_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 21/23] ptp: ixp46x: convert to the 64 bit get/set time methods.
The device has a 64 bit clock register, where each clock tick is 16
nanoseconds, and so with this patch the driver is ready for the year
2038.
Signed-off-by: Richard Cochran
---
drivers/ptp/ptp_ixp46x.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ptp/ptp_ixp46x.c b/drivers/ptp/ptp_ixp46x.c
index 604d340..934c139 100644
--- a/drivers/ptp/ptp_ixp46x.c
+++ b/drivers/ptp/ptp_ixp46x.c
@@ -175,7 +175,7 @@ static int ptp_ixp_adjtime(struct ptp_clock_info *ptp, s64
delta)
return 0;
}
-static int ptp_ixp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int ptp_ixp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -195,7 +195,7 @@ static int ptp_ixp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int ptp_ixp_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
unsigned long flags;
@@ -248,8 +248,8 @@ static struct ptp_clock_info ptp_ixp_caps = {
.pps= 0,
.adjfreq= ptp_ixp_adjfreq,
.adjtime= ptp_ixp_adjtime,
- .gettime= ptp_ixp_gettime,
- .settime= ptp_ixp_settime,
+ .gettime64 = ptp_ixp_gettime,
+ .settime64 = ptp_ixp_settime,
.enable = ptp_ixp_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 19/23] ptp: tilegx: convert to the 64 bit get/set time methods.
This driver calls code (via gxio_mpipe_get/set_timestamp) that makes
the assumption that the tv_sec field is 64 bits wide. So apparently
this driver is 64 bit only. So maybe this driver and device are ready
for 2038, but maybe not.
Not even compile tested.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/tile/tilegx.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index bea8cd2..614ea83 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net/ethernet/tile/tilegx.c
@@ -838,24 +838,28 @@ static int ptp_mpipe_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return ret;
}
-static int ptp_mpipe_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int ptp_mpipe_gettime(struct ptp_clock_info *ptp,
+struct timespec64 *ts64)
{
int ret = 0;
struct mpipe_data *md = container_of(ptp, struct mpipe_data, caps);
+ struct timespec ts;
mutex_lock(&md->ptp_lock);
- if (gxio_mpipe_get_timestamp(&md->context, ts))
+ if (gxio_mpipe_get_timestamp(&md->context, &ts))
ret = -EBUSY;
mutex_unlock(&md->ptp_lock);
+ *ts64 = timespec_to_timespec64(ts);
return ret;
}
static int ptp_mpipe_settime(struct ptp_clock_info *ptp,
-const struct timespec *ts)
+const struct timespec64 *ts64)
{
int ret = 0;
+ struct timespec ts = timespec64_to_timespec(*ts64);
struct mpipe_data *md = container_of(ptp, struct mpipe_data, caps);
mutex_lock(&md->ptp_lock);
- if (gxio_mpipe_set_timestamp(&md->context, ts))
+ if (gxio_mpipe_set_timestamp(&md->context, &ts))
ret = -EBUSY;
mutex_unlock(&md->ptp_lock);
return ret;
@@ -876,8 +880,8 @@ static struct ptp_clock_info ptp_mpipe_caps = {
.pps= 0,
.adjfreq= ptp_mpipe_adjfreq,
.adjtime= ptp_mpipe_adjtime,
- .gettime= ptp_mpipe_gettime,
- .settime= ptp_mpipe_settime,
+ .gettime64 = ptp_mpipe_gettime,
+ .settime64 = ptp_mpipe_settime,
.enable = ptp_mpipe_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 23/23] ptp: remove 32 bit get/set methods.
All of the PHC drivers have been converted to the new methods. This patch
converts the three remaining callers within the core code and removes the
older methods for good. As a result, the core PHC code is ready for the
year 2038. However, some of the PHC drivers are not quite ready yet.
Signed-off-by: Richard Cochran
---
drivers/ptp/ptp_chardev.c|8 +---
drivers/ptp/ptp_clock.c | 15 ---
include/linux/ptp_clock_kernel.h |8
3 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 95bcf15..da7bae9 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -125,7 +125,6 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
struct ptp_clock_info *ops = ptp->info;
struct ptp_clock_time *pct;
struct timespec64 ts;
- struct timespec t2;
int enable, err = 0;
unsigned int i, pin_index;
@@ -202,12 +201,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
unsigned long arg)
pct->sec = ts.tv_sec;
pct->nsec = ts.tv_nsec;
pct++;
- if (ptp->info->gettime64) {
- ptp->info->gettime64(ptp->info, &ts);
- } else {
- ptp->info->gettime(ptp->info, &t2);
- ts = timespec_to_timespec64(t2);
- }
+ ptp->info->gettime64(ptp->info, &ts);
pct->sec = ts.tv_sec;
pct->nsec = ts.tv_nsec;
pct++;
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index df50d5e..2e481b9 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -109,9 +109,7 @@ static int ptp_clock_settime(struct posix_clock *pc, const
struct timespec *tp)
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
struct timespec64 ts = timespec_to_timespec64(*tp);
- return ptp->info->settime64 ?
- ptp->info->settime64(ptp->info, &ts) :
- ptp->info->settime(ptp->info, tp);
+ return ptp->info->settime64(ptp->info, &ts);
}
static int ptp_clock_gettime(struct posix_clock *pc, struct timespec *tp)
@@ -120,14 +118,9 @@ static int ptp_clock_gettime(struct posix_clock *pc,
struct timespec *tp)
struct timespec64 ts;
int err;
- if (ptp->info->gettime64) {
- err = ptp->info->gettime64(ptp->info, &ts);
- if (!err)
- *tp = timespec64_to_timespec(ts);
- } else {
- err = ptp->info->gettime(ptp->info, tp);
- }
-
+ err = ptp->info->gettime64(ptp->info, &ts);
+ if (!err)
+ *tp = timespec64_to_timespec(ts);
return err;
}
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index 7d6f8e6..b8b7306 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -64,12 +64,6 @@ struct ptp_clock_request {
* @adjtime: Shifts the time of the hardware clock.
*parameter delta: Desired change in nanoseconds.
*
- * @gettime: Reads the current time from the hardware clock. (deprecated)
- *parameter ts: Holds the result.
- *
- * @settime: Set the current time on the hardware clock. (deprecated)
- *parameter ts: Time value to set.
- *
* @gettime64: Reads the current time from the hardware clock.
* parameter ts: Holds the result.
*
@@ -110,8 +104,6 @@ struct ptp_clock_info {
struct ptp_pin_desc *pin_config;
int (*adjfreq)(struct ptp_clock_info *ptp, s32 delta);
int (*adjtime)(struct ptp_clock_info *ptp, s64 delta);
- int (*gettime)(struct ptp_clock_info *ptp, struct timespec *ts);
- int (*settime)(struct ptp_clock_info *ptp, const struct timespec *ts);
int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
int (*settime64)(struct ptp_clock_info *p, const struct timespec64 *ts);
int (*enable)(struct ptp_clock_info *ptp,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 11/23] ptp: fm10k: convert to the 64 bit get/set time methods.
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/intel/fm10k/fm10k_ptp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
index d966044..02008e9 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
@@ -285,7 +285,7 @@ static int fm10k_ptp_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return 0;
}
-static int fm10k_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int fm10k_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct fm10k_intfc *interface;
unsigned long flags;
@@ -297,17 +297,17 @@ static int fm10k_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
now = fm10k_systime_read(interface) + interface->ptp_adjust;
read_unlock_irqrestore(&interface->systime_lock, flags);
- *ts = ns_to_timespec(now);
+ *ts = ns_to_timespec64(now);
return 0;
}
static int fm10k_ptp_settime(struct ptp_clock_info *ptp,
-const struct timespec *ts)
+const struct timespec64 *ts)
{
struct fm10k_intfc *interface;
unsigned long flags;
- u64 ns = timespec_to_ns(ts);
+ u64 ns = timespec64_to_ns(ts);
interface = container_of(ptp, struct fm10k_intfc, ptp_caps);
@@ -419,8 +419,8 @@ void fm10k_ptp_register(struct fm10k_intfc *interface)
ptp_caps->max_adj = 976562;
ptp_caps->adjfreq = fm10k_ptp_adjfreq;
ptp_caps->adjtime = fm10k_ptp_adjtime;
- ptp_caps->gettime = fm10k_ptp_gettime;
- ptp_caps->settime = fm10k_ptp_settime;
+ ptp_caps->gettime64 = fm10k_ptp_gettime;
+ ptp_caps->settime64 = fm10k_ptp_settime;
/* provide pins if BAR4 is accessible */
if (interface->sw_addr) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 12/23] ptp: i40e: convert to the 64 bit get/set time methods.
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
index fabcfa1..a92b772 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
@@ -57,7 +57,7 @@
* timespec. However, since the registers are 64 bits of nanoseconds, we must
* convert the result to a timespec before we can return.
**/
-static void i40e_ptp_read(struct i40e_pf *pf, struct timespec *ts)
+static void i40e_ptp_read(struct i40e_pf *pf, struct timespec64 *ts)
{
struct i40e_hw *hw = &pf->hw;
u32 hi, lo;
@@ -69,7 +69,7 @@ static void i40e_ptp_read(struct i40e_pf *pf, struct timespec
*ts)
ns = (((u64)hi) << 32) | lo;
- *ts = ns_to_timespec(ns);
+ *ts = ns_to_timespec64(ns);
}
/**
@@ -81,10 +81,10 @@ static void i40e_ptp_read(struct i40e_pf *pf, struct
timespec *ts)
* we receive a timespec from the stack, we must convert that timespec into
* nanoseconds before programming the registers.
**/
-static void i40e_ptp_write(struct i40e_pf *pf, const struct timespec *ts)
+static void i40e_ptp_write(struct i40e_pf *pf, const struct timespec64 *ts)
{
struct i40e_hw *hw = &pf->hw;
- u64 ns = timespec_to_ns(ts);
+ u64 ns = timespec64_to_ns(ts);
/* The timer will not update until the high register is written, so
* write the low register first.
@@ -159,14 +159,14 @@ static int i40e_ptp_adjfreq(struct ptp_clock_info *ptp,
s32 ppb)
static int i40e_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
{
struct i40e_pf *pf = container_of(ptp, struct i40e_pf, ptp_caps);
- struct timespec now, then = ns_to_timespec(delta);
+ struct timespec64 now, then = ns_to_timespec64(delta);
unsigned long flags;
spin_lock_irqsave(&pf->tmreg_lock, flags);
i40e_ptp_read(pf, &now);
- now = timespec_add(now, then);
- i40e_ptp_write(pf, (const struct timespec *)&now);
+ now = timespec64_add(now, then);
+ i40e_ptp_write(pf, (const struct timespec64 *)&now);
spin_unlock_irqrestore(&pf->tmreg_lock, flags);
@@ -181,7 +181,7 @@ static int i40e_ptp_adjtime(struct ptp_clock_info *ptp, s64
delta)
* Read the device clock and return the correct value on ns, after converting
it
* into a timespec struct.
**/
-static int i40e_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int i40e_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct i40e_pf *pf = container_of(ptp, struct i40e_pf, ptp_caps);
unsigned long flags;
@@ -202,7 +202,7 @@ static int i40e_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
* to ns happens in the write function.
**/
static int i40e_ptp_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct i40e_pf *pf = container_of(ptp, struct i40e_pf, ptp_caps);
unsigned long flags;
@@ -613,8 +613,8 @@ static long i40e_ptp_create_clock(struct i40e_pf *pf)
pf->ptp_caps.pps = 0;
pf->ptp_caps.adjfreq = i40e_ptp_adjfreq;
pf->ptp_caps.adjtime = i40e_ptp_adjtime;
- pf->ptp_caps.gettime = i40e_ptp_gettime;
- pf->ptp_caps.settime = i40e_ptp_settime;
+ pf->ptp_caps.gettime64 = i40e_ptp_gettime;
+ pf->ptp_caps.settime64 = i40e_ptp_settime;
pf->ptp_caps.enable = i40e_ptp_feature_enable;
/* Attempt to register the clock before enabling the hardware. */
@@ -673,7 +673,7 @@ void i40e_ptp_init(struct i40e_pf *pf)
dev_err(&pf->pdev->dev, "%s: ptp_clock_register failed\n",
__func__);
} else {
- struct timespec ts;
+ struct timespec64 ts;
u32 regval;
dev_info(&pf->pdev->dev, "%s: added PHC on %s\n", __func__,
@@ -695,7 +695,7 @@ void i40e_ptp_init(struct i40e_pf *pf)
i40e_ptp_set_timestamp_mode(pf, &pf->tstamp_config);
/* Set the clock value. */
- ts = ktime_to_timespec(ktime_get_real());
+ ts = ktime_to_timespec64(ktime_get_real());
i40e_ptp_settime(&pf->ptp_caps, &ts);
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
On Thu, Mar 19, 2015 at 07:37:24PM +, Will Deacon wrote: > On Thu, Mar 19, 2015 at 10:12:05AM +, Lorenzo Pieralisi wrote: > > On Thu, Mar 19, 2015 at 03:45:35AM +, Hanjun Guo wrote: > > > >> + if (trigger == ACPI_EDGE_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_LOW) > > > >> + irq_type = IRQ_TYPE_EDGE_FALLING; > > > >> + else if (trigger == ACPI_EDGE_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_HIGH) > > > >> + irq_type = IRQ_TYPE_EDGE_RISING; > > > >> + else if (trigger == ACPI_LEVEL_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_LOW) > > > >> + irq_type = IRQ_TYPE_LEVEL_LOW; > > > >> + else if (trigger == ACPI_LEVEL_SENSITIVE && > > > >> + polarity == ACPI_ACTIVE_HIGH) > > > >> + irq_type = IRQ_TYPE_LEVEL_HIGH; > > > >> + else > > > >> + irq_type = IRQ_TYPE_NONE; > > > >> + > > > >> + /* > > > >> + * Since only one GIC is supported in ACPI 5.0, we can > > > >> + * create mapping refer to the default domain > > > >> + */ > > > >> + irq = irq_create_mapping(NULL, gsi); > > > >> + if (!irq) > > > >> + return irq; > > > >> + > > > >> + /* Set irq type if specified and different than the current one > > > >> */ > > > >> + if (irq_type != IRQ_TYPE_NONE && > > > >> + irq_type != irq_get_trigger_type(irq)) > > > >> + irq_set_irq_type(irq, irq_type); > > > >> + return irq; > > > >> +} > > > >> +EXPORT_SYMBOL_GPL(acpi_register_gsi); > > > > I see you've still got this buried in the arch code. Is there any plan > > > > to > > > > move it out, as I moaned about this in the last version of the series > > > > and > > > > nothing seems to have changed? > > > > > > Ah, sorry. Last time when I was in Hongkong for LCA this Feb, I > > > discussed with Lorenzo and he had a look into that too, he also met some > > > obstacles to do that, so Lorenzo said that he will talk to you about > > > this (Lorenzo, correct me if I'm wrong due to hearing problems of much > > > noise in that room where we were talking). > > > > > > Anyway, if we move those functions to core code, such as irqdomain code, > > > which will be compiled for x86 too, we can only set those functions as > > > _weak, or we guard with them as #ifdef CONFIG_ARM64 ... #endif, so for > > > me, it's really not a big deal to move those code out of arch/arm64, but > > > I'm still open for suggestions if you can do that in a proper way. > > > > You heard me clear and sound in HK, Will has a point and I looked into > > this. Code is generic but not enough to be useful on other arches at > > the moment, I need more time to look into this and see if we can move > > this code to acpi core in a way that makes sense, to have, as you say, > > a "default" implementation. > > Yeah, just something guarded by a CONFIG option (probably not ARM64 > though) would be enough, I think. Nothing too fancy. I had a decent look and on x86/ia64 ACPI gsi mappings (PIC/IOAPIC/IOSAPIC) are buried in arch code (not saying it is nice, it is what it is at present). We can try either to move this code to ACPI layer and make it depend on CONFIG_ARM_GIC somehow, or move it to the GIC driver altogether. I have to think about this, certainly it is not generic code at present (or better it looks generic but can only work on ARM64 with GIC IRQ model). Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch.pl: Add warning for harmful goto labels
On Sat, Mar 21, 2015 at 10:16 PM, L. Alberto Giménez
wrote:
> Issue a warning for too broad goto labels that may make the code to
> follow the wrong exit path, thus causing hard to debug bugs.
>
> Signed-off-by: L. Alberto Giménez
> ---
> scripts/checkpatch.pl | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index d124359..e8ce220 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -444,6 +444,11 @@ our $allowed_asm_includes = qr{(?x:
> )};
> # memory.h: ARM has a custom one
>
> +our @goto_harmful_labels = qw(
> + out
> + fail
> + );
> +
> # Load common spelling mistakes and build regular expression list.
> my $misspellings;
> my %spelling_fix;
> @@ -2702,6 +2707,14 @@ sub process {
> }
> }
>
> + if ($sline =~ /goto (.*);/) {
> + my $label = $1;
> + if (grep { /^$label$/ } @goto_harmful_labels) {
> + WARN("HARMFUL_GOTO_LABEL",
> + "Goto label '$label' is considered
> harmful\n" . $herecurr);
Huh? Since when?
rw@azrael:~/linux (for-v4.1/uml_misc $)> git grep -e "goto out;" | wc -l
26667
rw@azrael:~/linux (for-v4.1/uml_misc $)> git grep -e "goto fail;" | wc -l
3733
What is next? Variable name "i" considered harmful?
Can we please stop this nonsense.
--
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/
Re: [PATCH] checkpatch.pl: Add warning for harmful goto labels
Hi Alberto, On 03/21/2015 05:16 PM, L. Alberto Giménez wrote: > Issue a warning for too broad goto labels that may make the code to > follow the wrong exit path, thus causing hard to debug bugs. What compiler allowed duplicate goto labels? Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 04/23] ptp: blackfin: convert to the 64 bit get/set time methods.
The device uses 64 bit nanoseconds register, and so with this patch the
driver is ready for the year 2038.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/adi/bfin_mac.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/adi/bfin_mac.c
b/drivers/net/ethernet/adi/bfin_mac.c
index ec20611..0c37aef 100644
--- a/drivers/net/ethernet/adi/bfin_mac.c
+++ b/drivers/net/ethernet/adi/bfin_mac.c
@@ -983,7 +983,7 @@ static int bfin_ptp_adjtime(struct ptp_clock_info *ptp, s64
delta)
return 0;
}
-static int bfin_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int bfin_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -1003,7 +1003,7 @@ static int bfin_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int bfin_ptp_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
unsigned long flags;
@@ -1039,8 +1039,8 @@ static struct ptp_clock_info bfin_ptp_caps = {
.pps= 0,
.adjfreq= bfin_ptp_adjfreq,
.adjtime= bfin_ptp_adjtime,
- .gettime= bfin_ptp_gettime,
- .settime= bfin_ptp_settime,
+ .gettime64 = bfin_ptp_gettime,
+ .settime64 = bfin_ptp_settime,
.enable = bfin_ptp_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 01/23] ptp: introduce get/set time methods with explicit 64 bit seconds.
Converting the PHC drivers over to the new methods is one step along the
way to making them ready for 2038. Once all the drivers are up to date,
then the old methods will be removed.
Signed-off-by: Richard Cochran
---
include/linux/ptp_clock_kernel.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index 0d8ff3f..7d6f8e6 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -64,12 +64,18 @@ struct ptp_clock_request {
* @adjtime: Shifts the time of the hardware clock.
*parameter delta: Desired change in nanoseconds.
*
- * @gettime: Reads the current time from the hardware clock.
+ * @gettime: Reads the current time from the hardware clock. (deprecated)
*parameter ts: Holds the result.
*
- * @settime: Set the current time on the hardware clock.
+ * @settime: Set the current time on the hardware clock. (deprecated)
*parameter ts: Time value to set.
*
+ * @gettime64: Reads the current time from the hardware clock.
+ * parameter ts: Holds the result.
+ *
+ * @settime64: Set the current time on the hardware clock.
+ * parameter ts: Time value to set.
+ *
* @enable: Request driver to enable or disable an ancillary feature.
*parameter request: Desired resource to enable or disable.
*parameter on: Caller passes one to enable or zero to disable.
@@ -106,6 +112,8 @@ struct ptp_clock_info {
int (*adjtime)(struct ptp_clock_info *ptp, s64 delta);
int (*gettime)(struct ptp_clock_info *ptp, struct timespec *ts);
int (*settime)(struct ptp_clock_info *ptp, const struct timespec *ts);
+ int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
+ int (*settime64)(struct ptp_clock_info *p, const struct timespec64 *ts);
int (*enable)(struct ptp_clock_info *ptp,
struct ptp_clock_request *request, int on);
int (*verify)(struct ptp_clock_info *ptp, unsigned int pin,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next V2 07/23] ptp: tg3: convert to the 64 bit get/set time methods.
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/broadcom/tg3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index 22b33da..d02d19b 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -6217,7 +6217,7 @@ static int tg3_ptp_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return 0;
}
-static int tg3_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int tg3_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -6235,12 +6235,12 @@ static int tg3_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int tg3_ptp_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
struct tg3 *tp = container_of(ptp, struct tg3, ptp_info);
- ns = timespec_to_ns(ts);
+ ns = timespec64_to_ns(ts);
tg3_full_lock(tp, 0);
tg3_refclk_write(tp, ns);
@@ -6320,8 +6320,8 @@ static const struct ptp_clock_info tg3_ptp_caps = {
.pps= 0,
.adjfreq= tg3_ptp_adjfreq,
.adjtime= tg3_ptp_adjtime,
- .gettime= tg3_ptp_gettime,
- .settime= tg3_ptp_settime,
+ .gettime64 = tg3_ptp_gettime,
+ .settime64 = tg3_ptp_settime,
.enable = tg3_ptp_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 0/2] N900 Modem Speech Support
Hi, On Sat, Mar 21, 2015 at 08:09:15PM +0100, Sebastian Reichel wrote: > [1] git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git > branch/cmt-speech-2 This should actually be: git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git branch/cmt-speech-3 -- Sebastian signature.asc Description: Digital signature
Re: [RESEND PATCH 1/3] clk: si5351: Constify clock names and struct regmap_config
On Fri, Mar 20, 2015 at 2:34 PM, Krzysztof Kozlowski wrote: > The regmap_config struct may be const because it is not modified by the > driver and regmap_init() accepts pointer to const. > > Replace doubled const in the arrays of clock names with proper const > pointer to const data. This fixes the warnings: > > drivers/clk/clk-si5351.c:71:25: warning: duplicate const > drivers/clk/clk-si5351.c:74:25: warning: duplicate const > drivers/clk/clk-si5351.c:77:25: warning: duplicate const > drivers/clk/clk-si5351.c:80:25: warning: duplicate const > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/clk/clk-si5351.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Max Filippov -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 2/3] clk: si570: Constify struct regmap_config
On Fri, Mar 20, 2015 at 2:34 PM, Krzysztof Kozlowski wrote: > The regmap_config struct may be const because it is not modified by the > driver and regmap_init() accepts pointer to const. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/clk/clk-si570.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Max Filippov -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 3/3] clk: cdce706: Constify struct regmap_config
On Fri, Mar 20, 2015 at 2:34 PM, Krzysztof Kozlowski wrote: > The regmap_config struct may be const because it is not modified by the > driver and regmap_init() accepts pointer to const. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/clk/clk-cdce706.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Max Filippov -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch.pl: Add warning for harmful goto labels
Issue a warning for too broad goto labels that may make the code to
follow the wrong exit path, thus causing hard to debug bugs.
Signed-off-by: L. Alberto Giménez
---
scripts/checkpatch.pl | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d124359..e8ce220 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -444,6 +444,11 @@ our $allowed_asm_includes = qr{(?x:
)};
# memory.h: ARM has a custom one
+our @goto_harmful_labels = qw(
+ out
+ fail
+ );
+
# Load common spelling mistakes and build regular expression list.
my $misspellings;
my %spelling_fix;
@@ -2702,6 +2707,14 @@ sub process {
}
}
+ if ($sline =~ /goto (.*);/) {
+ my $label = $1;
+ if (grep { /^$label$/ } @goto_harmful_labels) {
+ WARN("HARMFUL_GOTO_LABEL",
+ "Goto label '$label' is considered
harmful\n" . $herecurr);
+ }
+ }
+
# discourage the addition of CONFIG_EXPERIMENTAL in #if(def).
if ($line =~ /^\+\s*\#\s*if.*\bCONFIG_EXPERIMENTAL\b/) {
WARN("CONFIG_EXPERIMENTAL",
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC net-next 22/22] ptp: remove 32 bit get/set methods.
On Sat, Mar 21, 2015 at 09:59:52PM +0100, Richard Cochran wrote:
> diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
> index 296b0ec..2665360 100644
> --- a/drivers/ptp/ptp_clock.c
> +++ b/drivers/ptp/ptp_clock.c
> @@ -107,13 +107,21 @@ static int ptp_clock_getres(struct posix_clock *pc,
> struct timespec *tp)
> static int ptp_clock_settime(struct posix_clock *pc, const struct timespec
> *tp)
> {
> struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
> - return ptp->info->settime(ptp->info, tp);
> + struct timespec64 ts = timespec_to_timespec64(*tp);
> +
> + return ptp->info->settime64(ptp->info, &ts);
> }
>
> static int ptp_clock_gettime(struct posix_clock *pc, struct timespec *tp)
> {
> struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
> - return ptp->info->gettime(ptp->info, tp);
> + struct timespec64 ts;
> + int err;
> +
> + err = ptp->info->gettime64(ptp->info, &ts);
> + if (!err)
> + *tp = timespec64_to_timespec(ts);
> + return err;
> }
Oops, both of these functions should have started using the new
methods *before* migrating the drivers. Will fix in V2.
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/
[RFC net-next 04/22] ptp: xgbe: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
b/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
index f326178..b03e4f5 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
@@ -179,7 +179,7 @@ static int xgbe_adjtime(struct ptp_clock_info *info, s64
delta)
return 0;
}
-static int xgbe_gettime(struct ptp_clock_info *info, struct timespec *ts)
+static int xgbe_gettime(struct ptp_clock_info *info, struct timespec64 *ts)
{
struct xgbe_prv_data *pdata = container_of(info,
struct xgbe_prv_data,
@@ -193,12 +193,13 @@ static int xgbe_gettime(struct ptp_clock_info *info,
struct timespec *ts)
spin_unlock_irqrestore(&pdata->tstamp_lock, flags);
- *ts = ns_to_timespec(nsec);
+ *ts = ns_to_timespec64(nsec);
return 0;
}
-static int xgbe_settime(struct ptp_clock_info *info, const struct timespec *ts)
+static int xgbe_settime(struct ptp_clock_info *info,
+ const struct timespec64 *ts)
{
struct xgbe_prv_data *pdata = container_of(info,
struct xgbe_prv_data,
@@ -206,7 +207,7 @@ static int xgbe_settime(struct ptp_clock_info *info, const
struct timespec *ts)
unsigned long flags;
u64 nsec;
- nsec = timespec_to_ns(ts);
+ nsec = timespec64_to_ns(ts);
spin_lock_irqsave(&pdata->tstamp_lock, flags);
@@ -236,8 +237,8 @@ void xgbe_ptp_register(struct xgbe_prv_data *pdata)
info->max_adj = pdata->ptpclk_rate;
info->adjfreq = xgbe_adjfreq;
info->adjtime = xgbe_adjtime;
- info->gettime = xgbe_gettime;
- info->settime = xgbe_settime;
+ info->gettime64 = xgbe_gettime;
+ info->settime64 = xgbe_settime;
info->enable = xgbe_enable;
clock = ptp_clock_register(info, pdata->dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC net-next 06/22] ptp: tg3: convert to the 64 bit get/set time methods.
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/broadcom/tg3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index 22b33da..d02d19b 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -6217,7 +6217,7 @@ static int tg3_ptp_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return 0;
}
-static int tg3_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int tg3_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -6235,12 +6235,12 @@ static int tg3_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int tg3_ptp_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
struct tg3 *tp = container_of(ptp, struct tg3, ptp_info);
- ns = timespec_to_ns(ts);
+ ns = timespec64_to_ns(ts);
tg3_full_lock(tp, 0);
tg3_refclk_write(tp, ns);
@@ -6320,8 +6320,8 @@ static const struct ptp_clock_info tg3_ptp_caps = {
.pps= 0,
.adjfreq= tg3_ptp_adjfreq,
.adjtime= tg3_ptp_adjtime,
- .gettime= tg3_ptp_gettime,
- .settime= tg3_ptp_settime,
+ .gettime64 = tg3_ptp_gettime,
+ .settime64 = tg3_ptp_settime,
.enable = tg3_ptp_enable,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC net-next 05/22] ptp: bnx2x: convert to the 64 bit get/set time methods.
This driver's clock is implemented using a timecounter, and so with
this patch the driver is ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 9677431..765667c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13278,7 +13278,7 @@ static int bnx2x_ptp_adjtime(struct ptp_clock_info
*ptp, s64 delta)
return 0;
}
-static int bnx2x_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int bnx2x_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
@@ -13295,7 +13295,7 @@ static int bnx2x_ptp_gettime(struct ptp_clock_info
*ptp, struct timespec *ts)
}
static int bnx2x_ptp_settime(struct ptp_clock_info *ptp,
-const struct timespec *ts)
+const struct timespec64 *ts)
{
struct bnx2x *bp = container_of(ptp, struct bnx2x, ptp_clock_info);
u64 ns;
@@ -1,8 +1,8 @@ static void bnx2x_register_phc(struct bnx2x *bp)
bp->ptp_clock_info.pps = 0;
bp->ptp_clock_info.adjfreq = bnx2x_ptp_adjfreq;
bp->ptp_clock_info.adjtime = bnx2x_ptp_adjtime;
- bp->ptp_clock_info.gettime = bnx2x_ptp_gettime;
- bp->ptp_clock_info.settime = bnx2x_ptp_settime;
+ bp->ptp_clock_info.gettime64 = bnx2x_ptp_gettime;
+ bp->ptp_clock_info.settime64 = bnx2x_ptp_settime;
bp->ptp_clock_info.enable = bnx2x_ptp_enable;
bp->ptp_clock = ptp_clock_register(&bp->ptp_clock_info, &bp->pdev->dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC net-next 01/22] ptp: introduce get/set time methods with explicit 64 bit seconds.
Converting the PHC drivers over to the new methods is one step along the
way to making them ready for 2038. Once all the drivers are up to date,
then the old methods will be removed.
Signed-off-by: Richard Cochran
---
include/linux/ptp_clock_kernel.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index 0d8ff3f..7d6f8e6 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -64,12 +64,18 @@ struct ptp_clock_request {
* @adjtime: Shifts the time of the hardware clock.
*parameter delta: Desired change in nanoseconds.
*
- * @gettime: Reads the current time from the hardware clock.
+ * @gettime: Reads the current time from the hardware clock. (deprecated)
*parameter ts: Holds the result.
*
- * @settime: Set the current time on the hardware clock.
+ * @settime: Set the current time on the hardware clock. (deprecated)
*parameter ts: Time value to set.
*
+ * @gettime64: Reads the current time from the hardware clock.
+ * parameter ts: Holds the result.
+ *
+ * @settime64: Set the current time on the hardware clock.
+ * parameter ts: Time value to set.
+ *
* @enable: Request driver to enable or disable an ancillary feature.
*parameter request: Desired resource to enable or disable.
*parameter on: Caller passes one to enable or zero to disable.
@@ -106,6 +112,8 @@ struct ptp_clock_info {
int (*adjtime)(struct ptp_clock_info *ptp, s64 delta);
int (*gettime)(struct ptp_clock_info *ptp, struct timespec *ts);
int (*settime)(struct ptp_clock_info *ptp, const struct timespec *ts);
+ int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
+ int (*settime64)(struct ptp_clock_info *p, const struct timespec64 *ts);
int (*enable)(struct ptp_clock_info *ptp,
struct ptp_clock_request *request, int on);
int (*verify)(struct ptp_clock_info *ptp, unsigned int pin,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC net-next 08/22] ptp: gianfar: convert to the 64 bit get/set time methods.
The device features a 64 bit nanoseconds register, and so with this
patch the driver is ready for the year 2038.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c
b/drivers/net/ethernet/freescale/gianfar_ptp.c
index 77353366..04265a7 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -322,7 +322,8 @@ static int ptp_gianfar_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return 0;
}
-static int ptp_gianfar_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int ptp_gianfar_gettime(struct ptp_clock_info *ptp,
+ struct timespec64 *ts)
{
u64 ns;
u32 remainder;
@@ -341,7 +342,7 @@ static int ptp_gianfar_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
}
static int ptp_gianfar_settime(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
u64 ns;
unsigned long flags;
@@ -418,8 +419,8 @@ static struct ptp_clock_info ptp_gianfar_caps = {
.pps= 1,
.adjfreq= ptp_gianfar_adjfreq,
.adjtime= ptp_gianfar_adjtime,
- .gettime= ptp_gianfar_gettime,
- .settime= ptp_gianfar_settime,
+ .gettime64 = ptp_gianfar_gettime,
+ .settime64 = ptp_gianfar_settime,
.enable = ptp_gianfar_enable,
};
@@ -440,7 +441,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
{
struct device_node *node = dev->dev.of_node;
struct etsects *etsects;
- struct timespec now;
+ struct timespec64 now;
int err = -ENOMEM;
u32 tmr_ctrl;
unsigned long flags;
@@ -495,7 +496,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
pr_err("ioremap ptp registers failed\n");
goto no_ioremap;
}
- getnstimeofday(&now);
+ getnstimeofday64(&now);
ptp_gianfar_settime(&etsects->caps, &now);
tmr_ctrl =
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC net-next 10/22] ptp: fm10k: convert to the 64 bit get/set time methods.
The device appears to use a 64 bit nanoseconds register, and so with
this patch the driver should be ready for the year 2038.
Compile tested only.
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/intel/fm10k/fm10k_ptp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
index d966044..02008e9 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
@@ -285,7 +285,7 @@ static int fm10k_ptp_adjtime(struct ptp_clock_info *ptp,
s64 delta)
return 0;
}
-static int fm10k_ptp_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+static int fm10k_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct fm10k_intfc *interface;
unsigned long flags;
@@ -297,17 +297,17 @@ static int fm10k_ptp_gettime(struct ptp_clock_info *ptp,
struct timespec *ts)
now = fm10k_systime_read(interface) + interface->ptp_adjust;
read_unlock_irqrestore(&interface->systime_lock, flags);
- *ts = ns_to_timespec(now);
+ *ts = ns_to_timespec64(now);
return 0;
}
static int fm10k_ptp_settime(struct ptp_clock_info *ptp,
-const struct timespec *ts)
+const struct timespec64 *ts)
{
struct fm10k_intfc *interface;
unsigned long flags;
- u64 ns = timespec_to_ns(ts);
+ u64 ns = timespec64_to_ns(ts);
interface = container_of(ptp, struct fm10k_intfc, ptp_caps);
@@ -419,8 +419,8 @@ void fm10k_ptp_register(struct fm10k_intfc *interface)
ptp_caps->max_adj = 976562;
ptp_caps->adjfreq = fm10k_ptp_adjfreq;
ptp_caps->adjtime = fm10k_ptp_adjtime;
- ptp_caps->gettime = fm10k_ptp_gettime;
- ptp_caps->settime = fm10k_ptp_settime;
+ ptp_caps->gettime64 = fm10k_ptp_gettime;
+ ptp_caps->settime64 = fm10k_ptp_settime;
/* provide pins if BAR4 is accessible */
if (interface->sw_addr) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
