Re: [RFC PATCH] z3fold: prevent reclaim/free race for headless pages

[Tom Hebb]

On Tue, Feb 16, 2021 at 1:21 AM Greg Kroah-Hartman
 wrote:
>
> On Tue, Feb 16, 2021 at 12:44:40AM -0800, Thomas Hebb wrote:
> > commit ca0246bb97c2 ("z3fold: fix possible reclaim races") introduced
> > the PAGE_CLAIMED flag "to avoid racing on a z3fold 'headless' page
> > release." By atomically testing and setting the bit in each of
> > z3fold_free() and z3fold_reclaim_page(), a double-free was avoided.
> >
> > However, commit 746d179b0e66 ("z3fold: stricter locking and more careful
> > reclaim") appears to have unintentionally broken this behavior by moving
> > the PAGE_CLAIMED check in z3fold_reclaim_page() to after the page lock
> > gets taken, which only happens for non-headless pages. For headless
> > pages, the check is now skipped entirely and races can occur again.
> >
> > I have observed such a race on my system:
> >
> > page:ffbd76b7 refcount:0 mapcount:0 mapping: 
> > index:0x0 pfn:0x165316
> > flags: 0x200()
> > raw: 0200 ea0004535f48 8881d553a170 
> > raw:  0011  
> > page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
> > [ cut here ]
> > kernel BUG at include/linux/mm.h:707!
> > invalid opcode:  [#1] PREEMPT SMP KASAN PTI
> > CPU: 2 PID: 291928 Comm: kworker/2:0 Tainted: GB 
> > 5.10.7-arch1-1-kasan #1
> > Hardware name: Gigabyte Technology Co., Ltd. H97N-WIFI/H97N-WIFI, BIOS 
> > F9b 03/03/2016
> > Workqueue: zswap-shrink shrink_worker
> > RIP: 0010:__free_pages+0x10a/0x130
> > Code: c1 e7 06 48 01 ef 45 85 e4 74 d1 44 89 e6 31 d2 41 83 ec 01 e8 e7 
> > b0 ff ff eb da 48 c7 c6 e0 32 91 88 48 89 ef e8 a6 89 f8 ff <0f> 0b 4c 89 
> > e7 e8 fc 79 07 00 e9 33 ff ff ff 48 89 ef e8 ff 79 07
> > RSP: :88819a2ffb98 EFLAGS: 00010296
> > RAX:  RBX: ea000594c5a8 RCX: 
> > RDX: 1d4000b298b7 RSI:  RDI: ea000594c5b8
> > RBP: ea000594c580 R08: 003e R09: 8881d5520bbb
> > R10: ed103aaa4177 R11: 0001 R12: ea000594c5b4
> > R13:  R14: 888165316000 R15: ea000594c588
> > FS:  () GS:8881d550() 
> > knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2: 7f7c8c3654d8 CR3: 000103f42004 CR4: 001706e0
> > Call Trace:
> >  z3fold_zpool_shrink+0x9b6/0x1240
> >  ? sugov_update_single+0x357/0x990
> >  ? sched_clock+0x5/0x10
> >  ? sched_clock_cpu+0x18/0x180
> >  ? z3fold_zpool_map+0x490/0x490
> >  ? _raw_spin_lock_irq+0x88/0xe0
> >  shrink_worker+0x35/0x90
> >  process_one_work+0x70c/0x1210
> >  ? pwq_dec_nr_in_flight+0x15b/0x2a0
> >  worker_thread+0x539/0x1200
> >  ? __kthread_parkme+0x73/0x120
> >  ? rescuer_thread+0x1000/0x1000
> >  kthread+0x330/0x400
> >  ? __kthread_bind_mask+0x90/0x90
> >  ret_from_fork+0x22/0x30
> > Modules linked in: rfcomm ebtable_filter ebtables ip6table_filter 
> > ip6_tables iptable_filter ccm algif_aead des_generic libdes ecb 
> > algif_skcipher cmac bnep md4 algif_hash af_alg vfat fat intel_rapl_msr 
> > intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel 
> > iwlmvm hid_logitech_hidpp kvm at24 mac80211 snd_hda_codec_realtek iTCO_wdt 
> > snd_hda_codec_generic intel_pmc_bxt snd_hda_codec_hdmi ledtrig_audio 
> > iTCO_vendor_support mei_wdt mei_hdcp snd_hda_intel snd_intel_dspcfg libarc4 
> > soundwire_intel irqbypass iwlwifi soundwire_generic_allocation rapl 
> > soundwire_cadence intel_cstate snd_hda_codec intel_uncore btusb joydev 
> > mousedev snd_usb_audio pcspkr btrtl uvcvideo nouveau btbcm i2c_i801 btintel 
> > snd_hda_core videobuf2_vmalloc i2c_smbus snd_usbmidi_lib videobuf2_memops 
> > bluetooth snd_hwdep soundwire_bus snd_soc_rt5640 videobuf2_v4l2 cfg80211 
> > snd_soc_rl6231 videobuf2_common snd_rawmidi lpc_ich alx videodev mdio 
> > snd_seq_device snd_soc_core mc ecdh_generic mxm_wmi mei_me
> >  hid_logitech_dj wmi snd_compress e1000e ac97_bus mei ttm rfkill 
> > snd_pcm_dmaengine ecc snd_pcm snd_timer snd soundcore mac_hid acpi_pad 
> > pkcs8_key_parser it87 hwmon_vid crypto_user fuse ip_tables x_tables ext4 
> > crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys trusted tpm 
> > rng_core usbhid dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel 
> > ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper xhci_pci 
> > xhci_pci_renesas i915 video intel_gtt i2c_algo_bit drm_kms_helper 
> > syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm agpgart
> > ---[ end trace 126d646fc3dc0ad8 ]---
> >
> > To fix the issue, re-add the earlier test and set in the case where we
> > have a headless page.
> >
> > Fixes: 746d179b0e66 ("z3fold: stricter locking and more careful reclaim")
>
> This 

Re: [PATCH] hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist

[Tom Hebb]

On Wed, Jan 27, 2021 at 2:58 PM Pali Rohár  wrote:
>
> Hello Bob!
>
> On Thursday 28 January 2021 08:40:36 Bob Hepple wrote:
> > Hi Pali,
> >
> > No, I have not contacted Dell about this and I'm not sure that they
> > would be terribly interested given that my machine is 12 years old -
> > but I'll have a go if I can find the right place to do it.
>
> If it is 12 years old machine then I doubt that anybody would do any
> support for it...
>
> > Do you have a good email or other Dell target to report it?
>
> In this post is information how to contact Dell Linux support team which
> can open (internal) BIOS issue:
>
> https://github.com/dell/libsmbios/issues/48#issuecomment-391328501
>
> But it is possible that still only available for USA.
>
> Mario (superm1 on github) is active also in kernel and can help with
> firmware issues on new machines.
>
> But for this your 12 years old machine is proposed blacklist quirk the
> only option.
>
> I just do not know if this issue was already fixed in new BIOS which is
> available on new machines. And therefore I'm worried if these issues
> would continue to appear also on other machines, or we are just
> collecting list of old machines.

My XPS 13 9350 from 2015 does not exhibit this issue, FWIW. I think we
would be seeing a lot more reports like this if new BIOSes were also
affected.


> Just I do not want to see situation when manufacture says "it is
> working, nothing needed to fix" and it would work just because of
> blacklist... As such scenario would lead only to increasing blacklist
> without ability to start fixing issues.
>
> > I don't
> > have access to official Dell support as my warranty ran out about 10
> > years ago. Perhaps there's an existing Dell bug report that references
> > the original https://bugzilla.kernel.org/show_bug.cgi?id=195751 ??? I
> > could add my report there if someone has already informed Dell about
> > the other instances of the bug.
> >
> > Thanks
> >
> >
> >
> > Bob
> >
> > On Wed, 27 Jan 2021 at 19:19, Pali Rohár  wrote:
> > >
> > > On Tuesday 26 January 2021 00:15:13 Tom Hebb wrote:
> > > > Bob reports that blacklisting the fan type label is not sufficient.
> > > > See his message to me below.
> > >
> > > Ok! Thank you for confirmation.
> > >
> > > And my second question which I have asked:
> > > And have you reported this issue to Dell support?
> > >
> > > > On Mon, Jan 25, 2021 at 3:38 PM Bob Hepple  wrote:
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > Big nope this end with L502x in i8k_blacklist_fan_type_dmi_table:
> > > > >
> > > > > Jan 26 09:35:47 achar kernel: psmouse serio1: TouchPad at
> > > > > isa0060/serio1/input0 lost synchronization, throwing 1 bytes>
> > > > >
> > > > > ... and lots of trackpad stall/stutters.
> > > > >
> > > > > Cheers
> > > > >
> > > > >
> > > > > Bob
> > > > >
> > > > >
> > > > >
> > > > > On Tue, 26 Jan 2021 at 08:09, Bob Hepple  wrote:
> > > > > >
> > > > > > ... compiling now ... results in a coupla hours
> > > > > >
> > > > > > Cheers
> > > > > >
> > > > > >
> > > > > > Bob
> > > > > >
> > > > > > On Tue, 26 Jan 2021 at 04:05, Tom Hebb  wrote:
> > > > > > >
> > > > > > > On Mon, Jan 25, 2021 at 2:05 AM Pali Rohár  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Saturday 23 January 2021 18:46:08 Thomas Hebb wrote:
> > > > > > > > > It has been reported[0] that the Dell XPS 15 L502X exhibits 
> > > > > > > > > similar
> > > > > > > > > freezing behavior to the other systems[1] on this blacklist. 
> > > > > > > > > The issue
> > > > > > > > > was exposed by a prior change of mine to automatically load
> > > > > > > > > dell_smm_hwmon on a wider set of XPS models. To fix the 
> > > > > > > > > regression, add
> > > > > > > > > this model to the blacklist.
> > > > > > > > >
> > > > > > >

Re: [PATCH] hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist

[Tom Hebb]

Bob reports that blacklisting the fan type label is not sufficient.
See his message to me below.

On Mon, Jan 25, 2021 at 3:38 PM Bob Hepple  wrote:
>
> Hi Tom,
>
> Big nope this end with L502x in i8k_blacklist_fan_type_dmi_table:
>
> Jan 26 09:35:47 achar kernel: psmouse serio1: TouchPad at
> isa0060/serio1/input0 lost synchronization, throwing 1 bytes>
>
> ... and lots of trackpad stall/stutters.
>
> Cheers
>
>
> Bob
>
>
>
> On Tue, 26 Jan 2021 at 08:09, Bob Hepple  wrote:
> >
> > ... compiling now ... results in a coupla hours
> >
> > Cheers
> >
> >
> > Bob
> >
> > On Tue, 26 Jan 2021 at 04:05, Tom Hebb  wrote:
> > >
> > > On Mon, Jan 25, 2021 at 2:05 AM Pali Rohár  wrote:
> > > >
> > > > On Saturday 23 January 2021 18:46:08 Thomas Hebb wrote:
> > > > > It has been reported[0] that the Dell XPS 15 L502X exhibits similar
> > > > > freezing behavior to the other systems[1] on this blacklist. The issue
> > > > > was exposed by a prior change of mine to automatically load
> > > > > dell_smm_hwmon on a wider set of XPS models. To fix the regression, 
> > > > > add
> > > > > this model to the blacklist.
> > > > >
> > > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=211081
> > > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=195751
> > > > >
> > > > > Fixes: b8a13e5e8f37 ("hwmon: (dell-smm) Use one DMI match for all XPS 
> > > > > models")
> > > > > Cc: sta...@vger.kernel.org
> > > > > Reported-by: Bob Hepple 
> > > > > Tested-by: Bob Hepple 
> > > > > Signed-off-by: Thomas Hebb 
> > > > > ---
> > > > >
> > > > >  drivers/hwmon/dell-smm-hwmon.c | 7 +++
> > > > >  1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/drivers/hwmon/dell-smm-hwmon.c 
> > > > > b/drivers/hwmon/dell-smm-hwmon.c
> > > > > index ec448f5f2dc3..73b9db9e3aab 100644
> > > > > --- a/drivers/hwmon/dell-smm-hwmon.c
> > > > > +++ b/drivers/hwmon/dell-smm-hwmon.c
> > > > > @@ -1159,6 +1159,13 @@ static struct dmi_system_id 
> > > > > i8k_blacklist_fan_support_dmi_table[] __initdata = {
> > > > >   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS13 9333"),
> > > > >   },
> > > > >   },
> > > > > + {
> > > > > + .ident = "Dell XPS 15 L502X",
> > > > > + .matches = {
> > > > > + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > > > > + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Dell System 
> > > > > XPS L502X"),
> > > >
> > > > Hello! Are you sure that it is required to completely disable fan
> > > > support? And not only access to fan type label for which is different
> > > > blaclist i8k_blacklist_fan_type_dmi_table?
> > >
> > > This is a good question. We didn't try the other list. Bob is the one 
> > > with the
> > > affected system. Could you try moving the added block of code from
> > > i8k_blacklist_fan_support_dmi_table a few lines up to
> > > i8k_blacklist_fan_type_dmi_table, Bob, to see if the issue reappears or 
> > > if it
> > > remains fixed?
> > >
> > > >
> > > > And have you reported this issue to Dell support?
> > > >
> > > > > + },
> > > > > + },
> > > > >   { }
> > > > >  };
> > > > >
> > > > > --
> > > > > 2.30.0
> > > > >
> > >
> > > (Apologies for the previous HTML copy of this reply, to those directly 
> > > CCed.)
> > >
> > > -Tom

Re: [PATCH] hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist

[Tom Hebb]

On Mon, Jan 25, 2021 at 2:05 AM Pali Rohár  wrote:
>
> On Saturday 23 January 2021 18:46:08 Thomas Hebb wrote:
> > It has been reported[0] that the Dell XPS 15 L502X exhibits similar
> > freezing behavior to the other systems[1] on this blacklist. The issue
> > was exposed by a prior change of mine to automatically load
> > dell_smm_hwmon on a wider set of XPS models. To fix the regression, add
> > this model to the blacklist.
> >
> > [0] https://bugzilla.kernel.org/show_bug.cgi?id=211081
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=195751
> >
> > Fixes: b8a13e5e8f37 ("hwmon: (dell-smm) Use one DMI match for all XPS 
> > models")
> > Cc: sta...@vger.kernel.org
> > Reported-by: Bob Hepple 
> > Tested-by: Bob Hepple 
> > Signed-off-by: Thomas Hebb 
> > ---
> >
> >  drivers/hwmon/dell-smm-hwmon.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
> > index ec448f5f2dc3..73b9db9e3aab 100644
> > --- a/drivers/hwmon/dell-smm-hwmon.c
> > +++ b/drivers/hwmon/dell-smm-hwmon.c
> > @@ -1159,6 +1159,13 @@ static struct dmi_system_id 
> > i8k_blacklist_fan_support_dmi_table[] __initdata = {
> >   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS13 9333"),
> >   },
> >   },
> > + {
> > + .ident = "Dell XPS 15 L502X",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Dell System XPS 
> > L502X"),
>
> Hello! Are you sure that it is required to completely disable fan
> support? And not only access to fan type label for which is different
> blaclist i8k_blacklist_fan_type_dmi_table?

This is a good question. We didn't try the other list. Bob is the one with the
affected system. Could you try moving the added block of code from
i8k_blacklist_fan_support_dmi_table a few lines up to
i8k_blacklist_fan_type_dmi_table, Bob, to see if the issue reappears or if it
remains fixed?

>
> And have you reported this issue to Dell support?
>
> > + },
> > + },
> >   { }
> >  };
> >
> > --
> > 2.30.0
> >

(Apologies for the previous HTML copy of this reply, to those directly CCed.)

-Tom

Re: [PATCH] tools build feature: Quote CC and CXX for their arguments

[Tom Hebb]

On Wed, Aug 12, 2020 at 3:15 PM Daniel Díaz  wrote:
>
> When using a cross-compilation environment, such as OpenEmbedded,
> the CC an CXX variables are set to something more than just a
> command: there are arguments (such as --sysroot) that need to be
> passed on to the compiler so that the right set of headers and
> libraries are used.
>
> For the particular case that our systems detected, CC is set to
> the following:
>
>   export CC="aarch64-linaro-linux-gcc  
> --sysroot=/oe/build/tmp/work/machine/perf/1.0-r9/recipe-sysroot"
>
> Without quotes, detection is as follows:
>
>   Auto-detecting system features:
>   ... dwarf: [ OFF ]
>   ...dwarf_getlocations: [ OFF ]
>   ... glibc: [ OFF ]
>   ...  gtk2: [ OFF ]
>   ...libbfd: [ OFF ]
>   ...libcap: [ OFF ]
>   ...libelf: [ OFF ]
>   ...   libnuma: [ OFF ]
>   ...numa_num_possible_cpus: [ OFF ]
>   ...   libperl: [ OFF ]
>   ... libpython: [ OFF ]
>   ... libcrypto: [ OFF ]
>   ... libunwind: [ OFF ]
>   ...libdw-dwarf-unwind: [ OFF ]
>   ...  zlib: [ OFF ]
>   ...  lzma: [ OFF ]
>   ... get_cpuid: [ OFF ]
>   ...   bpf: [ OFF ]
>   ...libaio: [ OFF ]
>   ...   libzstd: [ OFF ]
>   ...disassembler-four-args: [ OFF ]
>
>   Makefile.config:414: *** No gnu/libc-version.h found, please install 
> glibc-dev[el].  Stop.
>   Makefile.perf:230: recipe for target 'sub-make' failed
>   make[1]: *** [sub-make] Error 2
>   Makefile:69: recipe for target 'all' failed
>   make: *** [all] Error 2
>
> With CC and CXX quoted, some of those features are now detected.
>
> Fixes: e3232c2f39ac ("tools build feature: Use CC and CXX from parent")
>
> Signed-off-by: Daniel Díaz 

Whoops, I'm the one who introduced this issue. Fix looks good, thanks!

Reviewed-by: Thomas Hebb 
Fixes: e3232c2f39ac ("tools build feature: Use CC and CXX from parent")

> ---
>  tools/build/Makefile.feature | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
> index 774f0b0ca28a..e7818b44b48e 100644
> --- a/tools/build/Makefile.feature
> +++ b/tools/build/Makefile.feature
> @@ -8,7 +8,7 @@ endif
>
>  feature_check = $(eval $(feature_check_code))
>  define feature_check_code
> -  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CC=$(CC) 
> CXX=$(CXX) CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" 
> CXXFLAGS="$(EXTRA_CXXFLAGS) $(FEATURE_CHECK_CXXFLAGS-$(1))" 
> LDFLAGS="$(LDFLAGS) $(FEATURE_CHECK_LDFLAGS-$(1))" -C $(feature_dir) 
> $(OUTPUT_FEATURES)test-$1.bin >/dev/null 2>/dev/null && echo 1 || echo 0)
> +  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CC="$(CC)" 
> CXX="$(CXX)" CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" 
> CXXFLAGS="$(EXTRA_CXXFLAGS) $(FEATURE_CHECK_CXXFLAGS-$(1))" 
> LDFLAGS="$(LDFLAGS) $(FEATURE_CHECK_LDFLAGS-$(1))" -C $(feature_dir) 
> $(OUTPUT_FEATURES)test-$1.bin >/dev/null 2>/dev/null && echo 1 || echo 0)

We should probably also be quoting the arguments that expand $(OUTPUT_FEATURES)
too, although trying to handle path names with spaces is probably a
lost cause anyway.

>  endef
>
>  feature_set = $(eval $(feature_set_code))
> --
> 2.25.1
>

Re: [PATCH] ARM: dts: berlin: switch to earlycon

[Tom Hebb]

Hi Jisheng,

On 07/04/2018 05:14 AM, Jisheng Zhang wrote:
> Hi Thomas,
> 
> On Tue, 29 May 2018 11:41:42 -0400 Thomas Hebb wrote:
> 
>> The Synopsys DesignWare 8250 UART in Berlin SoCs is now supported by
>> 8250_early, so we can use earlycon for early console output instead
>> of earlyprintk, which requires an SoC-specific kernel.
> 
> IIRC, earlyprintk still works during the decompress progress while the
> earlycon doesn't.

Yes, I believe that's correct. My original rationale for this patch was
that earlycon is generally preferred over earlyprintk since it doesn't
require SoC-specific kernels, but now I'm not convinced that either of
the two parameters belongs in the dts file. As you point out,
earlyprintk can do things that earlycon cannot, and in the common case,
neither are needed.

Perhaps removing the bootargs property altogether is more correct. I'm
happy to send another patch to do that if you concur.

>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts| 2 +-
>>  arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 2 +-
>>  arch/arm/boot/dts/berlin2q-marvell-dmp.dts| 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts 
>> b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
>> index 1c475796d17f..f98798bb684f 100644
>> --- a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
>> +++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
>> @@ -45,7 +45,7 @@
>>  compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
>>  
>>  chosen {
>> -bootargs = "earlyprintk";
>> +bootargs = "earlycon";
> 
> Is there something missing here? example, uart8250,mmio,?

No explicit MMIO info is needed for earlycon on DT systems where an
stdout-path property is present. I've tested the patch as-is and the
early output works fine.

>>  stdout-path = "serial0:115200n8";
>>  };
>>  
>> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts 
>> b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> index ca24def0ce13..20f31cdeaf38 100644
>> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> @@ -46,7 +46,7 @@
>>  compatible = "google,chromecast", "marvell,berlin2cd", "marvell,berlin";
>>  
>>  chosen {
>> -bootargs = "earlyprintk";
>> +bootargs = "earlycon";
>>  stdout-path = "serial0:115200n8";
>>  };
>>  
>> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
>> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
>> index 57aa5f8a7c77..9834e84a0797 100644
>> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
>> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
>> @@ -49,7 +49,7 @@
>>  };
>>  
>>  chosen {
>> -bootargs = "earlyprintk";
>> +bootargs = "earlycon";
>>  stdout-path = "serial0:115200n8";
>>  };
>>  
>

Re: [PATCH] ARM: dts: berlin: switch to earlycon

[Tom Hebb]

Hi Jisheng,

On 07/04/2018 05:14 AM, Jisheng Zhang wrote:
> Hi Thomas,
> 
> On Tue, 29 May 2018 11:41:42 -0400 Thomas Hebb wrote:
> 
>> The Synopsys DesignWare 8250 UART in Berlin SoCs is now supported by
>> 8250_early, so we can use earlycon for early console output instead
>> of earlyprintk, which requires an SoC-specific kernel.
> 
> IIRC, earlyprintk still works during the decompress progress while the
> earlycon doesn't.

Yes, I believe that's correct. My original rationale for this patch was
that earlycon is generally preferred over earlyprintk since it doesn't
require SoC-specific kernels, but now I'm not convinced that either of
the two parameters belongs in the dts file. As you point out,
earlyprintk can do things that earlycon cannot, and in the common case,
neither are needed.

Perhaps removing the bootargs property altogether is more correct. I'm
happy to send another patch to do that if you concur.

>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts| 2 +-
>>  arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 2 +-
>>  arch/arm/boot/dts/berlin2q-marvell-dmp.dts| 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts 
>> b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
>> index 1c475796d17f..f98798bb684f 100644
>> --- a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
>> +++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
>> @@ -45,7 +45,7 @@
>>  compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
>>  
>>  chosen {
>> -bootargs = "earlyprintk";
>> +bootargs = "earlycon";
> 
> Is there something missing here? example, uart8250,mmio,?

No explicit MMIO info is needed for earlycon on DT systems where an
stdout-path property is present. I've tested the patch as-is and the
early output works fine.

>>  stdout-path = "serial0:115200n8";
>>  };
>>  
>> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts 
>> b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> index ca24def0ce13..20f31cdeaf38 100644
>> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> @@ -46,7 +46,7 @@
>>  compatible = "google,chromecast", "marvell,berlin2cd", "marvell,berlin";
>>  
>>  chosen {
>> -bootargs = "earlyprintk";
>> +bootargs = "earlycon";
>>  stdout-path = "serial0:115200n8";
>>  };
>>  
>> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
>> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
>> index 57aa5f8a7c77..9834e84a0797 100644
>> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
>> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
>> @@ -49,7 +49,7 @@
>>  };
>>  
>>  chosen {
>> -bootargs = "earlyprintk";
>> +bootargs = "earlycon";
>>  stdout-path = "serial0:115200n8";
>>  };
>>  
>

Re: [PATCH RESEND] pwm: berlin: Don't use broken prescaler values

[Tom Hebb]

On 06/05/2018 05:10 AM, Thierry Reding wrote:
> On Mon, Jun 04, 2018 at 02:32:41PM -0400, Thomas Hebb wrote:
>> Six of the eight prescaler values available for Berlin PWM are not true
>> prescalers but rather internal shifts that throw away the high bits of
>> TCNT. Currently, we attempt to use those high bits, leading to erratic
>> behavior. Restrict the prescaler configurations we select to only the
>> two that respect the full range of TCNT.
>>
>> Tested on BG2CD.
>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  drivers/pwm/pwm-berlin.c | 45 ++--
>>  1 file changed, 25 insertions(+), 20 deletions(-)
> 
> Antoine, Jisheng,
> 
> can you guys review this patch? I'm personally on the fence about this,
> even if we can technically do the shift in software, I don't necessarily
> see a reason why we can't "offload" to the hardware.
> 
> Thierry

Sorry if my commit message was unclear: this patch doesn't just
arbitrarily change the hw/sw division of responsibility. The driver in
its current state is broken (at least on BG2CD), and this patch
implements a fix.

The reason the middle six prescaler values are useless is because they
do not actually slow down the clock. Instead, they emulate slowing down
the clock by internally multiplying TCNT.

This would be a fine trick, if not for the fact that the internal TCNT
value has no extra bits beyond the 16 already exposed to software by the
register. What this means is that, for a prescaler of 4, the software
must ensure that the top two bits of TCNT are not set, because hardware
will chop them off; for a prescaler of 8, the top three bits must not be
set, and so forth. Software does not currently ensure this, resulting in
a TCNT several orders of magnitude lower than intended any time one of
those six prescalers are selected.

Because hardware chops off the high bits in its internal shift, the
middle six prescalers don't actually allow *anything* that the first
doesn't. In fact, they are strictly worse than the first, since the
internal shift of TCNT prevents software from setting the low bits,
decreasing the resolution, without providing any extra high bits.

By skipping the useless prescalers entirely, this patch actually
increases the driver's performance, since, when the 4096 prescaler is
selected, it now does only a single shift rather than the seven
successive divisions it did before.

Let me know if any of this is still unclear, or if you'd like me to
revise the commit message.

-Tom

Re: [PATCH RESEND] pwm: berlin: Don't use broken prescaler values

[Tom Hebb]

On 06/05/2018 05:10 AM, Thierry Reding wrote:
> On Mon, Jun 04, 2018 at 02:32:41PM -0400, Thomas Hebb wrote:
>> Six of the eight prescaler values available for Berlin PWM are not true
>> prescalers but rather internal shifts that throw away the high bits of
>> TCNT. Currently, we attempt to use those high bits, leading to erratic
>> behavior. Restrict the prescaler configurations we select to only the
>> two that respect the full range of TCNT.
>>
>> Tested on BG2CD.
>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  drivers/pwm/pwm-berlin.c | 45 ++--
>>  1 file changed, 25 insertions(+), 20 deletions(-)
> 
> Antoine, Jisheng,
> 
> can you guys review this patch? I'm personally on the fence about this,
> even if we can technically do the shift in software, I don't necessarily
> see a reason why we can't "offload" to the hardware.
> 
> Thierry

Sorry if my commit message was unclear: this patch doesn't just
arbitrarily change the hw/sw division of responsibility. The driver in
its current state is broken (at least on BG2CD), and this patch
implements a fix.

The reason the middle six prescaler values are useless is because they
do not actually slow down the clock. Instead, they emulate slowing down
the clock by internally multiplying TCNT.

This would be a fine trick, if not for the fact that the internal TCNT
value has no extra bits beyond the 16 already exposed to software by the
register. What this means is that, for a prescaler of 4, the software
must ensure that the top two bits of TCNT are not set, because hardware
will chop them off; for a prescaler of 8, the top three bits must not be
set, and so forth. Software does not currently ensure this, resulting in
a TCNT several orders of magnitude lower than intended any time one of
those six prescalers are selected.

Because hardware chops off the high bits in its internal shift, the
middle six prescalers don't actually allow *anything* that the first
doesn't. In fact, they are strictly worse than the first, since the
internal shift of TCNT prevents software from setting the low bits,
decreasing the resolution, without providing any extra high bits.

By skipping the useless prescalers entirely, this patch actually
increases the driver's performance, since, when the 4096 prescaler is
selected, it now does only a single shift rather than the seven
successive divisions it did before.

Let me know if any of this is still unclear, or if you'd like me to
revise the commit message.

-Tom

Re: [PATCH] mmc: sdhci-pxav3: don't disable clocks when we might get an interrupt

[Tom Hebb]

Hi,

On 05/15/2018 01:59 AM, Adrian Hunter wrote:
> On 15/05/18 00:56, Thomas Hebb wrote:
>> Currently, runtime_suspend() unconditionally disables the clock gates
>> for the controller, which means that it's unable to receive interrupts
>> generated by connected SDIO cards.
> 
> We currently get / put runtime pm with enable / disable of the SDIO IRQ
> (refer sdhci_enable_sdio_irq()) so are you sure this is needed?

You're correct; this patch is unnecessary. I wrote it before
923713b35745 ("mmc: sdhci: Disable runtime pm when the sdio_irq is
enabled"), and it was needed then. Sorry for the noise.

FYI, sdhci-esdhc-imx still checks the IRQ in its suspend/resume
functions. That's one of the things that misled me to think this patch
was still relevant.

>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  drivers/mmc/host/sdhci-pxav3.c | 16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
>> index a34434166ca7..59760f3cc1d7 100644
>> --- a/drivers/mmc/host/sdhci-pxav3.c
>> +++ b/drivers/mmc/host/sdhci-pxav3.c
>> @@ -562,9 +562,11 @@ static int sdhci_pxav3_runtime_suspend(struct device 
>> *dev)
>>  if (host->tuning_mode != SDHCI_TUNING_MODE_3)
>>  mmc_retune_needed(host->mmc);
>>  
>> -clk_disable_unprepare(pxa->clk_io);
>> -if (!IS_ERR(pxa->clk_core))
>> -clk_disable_unprepare(pxa->clk_core);
>> +if (!sdhci_sdio_irq_enabled(host)) {
>> +clk_disable_unprepare(pxa->clk_io);
>> +if (!IS_ERR(pxa->clk_core))
>> +clk_disable_unprepare(pxa->clk_core);
>> +}
>>  
>>  return 0;
>>  }
>> @@ -575,9 +577,11 @@ static int sdhci_pxav3_runtime_resume(struct device 
>> *dev)
>>  struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>  struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
>>  
>> -clk_prepare_enable(pxa->clk_io);
>> -if (!IS_ERR(pxa->clk_core))
>> -clk_prepare_enable(pxa->clk_core);
>> +if (!sdhci_sdio_irq_enabled(host)) {
>> +clk_prepare_enable(pxa->clk_io);
>> +if (!IS_ERR(pxa->clk_core))
>> +clk_prepare_enable(pxa->clk_core);
>> +}
>>  
>>  return sdhci_runtime_resume_host(host);
>>  }
>>
> 

Re: [PATCH] mmc: sdhci-pxav3: don't disable clocks when we might get an interrupt

[Tom Hebb]

Hi,

On 05/15/2018 01:59 AM, Adrian Hunter wrote:
> On 15/05/18 00:56, Thomas Hebb wrote:
>> Currently, runtime_suspend() unconditionally disables the clock gates
>> for the controller, which means that it's unable to receive interrupts
>> generated by connected SDIO cards.
> 
> We currently get / put runtime pm with enable / disable of the SDIO IRQ
> (refer sdhci_enable_sdio_irq()) so are you sure this is needed?

You're correct; this patch is unnecessary. I wrote it before
923713b35745 ("mmc: sdhci: Disable runtime pm when the sdio_irq is
enabled"), and it was needed then. Sorry for the noise.

FYI, sdhci-esdhc-imx still checks the IRQ in its suspend/resume
functions. That's one of the things that misled me to think this patch
was still relevant.

>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  drivers/mmc/host/sdhci-pxav3.c | 16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
>> index a34434166ca7..59760f3cc1d7 100644
>> --- a/drivers/mmc/host/sdhci-pxav3.c
>> +++ b/drivers/mmc/host/sdhci-pxav3.c
>> @@ -562,9 +562,11 @@ static int sdhci_pxav3_runtime_suspend(struct device 
>> *dev)
>>  if (host->tuning_mode != SDHCI_TUNING_MODE_3)
>>  mmc_retune_needed(host->mmc);
>>  
>> -clk_disable_unprepare(pxa->clk_io);
>> -if (!IS_ERR(pxa->clk_core))
>> -clk_disable_unprepare(pxa->clk_core);
>> +if (!sdhci_sdio_irq_enabled(host)) {
>> +clk_disable_unprepare(pxa->clk_io);
>> +if (!IS_ERR(pxa->clk_core))
>> +clk_disable_unprepare(pxa->clk_core);
>> +}
>>  
>>  return 0;
>>  }
>> @@ -575,9 +577,11 @@ static int sdhci_pxav3_runtime_resume(struct device 
>> *dev)
>>  struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>  struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
>>  
>> -clk_prepare_enable(pxa->clk_io);
>> -if (!IS_ERR(pxa->clk_core))
>> -clk_prepare_enable(pxa->clk_core);
>> +if (!sdhci_sdio_irq_enabled(host)) {
>> +clk_prepare_enable(pxa->clk_io);
>> +if (!IS_ERR(pxa->clk_core))
>> +clk_prepare_enable(pxa->clk_core);
>> +}
>>  
>>  return sdhci_runtime_resume_host(host);
>>  }
>>
> 

Re: [PATCH] ARM: dts: chromecast: override bad bootloader memory info

[Tom Hebb]

Hi,

On 05/14/2018 10:29 PM, Jisheng Zhang wrote:
> Hi,
> 
> On Mon, 14 May 2018 17:56:45 -0400 Thomas Hebb  wrote:
> 
>> On the Chromecast, the bootloader provides us with an ATAG_MEM of
>> start=0x0100 and size=0x3eff8000. This is clearly incorrect, as the
>> range given encompasses nearly a GiB but the Chromecast only has 512MiB
>> of RAM! Additionally, this causes the kernel to be decompressed at
>> 0x8000, below the claimed beginning of RAM, and so the boot fails.
>>
>> Since the existing ATAG parsing code runs before the kernel is even
>> decompressed and irrevocably patches the device tree, don't even try
> 
> This means you enabled ARM_ATAG_DTB_COMPAT. could we disable it instead?
> The ATAG is useless when we provide dtb. And IIRC, the ATAG is provided due
> to legacy history code.
> 
> Thanks

Thanks for the quick review! It's true that compiling without
ARM_ATAG_DTB_COMPAT will prevent ATAG_MEM from getting parsed at all.
However, it will also prevent ATAG_CMDLINE from getting parsed, and the
command line from the Chromecast's bootloader does actually contain some
useful information--notably the mode in which the system was booted
(normal or recovery).

Userspace could conceivably want this information, so it's preferable
for the kernel to boot regardless of whether ARM_ATAG_DTB_COMPAT is
enabled. That's the intent of this patch.

I do agree in principle that ARM_ATAG_DTB_COMPAT should be disabled
whenever possible.

>> to bypass it. Instead, use the "linux,usable-memory" property instead
>> of the "reg" property to define the real range. The ATAG code only
>> overwrites reg, but linux,usable-memory is checked first in the OF
>> driver, so the fact that reg gets changed makes no difference.
>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 12 +++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts 
>> b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> index 20f31cdeaf38..54221f55bfa2 100644
>> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> @@ -52,7 +52,17 @@
>>  
>>  memory@0 {
>>  device_type = "memory";
>> -reg = <0x 0x2000>; /* 512 MB */
>> +
>> +/*
>> + * We're using "linux,usable-memory" instead of "reg" here
>> + * because the (signed and encrypted) bootloader that shipped
>> + * with this device provides an incorrect memory range in
>> + * ATAG_MEM. Linux helpfully overrides the "reg" property with
>> + * data from the ATAG, so we can't specify the proper range
>> + * normally. Fortunately, this alternate property is checked
>> + * first by the OF driver, so we can (ab)use it instead.
>> + */
>> +linux,usable-memory = <0x 0x2000>; /* 512 MB */
>>  };
>>  
>>  leds {
> 

Re: [PATCH] ARM: dts: chromecast: override bad bootloader memory info

[Tom Hebb]

Hi,

On 05/14/2018 10:29 PM, Jisheng Zhang wrote:
> Hi,
> 
> On Mon, 14 May 2018 17:56:45 -0400 Thomas Hebb  wrote:
> 
>> On the Chromecast, the bootloader provides us with an ATAG_MEM of
>> start=0x0100 and size=0x3eff8000. This is clearly incorrect, as the
>> range given encompasses nearly a GiB but the Chromecast only has 512MiB
>> of RAM! Additionally, this causes the kernel to be decompressed at
>> 0x8000, below the claimed beginning of RAM, and so the boot fails.
>>
>> Since the existing ATAG parsing code runs before the kernel is even
>> decompressed and irrevocably patches the device tree, don't even try
> 
> This means you enabled ARM_ATAG_DTB_COMPAT. could we disable it instead?
> The ATAG is useless when we provide dtb. And IIRC, the ATAG is provided due
> to legacy history code.
> 
> Thanks

Thanks for the quick review! It's true that compiling without
ARM_ATAG_DTB_COMPAT will prevent ATAG_MEM from getting parsed at all.
However, it will also prevent ATAG_CMDLINE from getting parsed, and the
command line from the Chromecast's bootloader does actually contain some
useful information--notably the mode in which the system was booted
(normal or recovery).

Userspace could conceivably want this information, so it's preferable
for the kernel to boot regardless of whether ARM_ATAG_DTB_COMPAT is
enabled. That's the intent of this patch.

I do agree in principle that ARM_ATAG_DTB_COMPAT should be disabled
whenever possible.

>> to bypass it. Instead, use the "linux,usable-memory" property instead
>> of the "reg" property to define the real range. The ATAG code only
>> overwrites reg, but linux,usable-memory is checked first in the OF
>> driver, so the fact that reg gets changed makes no difference.
>>
>> Signed-off-by: Thomas Hebb 
>> ---
>>  arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 12 +++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts 
>> b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> index 20f31cdeaf38..54221f55bfa2 100644
>> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
>> @@ -52,7 +52,17 @@
>>  
>>  memory@0 {
>>  device_type = "memory";
>> -reg = <0x 0x2000>; /* 512 MB */
>> +
>> +/*
>> + * We're using "linux,usable-memory" instead of "reg" here
>> + * because the (signed and encrypted) bootloader that shipped
>> + * with this device provides an incorrect memory range in
>> + * ATAG_MEM. Linux helpfully overrides the "reg" property with
>> + * data from the ATAG, so we can't specify the proper range
>> + * normally. Fortunately, this alternate property is checked
>> + * first by the OF driver, so we can (ab)use it instead.
>> + */
>> +linux,usable-memory = <0x 0x2000>; /* 512 MB */
>>  };
>>  
>>  leds {
> 

[PATCH] Documentation: arm: remove dead links from Marvell Berlin docs

[Tom Hebb]

The BG2 and BG2Q are no longer listed on Marvell's site, so the links in
the README go nowhere. The BG2Q's product brief has also been removed.

Signed-off-by: Thomas Hebb 
---

All the remaining Berlin links are tested working for me as of today,
November 30th, 2015.

 Documentation/arm/Marvell/README | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 360ba97..48c1cb0 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -248,13 +248,10 @@ Berlin family (Multimedia Solutions)
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500/
Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
Design name:BG2Q
Core:   Quad Core ARM Cortex-A9, PL310 L2CC
-   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-pro/
-   Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
88DE
Design name:BG3
Core:   ARM Cortex-A15, CA15 integrated L2CC
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Documentation: arm: remove dead links from Marvell Berlin docs

[Tom Hebb]

The BG2 and BG2Q are no longer listed on Marvell's site, so the links in
the README go nowhere. The BG2Q's product brief has also been removed.

Signed-off-by: Thomas Hebb 
---

All the remaining Berlin links are tested working for me as of today,
November 30th, 2015.

 Documentation/arm/Marvell/README | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 360ba97..48c1cb0 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -248,13 +248,10 @@ Berlin family (Multimedia Solutions)
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500/
Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
Design name:BG2Q
Core:   Quad Core ARM Cortex-A9, PL310 L2CC
-   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-pro/
-   Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
88DE
Design name:BG3
Core:   ARM Cortex-A15, CA15 integrated L2CC
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] Documentation: arm: update homepage URLs for Marvell Berlin SoCs

[Tom Hebb]

You seem to be right about some of the links being broken. I'm fairly
confident that they all worked when I sent the patch, so perhaps Marvell
has taken down some of the pages since then. The homepage no longer has
any mention of the Armada 1500 (BG2) or the Armada 1500 Pro (BG2Q), and
those are also the product pages I can't access. The BG2Q product brief
also seems to be gone, although the BG2 one is still up. All the old
links redirect me to http://www.marvell.com/multimedia-solutions/, which
is what was happening before. If we can't find updated links, though,
perhaps we should remove them altogether. I can send another patch to do
that, provided no one has new links to the missing documents.

-Tom

On 11/20/2015 06:45 PM, Jonathan Corbet wrote:
> On Sat, 14 Nov 2015 21:36:39 -0500
> Tom Hebb  wrote:
> 
>> Marvell has renamed their Berlin family from "Digital Entertainment" to
>> "Multimedia Solutions." There aren't proper redirects set up for
>> device-specific pages, so update the URLs accordingly.
> 
> So not all of these links work for me, but the behavior seems to vary from
> one moment to the next.  I suspect there's a cluster of web servers out of
> sync or something like that.  I'll go ahead and apply this (and the others)
> with Sebastian's ack, but can you verify that the URLs are all as they
> should be?
> 
> Thanks,
> 
> jon
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] Documentation: arm: update homepage URLs for Marvell Berlin SoCs

[Tom Hebb]

You seem to be right about some of the links being broken. I'm fairly
confident that they all worked when I sent the patch, so perhaps Marvell
has taken down some of the pages since then. The homepage no longer has
any mention of the Armada 1500 (BG2) or the Armada 1500 Pro (BG2Q), and
those are also the product pages I can't access. The BG2Q product brief
also seems to be gone, although the BG2 one is still up. All the old
links redirect me to http://www.marvell.com/multimedia-solutions/, which
is what was happening before. If we can't find updated links, though,
perhaps we should remove them altogether. I can send another patch to do
that, provided no one has new links to the missing documents.

-Tom

On 11/20/2015 06:45 PM, Jonathan Corbet wrote:
> On Sat, 14 Nov 2015 21:36:39 -0500
> Tom Hebb <tommyh...@gmail.com> wrote:
> 
>> Marvell has renamed their Berlin family from "Digital Entertainment" to
>> "Multimedia Solutions." There aren't proper redirects set up for
>> device-specific pages, so update the URLs accordingly.
> 
> So not all of these links work for me, but the behavior seems to vary from
> one moment to the next.  I suspect there's a cluster of web servers out of
> sync or something like that.  I'll go ahead and apply this (and the others)
> with Sebastian's ack, but can you verify that the URLs are all as they
> should be?
> 
> Thanks,
> 
> jon
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] Documentation: arm: add Marvell Armada 1500 Mini Plus to SoC list

[Tom Hebb]

Add known information about the Marvell BG2CDP SoC that's used in
the Google Chromecast 2015 and Kinoma HD devices.

Signed-off-by: Thomas Hebb 
---

My previous patch somehow ended up with spaces instead of tabs on
the added lines. This one is consistent with the rest of the section.
Apologies for the extra noise.

 Documentation/arm/Marvell/README | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index e61bedb..139d500 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -237,10 +237,14 @@ Berlin family (Multimedia Solutions)
 -
 
   Flavors:
-   88DE3005, Armada 1500-mini
+   88DE3005, Armada 1500 Mini
Design name:BG2CD
Core:   ARM Cortex-A9, PL310 L2CC
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini/
+   88DE3006, Armada 1500 Mini Plus
+   Design name:BG2CDP
+   Core:   Dual Core ARM Cortex-A7
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] Documentation: arm: add Marvell Armada 1500 Mini Plus to SoC list

[Tom Hebb]

Add known information about the Marvell BG2CDP SoC that's used in
the Google Chromecast 2015 and Kinoma HD devices.

Signed-off-by: Thomas Hebb 
---
 Documentation/arm/Marvell/README | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index e61bedb..4dec2b3 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -237,10 +237,14 @@ Berlin family (Multimedia Solutions)
 -
 
   Flavors:
-   88DE3005, Armada 1500-mini
+   88DE3005, Armada 1500 Mini
Design name:BG2CD
Core:   ARM Cortex-A9, PL310 L2CC
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini/
+88DE3006, Armada 1500 Mini Plus
+Design name:BG2CDP
+Core:   Dual Core ARM Cortex-A7
+Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] Documentation: arm: update Berlin family info in Marvell README

[Tom Hebb]

These are a few changes to bring the Marvell Berlin family documentation
up to date. The old URLs were no longer redirecting properly, so I
changed them to the current ones. I also added what information I could
find about the new BG2CDP chip used in the Chromecast 2015.

Thomas Hebb (3):
  Documentation: arm: update homepage URLs for Marvell Berlin SoCs
  Documentation: arm: add Marvell Armada 1500 Mini Plus to SoC list
  Documentation: arm: remove hyphen from BG2Q in Marvell Berlin docs

 Documentation/arm/Marvell/README | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] Documentation: arm: remove hyphen from BG2Q in Marvell Berlin docs

[Tom Hebb]

The chip's design name isn't hyphenated anywhere else, and none of the
other names in the same document are hyphenated.

Signed-off-by: Thomas Hebb 
---
 Documentation/arm/Marvell/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 4dec2b3..cf5ef7a 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -251,7 +251,7 @@ Berlin family (Multimedia Solutions)
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500/
Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
-   Design name:BG2-Q
+   Design name:BG2Q
Core:   Quad Core ARM Cortex-A9, PL310 L2CC
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-pro/
Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] Documentation: arm: update homepage URLs for Marvell Berlin SoCs

[Tom Hebb]

Marvell has renamed their Berlin family from "Digital Entertainment" to
"Multimedia Solutions." There aren't proper redirects set up for
device-specific pages, so update the URLs accordingly.

Signed-off-by: Thomas Hebb 
---
 Documentation/arm/Marvell/README | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 18a775d..e61bedb 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -233,29 +233,29 @@ MMP/MMP2 family (communication processor)
Linux kernel mach directory: arch/arm/mach-mmp
Linux kernel plat directory: arch/arm/plat-pxa
 
-Berlin family (Digital Entertainment)
+Berlin family (Multimedia Solutions)
 -
 
   Flavors:
88DE3005, Armada 1500-mini
Design name:BG2CD
Core:   ARM Cortex-A9, PL310 L2CC
-   Homepage:   
http://www.marvell.com/digital-entertainment/armada-1500-mini/
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini/
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-   Homepage:   
http://www.marvell.com/digital-entertainment/armada-1500/
-   Product Brief:  
http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500/
+   Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
Design name:BG2-Q
Core:   Quad Core ARM Cortex-A9, PL310 L2CC
-   Homepage:   
http://www.marvell.com/digital-entertainment/armada-1500-pro/
-   Product Brief:  
http://www.marvell.com/digital-entertainment/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-pro/
+   Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
88DE
Design name:BG3
Core:   ARM Cortex-A15, CA15 integrated L2CC
 
-  Homepage: http://www.marvell.com/digital-entertainment/
+  Homepage: http://www.marvell.com/multimedia-solutions/
   Directory: arch/arm/mach-berlin
 
   Comments:
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] Documentation: arm: remove hyphen from BG2Q in Marvell Berlin docs

[Tom Hebb]

The chip's design name isn't hyphenated anywhere else, and none of the
other names in the same document are hyphenated.

Signed-off-by: Thomas Hebb 
---
 Documentation/arm/Marvell/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 4dec2b3..cf5ef7a 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -251,7 +251,7 @@ Berlin family (Multimedia Solutions)
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500/
Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
-   Design name:BG2-Q
+   Design name:BG2Q
Core:   Quad Core ARM Cortex-A9, PL310 L2CC
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-pro/
Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] Documentation: arm: update homepage URLs for Marvell Berlin SoCs

[Tom Hebb]

Marvell has renamed their Berlin family from "Digital Entertainment" to
"Multimedia Solutions." There aren't proper redirects set up for
device-specific pages, so update the URLs accordingly.

Signed-off-by: Thomas Hebb 
---
 Documentation/arm/Marvell/README | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 18a775d..e61bedb 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -233,29 +233,29 @@ MMP/MMP2 family (communication processor)
Linux kernel mach directory: arch/arm/mach-mmp
Linux kernel plat directory: arch/arm/plat-pxa
 
-Berlin family (Digital Entertainment)
+Berlin family (Multimedia Solutions)
 -
 
   Flavors:
88DE3005, Armada 1500-mini
Design name:BG2CD
Core:   ARM Cortex-A9, PL310 L2CC
-   Homepage:   
http://www.marvell.com/digital-entertainment/armada-1500-mini/
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini/
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-   Homepage:   
http://www.marvell.com/digital-entertainment/armada-1500/
-   Product Brief:  
http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500/
+   Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
Design name:BG2-Q
Core:   Quad Core ARM Cortex-A9, PL310 L2CC
-   Homepage:   
http://www.marvell.com/digital-entertainment/armada-1500-pro/
-   Product Brief:  
http://www.marvell.com/digital-entertainment/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-pro/
+   Product Brief:  
http://www.marvell.com/multimedia-solutions/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
88DE
Design name:BG3
Core:   ARM Cortex-A15, CA15 integrated L2CC
 
-  Homepage: http://www.marvell.com/digital-entertainment/
+  Homepage: http://www.marvell.com/multimedia-solutions/
   Directory: arch/arm/mach-berlin
 
   Comments:
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] Documentation: arm: update Berlin family info in Marvell README

[Tom Hebb]

These are a few changes to bring the Marvell Berlin family documentation
up to date. The old URLs were no longer redirecting properly, so I
changed them to the current ones. I also added what information I could
find about the new BG2CDP chip used in the Chromecast 2015.

Thomas Hebb (3):
  Documentation: arm: update homepage URLs for Marvell Berlin SoCs
  Documentation: arm: add Marvell Armada 1500 Mini Plus to SoC list
  Documentation: arm: remove hyphen from BG2Q in Marvell Berlin docs

 Documentation/arm/Marvell/README | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] Documentation: arm: add Marvell Armada 1500 Mini Plus to SoC list

[Tom Hebb]

Add known information about the Marvell BG2CDP SoC that's used in
the Google Chromecast 2015 and Kinoma HD devices.

Signed-off-by: Thomas Hebb 
---
 Documentation/arm/Marvell/README | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index e61bedb..4dec2b3 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -237,10 +237,14 @@ Berlin family (Multimedia Solutions)
 -
 
   Flavors:
-   88DE3005, Armada 1500-mini
+   88DE3005, Armada 1500 Mini
Design name:BG2CD
Core:   ARM Cortex-A9, PL310 L2CC
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini/
+88DE3006, Armada 1500 Mini Plus
+Design name:BG2CDP
+Core:   Dual Core ARM Cortex-A7
+Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] Documentation: arm: add Marvell Armada 1500 Mini Plus to SoC list

[Tom Hebb]

Add known information about the Marvell BG2CDP SoC that's used in
the Google Chromecast 2015 and Kinoma HD devices.

Signed-off-by: Thomas Hebb 
---

My previous patch somehow ended up with spaces instead of tabs on
the added lines. This one is consistent with the rest of the section.
Apologies for the extra noise.

 Documentation/arm/Marvell/README | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index e61bedb..139d500 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -237,10 +237,14 @@ Berlin family (Multimedia Solutions)
 -
 
   Flavors:
-   88DE3005, Armada 1500-mini
+   88DE3005, Armada 1500 Mini
Design name:BG2CD
Core:   ARM Cortex-A9, PL310 L2CC
Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini/
+   88DE3006, Armada 1500 Mini Plus
+   Design name:BG2CDP
+   Core:   Dual Core ARM Cortex-A7
+   Homepage:   
http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
88DE3100, Armada 1500
Design name:BG2
Core:   Marvell PJ4B (ARMv7), Tauros3 L2CC
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/