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
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
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
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
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
>>
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 -
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
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
>
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
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
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
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
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
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);
>
On Saturday 21 March 2015, Richard Cochran wrote:
> mutex_lock(>extreg_lock);
>
> - err = tdr_write(1, phydev, ts, PTP_LOAD_CLK);
> + err = tdr_write(1, phydev, , PTP_LOAD_CLK);
>
> mutex_unlock(>extreg_lock);
I don't see the change to the tdr_write() function that
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
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
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
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
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
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
> -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;
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
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:
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 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:
> >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
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
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
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
---
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 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
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:
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
---
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
>
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
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
> ---
>
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];
> > > +
>
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
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
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
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:
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:
>
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,
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
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
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.
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
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
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
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
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
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
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
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
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
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
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(-)
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
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
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
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
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
---
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.
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
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(+),
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 564 matches
Mail list logo
