On Fri, 2017-01-27 at 12:32 -0800, Tyrel Datwyler wrote:
> Its possible being the end of the week I'm just a little dense, but
> wouldn't be64_to_cpu() imply that we are byte-swapping something that is
> already, or supposedly already, in BE format to cpu endianness? Which on
> a BE cpu I would exp
Hello,
On 2017-01-27 21:32, Tyrel Datwyler wrote:
On 01/27/2017 11:58 AM, Benjamin Herrenschmidt wrote:
On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote:
The problem is that we are packing an in-memory structure into 2
registers and it's expected that this structure is laid out in the
r
Highlights include 8xx breakpoints and perf, t1042rdb display support,
and board updates.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel
On 01/27/2017 01:03 AM, Michal Suchanek wrote:
> On 27 January 2017 at 02:50, Benjamin Herrenschmidt
> wrote:
>> On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote:
>>> On 01/26/2017 12:22 PM, Michal Suchánek wrote:
Hello,
building ibmvtpm I noticed gcc warning complaining that
On 01/27/2017 11:58 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote:
>>> The problem is that we are packing an in-memory structure into 2
>>> registers and it's expected that this structure is laid out in the
>>> registers as if it had been loaded by a BE
On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote:
> > The problem is that we are packing an in-memory structure into 2
> > registers and it's expected that this structure is laid out in the
> > registers as if it had been loaded by a BE CPU.
>
> This is only the case if the cpu is BE. If th
On 01/26/2017 05:50 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote:
>> On 01/26/2017 12:22 PM, Michal Suchánek wrote:
>>> Hello,
>>>
>>> building ibmvtpm I noticed gcc warning complaining that second word
>>> of
>>> struct ibmvtpm_crq in tpm_ibmvtpm_susp
On Fri, Jan 27, 2017 at 09:47:08AM +0100, Miroslav Benes wrote:
>
> > diff --git a/include/linux/stacktrace.h b/include/linux/stacktrace.h
> > index 0a34489..8e8b67b 100644
> > --- a/include/linux/stacktrace.h
> > +++ b/include/linux/stacktrace.h
> > @@ -18,6 +18,8 @@ extern void save_stack_trace_
On 24 January 2017 at 16:16, Ard Biesheuvel wrote:
> This v4 is a followup to [0] 'modversions: redefine kcrctab entries as
> relative CRC pointers', but since relative CRC pointers do not work in
> modules, and are actually only needed by powerpc with CONFIG_RELOCATABLE=y,
> I have made it a Kcon
The QE_General4 workaround is only valid for the MPC832x and MPC836x
SoCs. The other SoCs that embed a QUICC engine are not affected by this
hardware bug and thus can use the computed divisors (this was
successfully tested on the T1040).
Similalry to what was done in commit 8ce795cb0c6b ("i2c: mpc
This allows to build the fsl_ucc_hdlc driver as a module.
Signed-off-by: Valentin Longchamp
---
drivers/soc/fsl/qe/qe_tdm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/fsl/qe/qe_tdm.c b/drivers/soc/fsl/qe/qe_tdm.c
index a1048b4..f744c21 100644
--- a/drivers/soc/fsl/qe/qe_td
Because of integer computation rounding in u-boot (that sets the QE
brg-frequency DTS prop), the clk value is Hz even though it is
100 MHz.
When setting brg clks that are exact divisors of 100 MHz, this small
differnce plays a role and can result in lower clks to be output (for
instance 2
Testing the QE's UCC for our HDLC bus I noticed a few odd things and I have
fixed these in these 3 patches.
Valentin Longchamp (3):
soc/fsl/qe: round brg_freq to 1kHz granularity
soc/fsl/qe: only apply QE_General4 workaround on affected SoCs
soc/fsl/qe: add EXPORT_SYMBOL for the 2 qe_tdm fun
Hello Michael
On 27/01/2017, Michael Ellerman wrote:
> On Mon, 2017-01-23 at 19:42:54 UTC, Darren Stevens wrote:
> Applied to powerpc fixes, thanks.
>
> https://git.kernel.org/powerpc/c/af2b7fa17eb92e52b65f96604448ff
Thanks, I was going to ask about backporting to 4.9 as it's a LTS now, but I
see
While rebooting PowerVM LPAR running 4.10.0-rc5-next-20170124
on a POWER8 box, following kernel oops is displayed.
This problem was introduced with next-20170123. next-20170120 works.
Initial analysis points to following patch included with next-20170123
commit a1a22c12060e4b9c52f45d4b3460f614e00
On Wed, Jan 25, 2017 at 03:58:22PM +1100, Gavin Shan wrote:
> On Wed, Jan 25, 2017 at 09:27:44AM +0530, Balbir Singh wrote:
> >On Tue, Jan 24, 2017 at 10:32:28AM +1100, Gavin Shan wrote:
> >> When @node_reclaim_mode ("/proc/sys/vm/zone_reclaim_mode") is enabled,
> >> the nodes in the specified dist
From: Michal Suchánek
> building ibmvtpm I noticed gcc warning complaining that second word of
> struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized.
>
> The structure is defined as
>
> struct ibmvtpm_crq {
> u8 valid;
> u8 msg;
> __be16 len;
> __be32 data;
From: Larry Finger
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.
I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:
AS
On Wed, Jan 25, 2017 at 01:27:22PM +0100, Thomas Huth wrote:
> The function kvmppc_handle_exit_pr() is quite huge and thus hard to read,
> and even contains a "spaghetti-code"-like goto between the different case
> labels of the big switch statement. This can be made much more readable
> by moving
On 27 January 2017 at 02:50, Benjamin Herrenschmidt
wrote:
> On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote:
>> On 01/26/2017 12:22 PM, Michal Suchánek wrote:
>> > Hello,
>> >
>> > building ibmvtpm I noticed gcc warning complaining that second word
>> > of
>> > struct ibmvtpm_crq in tpm_i
On Thu, 19 Jan 2017, Josh Poimboeuf wrote:
> Create temporary stubs for klp_update_patch_state() so we can add
> TIF_PATCH_PENDING to different architectures in separate patches without
> breaking build bisectability.
>
> Signed-off-by: Josh Poimboeuf
> Reviewed-by: Petr Mladek
Acked-by: Miros
> diff --git a/include/linux/stacktrace.h b/include/linux/stacktrace.h
> index 0a34489..8e8b67b 100644
> --- a/include/linux/stacktrace.h
> +++ b/include/linux/stacktrace.h
> @@ -18,6 +18,8 @@ extern void save_stack_trace_regs(struct pt_regs *regs,
> struct stack_tr
22 matches
Mail list logo
