* [PATCH] fsf2: Use DIV_ROUND_UP() instead of open-coding
From: Geert Uytterhoeven @ 2019-06-20 14:42 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu; +Cc: linux-f2fs-devel, linux-kernel, Geert Uytterhoeven
Replace the open-coded divisions with round-up by calls to the
DIV_ROUND_UP() helper macro.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
fs/f2fs/f2fs.h | 4 ++--
fs/f2fs/file.c | 6 +++---
fs/f2fs/segment.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9afe15675dbbd369..52f477eaaee93bc3 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -480,8 +480,8 @@ static inline int get_inline_xattr_addrs(struct inode *inode);
#define NR_INLINE_DENTRY(inode) (MAX_INLINE_DATA(inode) * BITS_PER_BYTE / \
((SIZE_OF_DIR_ENTRY + F2FS_SLOT_LEN) * \
BITS_PER_BYTE + 1))
-#define INLINE_DENTRY_BITMAP_SIZE(inode) ((NR_INLINE_DENTRY(inode) + \
- BITS_PER_BYTE - 1) / BITS_PER_BYTE)
+#define INLINE_DENTRY_BITMAP_SIZE(inode) \
+ DIV_ROUND_UP(NR_INLINE_DENTRY(inode), BITS_PER_BYTE)
#define INLINE_RESERVED_SIZE(inode) (MAX_INLINE_DATA(inode) - \
((SIZE_OF_DIR_ENTRY + F2FS_SLOT_LEN) * \
NR_INLINE_DENTRY(inode) + \
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 1180eca879331eba..fc00d8bdc31c18b0 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1211,7 +1211,7 @@ static int __exchange_data_block(struct inode *src_inode,
static int f2fs_do_collapse(struct inode *inode, loff_t offset, loff_t len)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- pgoff_t nrpages = (i_size_read(inode) + PAGE_SIZE - 1) / PAGE_SIZE;
+ pgoff_t nrpages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
pgoff_t start = offset >> PAGE_SHIFT;
pgoff_t end = (offset + len) >> PAGE_SHIFT;
int ret;
@@ -1464,7 +1464,7 @@ static int f2fs_insert_range(struct inode *inode, loff_t offset, loff_t len)
pg_start = offset >> PAGE_SHIFT;
pg_end = (offset + len) >> PAGE_SHIFT;
delta = pg_end - pg_start;
- idx = (i_size_read(inode) + PAGE_SIZE - 1) / PAGE_SIZE;
+ idx = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
/* avoid gc operation during block exchange */
down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
@@ -2362,7 +2362,7 @@ static int f2fs_defragment_range(struct f2fs_sb_info *sbi,
if (!fragmented)
goto out;
- sec_num = (total + BLKS_PER_SEC(sbi) - 1) / BLKS_PER_SEC(sbi);
+ sec_num = DIV_ROUND_UP(total, BLKS_PER_SEC(sbi));
/*
* make sure there are enough free section for LFS allocation, this can
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 166ac0f07a4e472d..2ae6df03b9982d12 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -109,7 +109,7 @@
#define START_SEGNO(segno) \
(SIT_BLOCK_OFFSET(segno) * SIT_ENTRY_PER_BLOCK)
#define SIT_BLK_CNT(sbi) \
- ((MAIN_SEGS(sbi) + SIT_ENTRY_PER_BLOCK - 1) / SIT_ENTRY_PER_BLOCK)
+ DIV_ROUND_UP(MAIN_SEGS(sbi), SIT_ENTRY_PER_BLOCK)
#define f2fs_bitmap_size(nr) \
(BITS_TO_LONGS(nr) * sizeof(unsigned long))
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/2] PM / devfreq: Sanitize prints
From: Ezequiel Garcia @ 2019-06-20 14:41 UTC (permalink / raw)
To: Chanwoo Choi, Kyungmin Park, MyungJoo Ham
Cc: kernel, linux-pm, Enric Balletbo i Serra
In-Reply-To: <c053eea7-7c7f-a03a-0f09-83cd006a6a3a@samsung.com>
On Thu, 2019-06-20 at 16:23 +0900, Chanwoo Choi wrote:
> Hi,
>
> Frankly, I don't like the existing 'DEVFREQ: ' prefix
> because it is not used on all error log and it is not necessary.
>
> Instead of this patch, I just prefer to delete the 'DEVFREQ: ' prefix
>
Hm, I have to disagree. Having naked pr_{} with just the __func__
reducess logging consistency.
Thanks,
Ezequiel
^ permalink raw reply
* Re: [PATCH] carl9170: fix enum compare splat
From: Christian Lamparter @ 2019-06-20 14:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87a7ef9jp2.fsf@kamboji.qca.qualcomm.com>
On Tuesday, June 18, 2019 2:11:53 PM CEST Kalle Valo wrote:
> Christian Lamparter <chunkeey@gmail.com> writes:
> > On Monday, June 10, 2019 9:06:30 AM CEST Kalle Valo wrote:
> >> Christian Lamparter <chunkeey@gmail.com> writes:
> >>
> >> > This patch fixes a noisy warning triggered by -Wenum-compare
> >> >
> >> > |main.c:1390:31: warning: comparison between ‘enum nl80211_ac’
> >> > | and ‘enum ar9170_txq’ [-Wenum-compare]
> >> > | BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> >> > | ^
> >> > | [...]
> >> >
> >> > This is a little bit unfortunate, since the number of queues
> >> > (hence NL80211_NUM_ACS) is a constant based on the IEEE 802.11
> >> > (much like IEEE80211_NUM_ACS) and __AR9170_NUM_TXQ is more or
> >> > less defined by the AR9170 hardware.
> >>
> >> Is the warning enabled by default? TBH I'm not seeing how useful this
> >> warning is for kernel development.
> >
> > It is included in the "-Wall" (which is coming from "KBUILD_CFLAGS"
> > in the main Makefile).
> >
> > I tried debian's gcc starting from 4.6 to the lastest 8.3. They all
> > complain about it in various degrees.
> >
> > https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Warning-Options.html#Warning-Options
>
> Ok, odd that I haven't noticed this warning. Maybe I have been just
> blind.
Sorry. No, I messed up there. I made a patch back in the day during the spectre
mac80211 patches that I kept in my tree for the driver. But I now remember that
I never published those because of that exact "warning".
These lines are coming from there.
> >> > --- a/drivers/net/wireless/ath/carl9170/main.c
> >> > +++ b/drivers/net/wireless/ath/carl9170/main.c
> >> > @@ -1387,7 +1387,7 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
> >> > int ret;
> >> >
> >> > BUILD_BUG_ON(ARRAY_SIZE(ar9170_qmap) != __AR9170_NUM_TXQ);
> >> > - BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> >> > + BUILD_BUG_ON((size_t)NL80211_NUM_ACS > (size_t)__AR9170_NUM_TXQ);
> >>
> >> IMHO this just makes the code worse. Does it make sense to workaround
> >> (stupid) compiler warnings like this?
> >
> > True. What's worse: This isn't really code. The BUILD_BUG_ON Macro is there
> > to guard but it's getting compiled away. I could also just drop it.
>
> Either way is fine for me. If the GCC (by default) emits a warning for
> this we need to silence that warning, so in that respect I guess we
> should apply this. Unless better solutions come up, of course :)
Note: I dropped this patch from patchwork. So, there's nothing that
needs to be done now ;)
Well, except OT: Would you mind adding the QCA4019 boardfiles that
have accumulated over the past six-ish months?
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg09966.html>
That list already had:
ath10k-firmware: QCA4019 hw1.0: Add ASUS Lyra specific BDFs
ath10k-firmware: QCA4019 hw1.0: Add Linksys EA6350v3
ath10k-firmware: QCA4019 hw1.0: Add Qxwlan E2600AC specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A62 specific BDFs
ath10k-firmware: QCA9888 hw2.0: Update OpenMesh A62 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A42 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Add ALFA Network AP120C-AC specific BDF
ath10k-firmware: QCA4019 hw1.0: Add AVM FRITZ!Box 7530 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update Linksys EA6350v3 specific BDFs
and now there's even more:
+ ath10k-firmware: QCA4019 hw1.0: Add Qxwlan E2600AC specific BDFs
(Watch out, there are multiple versions! The first ones are dodgy
with a bad crc)
This should be the right "one"
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10007.html>
+ ath10k-firmware: QCA4019 hw1.0: Add AVM FRITZ!Repeater 3000 specific BDFs
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10101.html>
+ ath10k-firmware: IPQ4018 hw1.0: Add EnGenius ENS620EXT specific BDFs
<http://lists.infradead.org/pipermail/ath10k/2019-March/013034.html>
+ ath10k-firmware: QCA9984 hw1.0: Update Netgear Orbi Pro SRK60 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update Netgear Orbi Pro SRK60 specific BDFs
One for QCA9984 and one for two QCA4019
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10170.html>
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10171.html>
+ ath10k-firmware: IPQ4019 hw1.0: Add BDF for Linksys EA8300 [1/2]
ath10k-firmware: QCA9888 hw1.0: Add BDF for Linksys EA8300 [2/2]
<http://lists.infradead.org/pipermail/ath10k/2019-May/013403.html>
<http://lists.infradead.org/pipermail/ath10k/2019-May/013404.html>
Cheers,
Christian
^ permalink raw reply
* RE: [PATCH] net: phylink: set the autoneg state in phylink_phy_change
From: Ioana Ciornei @ 2019-06-20 14:40 UTC (permalink / raw)
To: Russell King - ARM Linux admin, David Miller
Cc: andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com,
netdev@vger.kernel.org
In-Reply-To: <20190616094226.bnhivshhnzeokplu@shell.armlinux.org.uk>
> Subject: Re: [PATCH] net: phylink: set the autoneg state in phylink_phy_change
>
> On Sat, Jun 15, 2019 at 06:08:54PM -0700, David Miller wrote:
> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Date: Sat, 15 Jun 2019 23:13:28 +0100
> >
> > > On Sat, Jun 15, 2019 at 01:30:21PM -0700, David Miller wrote:
> > >> From: Ioana Ciornei <ioana.ciornei@nxp.com>
> > >> Date: Thu, 13 Jun 2019 09:37:51 +0300
> > >>
> > >> > The phy_state field of phylink should carry only valid
> > >> > information especially when this can be passed to the .mac_config
> callback.
> > >> > Update the an_enabled field with the autoneg state in the
> > >> > phylink_phy_change function.
> > >> >
> > >> > Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
> > >> > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > >>
> > >> Applied and queued up for -stable, thanks.
> > >
> > > This is not a fix; it is an attempt to make phylink work differently
> > > from how it's been designed for the dpaa2 driver. I've already
> > > stated that this field is completely meaningless, so I'm surprised
> > > you applied it.
> >
> > I'm sorry, I did wait a day or so to see any direct responses to this
> > patch and I saw no feedback.
> >
> > I'll revert.
>
> Hi Dave,
>
> Thanks for the revert. There was discussion surrounding this patch:
>
> https://www.mail-archive.com/netdev@vger.kernel.org/thrd2.html#302220
>
> It was then re-posted as part of a later RFC series ("DPAA2 MAC
> Driver") which shows why the change was proposed, where the discussion
> continued on Friday. The patch ended up with a slightly different subject line.
>
> There is still further discussion required to try and work out a way forward.
>
> Thanks.
>
Hi all,
Sorry for not commenting on this until now but last weekend I had an unfortunate accident and ended up with a broken ankle. I'll start responding to all the emails and get back into this.
--
Ioana
^ permalink raw reply
* Re: [PATCH 0/4] drm/bridge: dw-hdmi: Add support for HDR metadata
From: Neil Armstrong @ 2019-06-20 14:40 UTC (permalink / raw)
To: Jonas Karlman, a.hajda@samsung.com,
Laurent.pinchart@ideasonboard.com
Cc: jernej.skrabec@siol.net, khilman@baylibre.com,
zhengyang@rock-chips.com, maxime.ripard@bootlin.com,
wens@csie.org, hjc@rock-chips.com, heiko@sntech.de,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
In-Reply-To: <VI1PR03MB420621617DDEAB3596700DE0AC1C0@VI1PR03MB4206.eurprd03.prod.outlook.com>
Hi Andrzej,
Gentle ping, could you review the dw-hdmi changes here ?
Thanks,
Neil
On 26/05/2019 23:18, Jonas Karlman wrote:
> Add support for HDR metadata using the hdr_output_metadata connector property,
> configure Dynamic Range and Mastering InfoFrame accordingly.
>
> A drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers
> can use to signal when Dynamic Range and Mastering infoframes is supported.
> This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version,
> and only GXL support DRM InfoFrame.
>
> The first patch add functionality to configure DRM InfoFrame based on the
> hdr_output_metadata connector property.
>
> The remaining patches sets the drm_infoframe flag on some SoCs supporting
> Dynamic Range and Mastering InfoFrame.
>
> Note that this was based on top of drm-misc-next and Neil Armstrong's
> "drm/meson: Add support for HDMI2.0 YUV420 4k60" series at [1]
>
> [1] https://patchwork.freedesktop.org/series/58725/#rev2
>
> Jonas Karlman (4):
> drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support
> drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399
> drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A
> drm/sun4i: Enable DRM InfoFrame support on H6
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 109 ++++++++++++++++++++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++++++
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 +
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> include/drm/bridge/dw_hdmi.h | 1 +
> 7 files changed, 157 insertions(+)
>
^ permalink raw reply
* Re: [PATCH v2] mm, memcg: Add a memcg_slabinfo debugfs file
From: Shakeel Butt @ 2019-06-20 14:39 UTC (permalink / raw)
To: Waiman Long
Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
Andrew Morton, Linux MM, LKML, Michal Hocko, Roman Gushchin,
Johannes Weiner, Vladimir Davydov
In-Reply-To: <cfc6c800-1cb4-e2f2-e6d9-f0571c11a47b@redhat.com>
On Thu, Jun 20, 2019 at 7:24 AM Waiman Long <longman@redhat.com> wrote:
>
> On 6/19/19 7:48 PM, Shakeel Butt wrote:
> > Hi Waiman,
> >
> > On Wed, Jun 19, 2019 at 10:16 AM Waiman Long <longman@redhat.com> wrote:
> >> There are concerns about memory leaks from extensive use of memory
> >> cgroups as each memory cgroup creates its own set of kmem caches. There
> >> is a possiblity that the memcg kmem caches may remain even after the
> >> memory cgroups have been offlined. Therefore, it will be useful to show
> >> the status of each of memcg kmem caches.
> >>
> >> This patch introduces a new <debugfs>/memcg_slabinfo file which is
> >> somewhat similar to /proc/slabinfo in format, but lists only information
> >> about kmem caches that have child memcg kmem caches. Information
> >> available in /proc/slabinfo are not repeated in memcg_slabinfo.
> >>
> >> A portion of a sample output of the file was:
> >>
> >> # <name> <css_id[:dead]> <active_objs> <num_objs> <active_slabs> <num_slabs>
> >> rpc_inode_cache root 13 51 1 1
> >> rpc_inode_cache 48 0 0 0 0
> >> fat_inode_cache root 1 45 1 1
> >> fat_inode_cache 41 2 45 1 1
> >> xfs_inode root 770 816 24 24
> >> xfs_inode 92 22 34 1 1
> >> xfs_inode 88:dead 1 34 1 1
> >> xfs_inode 89:dead 23 34 1 1
> >> xfs_inode 85 4 34 1 1
> >> xfs_inode 84 9 34 1 1
> >>
> >> The css id of the memcg is also listed. If a memcg is not online,
> >> the tag ":dead" will be attached as shown above.
> >>
> >> Suggested-by: Shakeel Butt <shakeelb@google.com>
> >> Signed-off-by: Waiman Long <longman@redhat.com>
> >> ---
> >> mm/slab_common.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 57 insertions(+)
> >>
> >> diff --git a/mm/slab_common.c b/mm/slab_common.c
> >> index 58251ba63e4a..2bca1558a722 100644
> >> --- a/mm/slab_common.c
> >> +++ b/mm/slab_common.c
> >> @@ -17,6 +17,7 @@
> >> #include <linux/uaccess.h>
> >> #include <linux/seq_file.h>
> >> #include <linux/proc_fs.h>
> >> +#include <linux/debugfs.h>
> >> #include <asm/cacheflush.h>
> >> #include <asm/tlbflush.h>
> >> #include <asm/page.h>
> >> @@ -1498,6 +1499,62 @@ static int __init slab_proc_init(void)
> >> return 0;
> >> }
> >> module_init(slab_proc_init);
> >> +
> >> +#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_MEMCG_KMEM)
> >> +/*
> >> + * Display information about kmem caches that have child memcg caches.
> >> + */
> >> +static int memcg_slabinfo_show(struct seq_file *m, void *unused)
> >> +{
> >> + struct kmem_cache *s, *c;
> >> + struct slabinfo sinfo;
> >> +
> >> + mutex_lock(&slab_mutex);
> > On large machines there can be thousands of memcgs and potentially
> > each memcg can have hundreds of kmem caches. So, the slab_mutex can be
> > held for a very long time.
>
> But that is also what /proc/slabinfo does by doing mutex_lock() at
> slab_start() and mutex_unlock() at slab_stop(). So the same problem will
> happen when /proc/slabinfo is being read.
>
> When you are in a situation that reading /proc/slabinfo take a long time
> because of the large number of memcg's, the system is in some kind of
> trouble anyway. I am saying that we should not improve the scalability
> of this patch. It is just that some nasty race conditions may pop up if
> we release the lock and re-acquire it latter. That will greatly
> complicate the code to handle all those edge cases.
>
We have been using that interface and implementation for couple of
years and have not seen any race condition. However I am fine with
what you have here for now. We can always come back if we think we
need to improve it.
> > Our internal implementation traverses the memcg tree and then
> > traverses 'memcg->kmem_caches' within the slab_mutex (and
> > cond_resched() after unlock).
> For cgroup v1, the setting of the CONFIG_SLUB_DEBUG option will allow
> you to iterate and display slabinfo just for that particular memcg. I am
> thinking of extending the debug controller to do similar thing for
> cgroup v2.
I was also planning to look into that and it seems like you are
already on it. Do CC me the patches.
> >> + seq_puts(m, "# <name> <css_id[:dead]> <active_objs> <num_objs>");
> >> + seq_puts(m, " <active_slabs> <num_slabs>\n");
> >> + list_for_each_entry(s, &slab_root_caches, root_caches_node) {
> >> + /*
> >> + * Skip kmem caches that don't have any memcg children.
> >> + */
> >> + if (list_empty(&s->memcg_params.children))
> >> + continue;
> >> +
> >> + memset(&sinfo, 0, sizeof(sinfo));
> >> + get_slabinfo(s, &sinfo);
> >> + seq_printf(m, "%-17s root %6lu %6lu %6lu %6lu\n",
> >> + cache_name(s), sinfo.active_objs, sinfo.num_objs,
> >> + sinfo.active_slabs, sinfo.num_slabs);
> >> +
> >> + for_each_memcg_cache(c, s) {
> >> + struct cgroup_subsys_state *css;
> >> + char *dead = "";
> >> +
> >> + css = &c->memcg_params.memcg->css;
> >> + if (!(css->flags & CSS_ONLINE))
> >> + dead = ":dead";
> > Please note that Roman's kmem cache reparenting patch series have made
> > kmem caches of zombie memcgs a bit tricky. On memcg offlining the
> > memcg kmem caches are reparented and the css->id can get recycled. So,
> > we want to know that the a kmem cache is reparented and which memcg it
> > belonged to initially. Determining if a kmem cache is reparented, we
> > can store a flag on the kmem cache and for the previous memcg we can
> > use fhandle. However to not make this more complicated, for now, we
> > can just have the info that the kmem cache was reparented i.e. belongs
> > to an offlined memcg.
>
> I need to play with Roman's kmem cache reparenting patch a bit more to
> see how to properly recognize a reparent'ed kmem cache. What I have
> noticed is that the dead kmem caches that I saw at boot up were gone
> after applying his patch. So that is a good thing.
>
By gone, do you mean the kmem cache got freed or the kmem cache is not
part of online parent memcg and thus no more dead kmem cache?
> For now, I think the current patch is good enough for its purpose. I may
> send follow-up if I see something that can be improved.
>
I would like to see the recognition of reparent'ed kmem cache in this
patch. However if others are ok with the current status of the patch
then I will not stand in the way.
thanks,
Shakeel
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH 0/9] hw/acpi: make build_madt arch agnostic
From: Wei Yang @ 2019-06-20 14:18 UTC (permalink / raw)
To: Igor Mammedov
Cc: yang.zhong, ehabkost, mst, qemu-devel, Wei Yang, pbonzini, rth
In-Reply-To: <20190619110440.13a54848@redhat.com>
On Wed, Jun 19, 2019 at 11:04:40AM +0200, Igor Mammedov wrote:
>On Wed, 19 Jun 2019 14:20:50 +0800
>Wei Yang <richardw.yang@linux.intel.com> wrote:
>
>> On Tue, Jun 18, 2019 at 05:59:56PM +0200, Igor Mammedov wrote:
>> >
>> >On Mon, 13 May 2019 14:19:04 +0800
>> >Wei Yang <richardw.yang@linux.intel.com> wrote:
>> >
>> >> Now MADT is highly depend in architecture and machine type and leaves
>> >> duplicated code in different architecture. The series here tries to generalize
>> >> it.
>> >>
>> >> MADT contains one main table and several sub tables. These sub tables are
>> >> highly related to architecture. Here we introduce one method to make it
>> >> architecture agnostic.
>> >>
>> >> * each architecture define its sub-table implementation function in madt_sub
>> >> * introduces struct madt_input to collect sub table information and pass to
>> >> build_madt
>> >>
>> >> By doing so, each architecture could prepare its own sub-table implementation
>> >> and madt_input. And keep build_madt architecture agnostic.
>> >
>> >I've skimmed over patches, and to me it looks mostly as code movement
>> >without apparent benefits and probably a bit more complex than what we have now
>> >(it might be ok cost if it simplifies MADT support for other boards).
>> >
>> >Before I do line by line review could you demonstrate what effect new way
>> >to build MADT would have on arm/virt and i386/virt (from NEMU). So it would be
>> >possible to estimate net benefits from new approach?
>> >(PS: it doesn't have to be patches ready for merging, just a dirty hack
>> >that would demonstrate adding MADT for new board using mad_sub[])
>> >
>>
>> Per APIC spec 5.2.12, MADT contains a *main* table and several *sub* tables
>> (Interrupt Controllere), so the idea is give a callback hook in
>> AcpiDeviceIfClass for each table, including *main* and *sub* table.
>>
>> Current AcpiDeviceIfClass has one callback pc_madt_cpu_entry for some *sub*
>> tables, after replacing the AcpiDeviceIfClass will look like this:
>>
>> typedef struct AcpiDeviceIfClass {
>> /* <private> */
>> InterfaceClass parent_class;
>>
>> /* <public> */
>> void (*ospm_status)(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
>> void (*send_event)(AcpiDeviceIf *adev, AcpiEventStatusBits ev);
>> - void (*madt_cpu)(AcpiDeviceIf *adev, int uid,
>> - const CPUArchIdList *apic_ids, GArray *entry);
>> + madt_operation madt_main;
>> + madt_operation *madt_sub;
>> } AcpiDeviceIfClass;
>>
>> By doing so, each arch could have its own implementation for MADT.
>>
>> After this refactoring, build_madt could be simplified to:
>>
>> build_madt(GArray *table_data, BIOSLinker *linker, PCMachineState *pcms,
>> struct madt_input *input)
>> {
>> ...
>>
>> if (adevc->madt_main) {
>> adevc->madt_main(table_data, madt);
>> }
>>
>> for (i = 0; ; i++) {
>> sub_id = input[i].sub_id;
>> if (sub_id == ACPI_APIC_RESERVED) {
>> break;
>> }
>> opaque = input[i].opaque;
>> adevc->madt_sub[sub_id](table_data, opaque);
>> }
>>
>> ...
>> }
>>
>> input is a list of data necessary to build *sub* table. Its details is also
>> arch dependent.
>I've got general idea reading patches in this series.
>As I've mentioned before it's hard to generalize MADT since it
>mostly contains entries unique for target/board.
>Goal here isn't generalizing at any cost, but rather find out
>if there is enough common code to justify generalization
>and if it allows us to reduce code duplication and simplify.
>
>> For following new arch, what it need to do is prepare the input array and
>> implement necessary *main*/*sub* table callbacks.
>What I'd like to see is the actual patch that does this,
>to see if it has any merit and to compare to the current
>approach.
I didn't get some idea about your approach. Would you mind sharing more light?
--
Wei Yang
Help you, Help me
^ permalink raw reply
* [Buildroot] [git commit] package/sqlite: work around build timeout on Microblaze
From: Thomas Petazzoni @ 2019-06-20 14:39 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=79bea6cf60665c4a17a5066a2043b05aa45eca85
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
With Microblaze Gcc version 4.9 build hangs due to a bug discovered
for Gcc 4.9 only. Since Gcc 4.9 is not maintaned anymore it doesn't
make sense to report this bug in Gcc bugzilla and use
BR2_TOOLCHAIN_HAS_GCC_BUG_. So let's check if we're building for
Microblaze with Gcc version < 5.x and work around the bug forcing the
use of -O0.
To reproduce this bug build with following defconfig:
'
BR2_microblazeel=y
BR2_ENABLE_DEBUG=y
BR2_OPTIMIZE_2=y
BR2_KERNEL_HEADERS_5_0=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_GCC_VERSION_4_9_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TOOLCHAIN_BUILDROOT_FORTRAN=y
BR2_GCC_ENABLE_LTO=y
BR2_PACKAGE_SQLITE=y
'
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/sqlite/sqlite.mk | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/package/sqlite/sqlite.mk b/package/sqlite/sqlite.mk
index 7e97c966b7..d4cdefe34d 100644
--- a/package/sqlite/sqlite.mk
+++ b/package/sqlite/sqlite.mk
@@ -39,8 +39,14 @@ ifeq ($(BR2_PACKAGE_SQLITE_NO_SYNC),y)
SQLITE_CFLAGS += -DSQLITE_NO_SYNC
endif
+# Building with Microblaze Gcc 4.9 makes compiling to hang.
+# Work around using -O0
+ifeq ($(BR2_microblaze):$(BR2_TOOLCHAIN_GCC_AT_LEAST_5),y:)
+SQLITE_CFLAGS += $(TARGET_CFLAGS) -O0
+else
# fallback to standard -O3 when -Ofast is present to avoid -ffast-math
SQLITE_CFLAGS += $(subst -Ofast,-O3,$(TARGET_CFLAGS))
+endif
SQLITE_CONF_ENV = CFLAGS="$(SQLITE_CFLAGS)"
^ permalink raw reply related
* [PATCH v7 5/5] arm64: dts: qcom: Add Asus NovaGo TP370QL
From: Jeffrey Hugo @ 2019-06-20 14:39 UTC (permalink / raw)
To: bjorn.andersson, agross
Cc: benjamin.tissoires, dmitry.torokhov, jikos, hdegoede, lee.jones,
xnox, robh+dt, mark.rutland, linux-input, devicetree,
linux-arm-msm, linux-kernel, Jeffrey Hugo
In-Reply-To: <20190620142801.11827-1-jeffrey.l.hugo@gmail.com>
This adds the initial DT for the Asus NovaGo TP370QL laptop. Supported
functionality includes USB (host), microSD-card, keyboard, and trackpad.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/msm8998-asus-novago-tp370ql.dts | 47 +++++++++++++++++++
2 files changed, 48 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 76436f33a013..5cd1844a6d33 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8998-asus-novago-tp370ql.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-hp-envy-x2.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-lenovo-miix-630.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dts b/arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dts
new file mode 100644
index 000000000000..db5821be1e2f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dts
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
+
+/dts-v1/;
+
+#include "msm8998-clamshell.dtsi"
+
+/ {
+ model = "Asus NovaGo TP370QL";
+ compatible = "asus,novago-tp370ql", "qcom,msm8998";
+};
+
+&blsp1_i2c6 {
+ status = "okay";
+
+ touchpad@15 {
+ compatible = "hid-over-i2c";
+ interrupt-parent = <&tlmm>;
+ interrupts = <0x7b IRQ_TYPE_LEVEL_LOW>;
+ reg = <0x15>;
+ hid-descr-addr = <0x0001>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&touchpad>;
+ };
+
+ keyboard@3a {
+ compatible = "hid-over-i2c";
+ interrupt-parent = <&tlmm>;
+ interrupts = <0x25 IRQ_TYPE_LEVEL_LOW>;
+ reg = <0x3a>;
+ hid-descr-addr = <0x0001>;
+ };
+};
+
+&sdhc2 {
+ cd-gpios = <&tlmm 95 GPIO_ACTIVE_HIGH>;
+};
+
+&tlmm {
+ touchpad: touchpad {
+ config {
+ pins = "gpio123";
+ bias-pull-up;
+ };
+ };
+};
--
2.17.1
^ permalink raw reply related
* Re: WARNING in add_event_to_ctx
From: syzbot @ 2019-06-20 14:39 UTC (permalink / raw)
To: acme, acme, alexander.shishkin, ast, bpf, daniel, davem, jbacik,
jolsa, kafai, kernel-team, linux-kernel, mingo, mingo, namhyung,
netdev, peterz, rostedt, songliubraving, syzkaller-bugs, tglx,
torvalds, yhs
In-Reply-To: <000000000000946842058bc1291d@google.com>
syzbot has bisected this bug to:
commit 33ea4b24277b06dbc55d7f5772a46f029600255e
Author: Song Liu <songliubraving@fb.com>
Date: Wed Dec 6 22:45:16 2017 +0000
perf/core: Implement the 'perf_uprobe' PMU
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17561aa1a00000
start commit: abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=14d61aa1a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=10d61aa1a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=28ec3437a5394ee0
dashboard link: https://syzkaller.appspot.com/bug?extid=704bfe2c7d156640ad7a
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16d8b732a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f7a5e6a00000
Reported-by: syzbot+704bfe2c7d156640ad7a@syzkaller.appspotmail.com
Fixes: 33ea4b24277b ("perf/core: Implement the 'perf_uprobe' PMU")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH] ath11k: clean up in htt ppdu stats
From: Kalle Valo @ 2019-06-20 14:38 UTC (permalink / raw)
To: Venkateswara Naralasetty; +Cc: ath11k
In-Reply-To: <20190620143745.E0DCB60300@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Venkateswara Naralasetty <vnaralas@codeaurora.org> wrote:
>
>> Removed pointer arithmetic and the magic numbers
>>
>> Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>
> Patch applied to ath11k-bringup branch of ath.git, thanks.
>
> 6f55fd062ae0 ath11k: clean up in htt ppdu stats
There was a conflict, please double check my resolution.
--
Kalle Valo
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply
* [PATCH v7 4/5] arm64: dts: qcom: Add HP Envy x2
From: Jeffrey Hugo @ 2019-06-20 14:38 UTC (permalink / raw)
To: bjorn.andersson, agross
Cc: benjamin.tissoires, dmitry.torokhov, jikos, hdegoede, lee.jones,
xnox, robh+dt, mark.rutland, linux-input, devicetree,
linux-arm-msm, linux-kernel, Jeffrey Hugo
In-Reply-To: <20190620142801.11827-1-jeffrey.l.hugo@gmail.com>
This adds the initial DT for the HP Envy x2 laptop. Supported
functionality includes USB (host), microSD-card, keyboard, and trackpad.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/msm8998-hp-envy-x2.dts | 30 +++++++++++++++++++
2 files changed, 31 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index c3e4307bcbd4..76436f33a013 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8998-hp-envy-x2.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-lenovo-miix-630.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm845-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts b/arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts
new file mode 100644
index 000000000000..24073127091f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
+
+/dts-v1/;
+
+#include "msm8998-clamshell.dtsi"
+
+/ {
+ model = "HP Envy x2";
+ compatible = "hp,envy-x2", "qcom,msm8998";
+};
+
+&blsp1_i2c6 {
+ status = "okay";
+
+ keyboard@3a {
+ compatible = "hid-over-i2c";
+ interrupt-parent = <&tlmm>;
+ interrupts = <0x79 IRQ_TYPE_LEVEL_LOW>;
+ reg = <0x3a>;
+ hid-descr-addr = <0x0001>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&touchpad>;
+ };
+};
+
+&sdhc2 {
+ cd-gpios = <&tlmm 95 GPIO_ACTIVE_LOW>;
+};
--
2.17.1
^ permalink raw reply related
* [igt-dev] ✓ Fi.CI.IGT: success for lib/i915: gem_engine_topology: get eb flags from engine's coordiantes
From: Patchwork @ 2019-06-20 14:38 UTC (permalink / raw)
To: Andi Shyti; +Cc: igt-dev
In-Reply-To: <20190619221911.2684-1-andi.shyti@intel.com>
== Series Details ==
Series: lib/i915: gem_engine_topology: get eb flags from engine's coordiantes
URL : https://patchwork.freedesktop.org/series/62414/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6312_full -> IGTPW_3179_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/62414/revisions/1/mbox/
Known issues
------------
Here are the changes found in IGTPW_3179_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_eio@in-flight-contexts-immediate:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +3 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl7/igt@gem_eio@in-flight-contexts-immediate.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-kbl2/igt@gem_eio@in-flight-contexts-immediate.html
* igt@gem_eio@wait-wedge-10ms:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +3 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl7/igt@gem_eio@wait-wedge-10ms.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-apl8/igt@gem_eio@wait-wedge-10ms.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-snb: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-snb7/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html
* igt@gem_workarounds@suspend-resume:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +5 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl7/igt@gem_workarounds@suspend-resume.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-apl1/igt@gem_workarounds@suspend-resume.html
* igt@i915_hangman@error-state-basic:
- shard-snb: [PASS][9] -> [DMESG-WARN][10] ([fdo#110789] / [fdo#110913 ])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb1/igt@i915_hangman@error-state-basic.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-snb1/igt@i915_hangman@error-state-basic.html
* igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-snb: [PASS][11] -> [SKIP][12] ([fdo#109271])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb1/igt@i915_pm_rc6_residency@rc6-accuracy.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-snb2/igt@i915_pm_rc6_residency@rc6-accuracy.html
* igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen:
- shard-kbl: [PASS][13] -> [FAIL][14] ([fdo#103232])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html
- shard-apl: [PASS][15] -> [FAIL][16] ([fdo#103232])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl7/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-apl6/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw: [PASS][17] -> [FAIL][18] ([fdo#105767])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-hsw: [PASS][19] -> [SKIP][20] ([fdo#109271]) +19 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw4/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-hsw1/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl6/igt@kms_setmode@basic.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-apl4/igt@kms_setmode@basic.html
#### Possible fixes ####
* igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
- shard-snb: [DMESG-WARN][23] ([fdo#110789] / [fdo#110913 ]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-snb6/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-apl: [DMESG-WARN][25] ([fdo#110913 ]) -> [PASS][26] +4 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl3/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-apl1/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
- shard-snb: [DMESG-WARN][27] ([fdo#110913 ]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb5/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-snb2/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-kbl: [DMESG-WARN][29] ([fdo#110913 ]) -> [PASS][30] +2 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl1/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-kbl2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
* igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge:
- shard-snb: [SKIP][31] ([fdo#109271] / [fdo#109278]) -> [PASS][32]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-snb5/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [FAIL][33] ([fdo#104873]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk8/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-glk6/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite:
- shard-hsw: [SKIP][35] ([fdo#109271]) -> [PASS][36] +22 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw1/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-hsw8/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [DMESG-WARN][37] ([fdo#108566]) -> [PASS][38] +1 similar issue
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl3/igt@kms_frontbuffer_tracking@fbc-suspend.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-apl4/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_plane@plane-panning-bottom-right-pipe-b-planes:
- shard-snb: [SKIP][39] ([fdo#109271]) -> [PASS][40] +1 similar issue
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
* igt@kms_setmode@basic:
- shard-kbl: [FAIL][41] ([fdo#99912]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl1/igt@kms_setmode@basic.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/shard-kbl6/igt@kms_setmode@basic.html
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
[fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (10 -> 5)
------------------------------
Missing (5): shard-skl pig-hsw-4770r pig-glk-j5005 shard-iclb pig-skl-6260u
Build changes
-------------
* IGT: IGT_5061 -> IGTPW_3179
* Piglit: piglit_4509 -> None
CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_3179: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/
IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3179/
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH V2 1/4] ath11k: Clean up void *per_transfer_context[] in ce
From: Kalle Valo @ 2019-06-20 14:38 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: ath11k
In-Reply-To: <20190620143658.5E811602BC@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Vasanthakumar Thiagarajan <vthiagar@codeaurora.org> wrote:
>
>> Since per_transfer_context is used as an array of skb pointer always
>> no need that to be an array of void *.
>>
>> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@codeaurora.org>
>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>
> 4 patches applied to ath11k-bringup branch of ath.git, thanks.
>
> ac429efcdf8d ath11k: Clean up void *per_transfer_context[] in ce
> 4fd9eee9c2ef ath11k: Add peer.[ch] files for peer related util functions
> 9dff37f3c969 ath11k{dp, hal}: Endian macro related clean ups
> 74971a410d44 ath11k/dp_rx: Clean up void *rx_desc in struct ath11k_skb_rxcb
There were few conflicts. Very easy to resolve with 3-way merge but
please check anyway.
--
Kalle Valo
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply
* Re: [PATCH] drm/bridge: dw-hdmi: Use automatic CTS generation mode when using non-AHB audio
From: Neil Armstrong @ 2019-06-20 14:38 UTC (permalink / raw)
To: a.hajda, Laurent.pinchart
Cc: dri-devel, linux-kernel, Jernej Skrabec, Maxime Ripard,
Jonas Karlman, Heiko Stuebner, Jerome Brunet
In-Reply-To: <20190612085147.26971-1-narmstrong@baylibre.com>
Hi Andrzej,
Gentle ping, do you think this could go in drm-misc-next for 5.3 ?
Thanks,
Neil
On 12/06/2019 10:51, Neil Armstrong wrote:
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on Amlogic, Allwinner and Rockchip SoCs setups.
>
> Setting the CTS in automatic mode will let the HDMI controller generate
> automatically the CTS value to match the input audio clock.
>
> The DesignWare DW-HDMI User Guide explains:
> For Automatic CTS generation
> Write "0" on the bit field "CTS_manual", Register 0x3205: AUD_CTS3
>
> The DesignWare DW-HDMI Databook explains :
> If "CTS_manual" bit equals 0b this registers contains "audCTS[19:0]"
> generated by the Cycle time counter according to specified timing.
>
> Cc: Jernej Skrabec <jernej.skrabec@siol.net>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +++++++++++++++--------
> 1 file changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index c68b6ed1bb35..6458c3a31d23 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -437,8 +437,14 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned int cts,
> /* nshift factor = 0 */
> hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
>
> - hdmi_writeb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> - HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
> + /* Use automatic CTS generation mode when CTS is not set */
> + if (cts)
> + hdmi_writeb(hdmi, ((cts >> 16) &
> + HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> + HDMI_AUD_CTS3_CTS_MANUAL,
> + HDMI_AUD_CTS3);
> + else
> + hdmi_writeb(hdmi, 0, HDMI_AUD_CTS3);
> hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
> hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
>
> @@ -508,24 +514,32 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> {
> unsigned long ftdms = pixel_clk;
> unsigned int n, cts;
> + u8 config3;
> u64 tmp;
>
> n = hdmi_compute_n(sample_rate, pixel_clk);
>
> - /*
> - * Compute the CTS value from the N value. Note that CTS and N
> - * can be up to 20 bits in total, so we need 64-bit math. Also
> - * note that our TDMS clock is not fully accurate; it is accurate
> - * to kHz. This can introduce an unnecessary remainder in the
> - * calculation below, so we don't try to warn about that.
> - */
> - tmp = (u64)ftdms * n;
> - do_div(tmp, 128 * sample_rate);
> - cts = tmp;
> + config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
>
> - dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d cts=%d\n",
> - __func__, sample_rate, ftdms / 1000000, (ftdms / 1000) % 1000,
> - n, cts);
> + /* Only compute CTS when using internal AHB audio */
> + if (config3 & HDMI_CONFIG3_AHBAUDDMA) {
> + /*
> + * Compute the CTS value from the N value. Note that CTS and N
> + * can be up to 20 bits in total, so we need 64-bit math. Also
> + * note that our TDMS clock is not fully accurate; it is
> + * accurate to kHz. This can introduce an unnecessary remainder
> + * in the calculation below, so we don't try to warn about that.
> + */
> + tmp = (u64)ftdms * n;
> + do_div(tmp, 128 * sample_rate);
> + cts = tmp;
> +
> + dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d cts=%d\n",
> + __func__, sample_rate,
> + ftdms / 1000000, (ftdms / 1000) % 1000,
> + n, cts);
> + } else
> + cts = 0;
>
> spin_lock_irq(&hdmi->audio_lock);
> hdmi->audio_n = n;
>
^ permalink raw reply
* [f2fs-dev] [PATCH -next] f2fs: Use div_u64*() for 64-bit divisions
From: Geert Uytterhoeven @ 2019-06-20 14:38 UTC (permalink / raw)
To: Qiuyang Sun, Jaegeuk Kim, Chao Yu
Cc: linux-next, Geert Uytterhoeven, linux-kernel, linux-f2fs-devel
On 32-bit (e.g. m68k):
fs/f2fs/gc.o: In function `f2fs_resize_fs':
gc.c:(.text+0x3056): undefined reference to `__umoddi3'
gc.c:(.text+0x30c4): undefined reference to `__udivdi3'
Fix this by using div_u64_rem() and div_u64() for 64-by-32 modulo resp.
division operations.
Reported-by: noreply@ellerman.id.au
Fixes: d2ae7494d043bfaf ("f2fs: ioctl for removing a range from F2FS")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This assumes BLKS_PER_SEC(sbi) is 32-bit.
#define BLKS_PER_SEC(sbi) \
((sbi)->segs_per_sec * (sbi)->blocks_per_seg)
Notes:
1. f2fs_sb_info.segs_per_sec and f2fs_sb_info.blocks_per_seg are both
unsigned int,
2. The multiplication is done in 32-bit arithmetic, hence the result
is of type unsigned int.
3. Is it guaranteed that the result will always fit in 32-bit, or can
this overflow?
4. fs/f2fs/debug.c:update_sit_info() assigns BLKS_PER_SEC(sbi) to
unsigned long long blks_per_sec, anticipating a 64-bit value.
---
fs/f2fs/gc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 5b1076505ade9f84..c65f87f11de029f4 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1438,13 +1438,15 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
unsigned int secs;
int gc_mode, gc_type;
int err = 0;
+ __u32 rem;
old_block_count = le64_to_cpu(F2FS_RAW_SUPER(sbi)->block_count);
if (block_count > old_block_count)
return -EINVAL;
/* new fs size should align to section size */
- if (block_count % BLKS_PER_SEC(sbi))
+ div_u64_rem(block_count, BLKS_PER_SEC(sbi), &rem);
+ if (rem)
return -EINVAL;
if (block_count == old_block_count)
@@ -1463,7 +1465,7 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
freeze_bdev(sbi->sb->s_bdev);
shrunk_blocks = old_block_count - block_count;
- secs = shrunk_blocks / BLKS_PER_SEC(sbi);
+ secs = div_u64(shrunk_blocks, BLKS_PER_SEC(sbi));
spin_lock(&sbi->stat_lock);
if (shrunk_blocks + valid_user_blocks(sbi) +
sbi->current_reserved_blocks + sbi->unusable_block_count +
--
2.17.1
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply related
* Re: [PATCH] drm/bridge: dw-hdmi: Use automatic CTS generation mode when using non-AHB audio
From: Neil Armstrong @ 2019-06-20 14:38 UTC (permalink / raw)
To: a.hajda, Laurent.pinchart
Cc: Jernej Skrabec, Jonas Karlman, Maxime Ripard, linux-kernel,
dri-devel, Jerome Brunet
In-Reply-To: <20190612085147.26971-1-narmstrong@baylibre.com>
Hi Andrzej,
Gentle ping, do you think this could go in drm-misc-next for 5.3 ?
Thanks,
Neil
On 12/06/2019 10:51, Neil Armstrong wrote:
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on Amlogic, Allwinner and Rockchip SoCs setups.
>
> Setting the CTS in automatic mode will let the HDMI controller generate
> automatically the CTS value to match the input audio clock.
>
> The DesignWare DW-HDMI User Guide explains:
> For Automatic CTS generation
> Write "0" on the bit field "CTS_manual", Register 0x3205: AUD_CTS3
>
> The DesignWare DW-HDMI Databook explains :
> If "CTS_manual" bit equals 0b this registers contains "audCTS[19:0]"
> generated by the Cycle time counter according to specified timing.
>
> Cc: Jernej Skrabec <jernej.skrabec@siol.net>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +++++++++++++++--------
> 1 file changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index c68b6ed1bb35..6458c3a31d23 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -437,8 +437,14 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned int cts,
> /* nshift factor = 0 */
> hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
>
> - hdmi_writeb(hdmi, ((cts >> 16) & HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> - HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
> + /* Use automatic CTS generation mode when CTS is not set */
> + if (cts)
> + hdmi_writeb(hdmi, ((cts >> 16) &
> + HDMI_AUD_CTS3_AUDCTS19_16_MASK) |
> + HDMI_AUD_CTS3_CTS_MANUAL,
> + HDMI_AUD_CTS3);
> + else
> + hdmi_writeb(hdmi, 0, HDMI_AUD_CTS3);
> hdmi_writeb(hdmi, (cts >> 8) & 0xff, HDMI_AUD_CTS2);
> hdmi_writeb(hdmi, cts & 0xff, HDMI_AUD_CTS1);
>
> @@ -508,24 +514,32 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> {
> unsigned long ftdms = pixel_clk;
> unsigned int n, cts;
> + u8 config3;
> u64 tmp;
>
> n = hdmi_compute_n(sample_rate, pixel_clk);
>
> - /*
> - * Compute the CTS value from the N value. Note that CTS and N
> - * can be up to 20 bits in total, so we need 64-bit math. Also
> - * note that our TDMS clock is not fully accurate; it is accurate
> - * to kHz. This can introduce an unnecessary remainder in the
> - * calculation below, so we don't try to warn about that.
> - */
> - tmp = (u64)ftdms * n;
> - do_div(tmp, 128 * sample_rate);
> - cts = tmp;
> + config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
>
> - dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d cts=%d\n",
> - __func__, sample_rate, ftdms / 1000000, (ftdms / 1000) % 1000,
> - n, cts);
> + /* Only compute CTS when using internal AHB audio */
> + if (config3 & HDMI_CONFIG3_AHBAUDDMA) {
> + /*
> + * Compute the CTS value from the N value. Note that CTS and N
> + * can be up to 20 bits in total, so we need 64-bit math. Also
> + * note that our TDMS clock is not fully accurate; it is
> + * accurate to kHz. This can introduce an unnecessary remainder
> + * in the calculation below, so we don't try to warn about that.
> + */
> + tmp = (u64)ftdms * n;
> + do_div(tmp, 128 * sample_rate);
> + cts = tmp;
> +
> + dev_dbg(hdmi->dev, "%s: fs=%uHz ftdms=%lu.%03luMHz N=%d cts=%d\n",
> + __func__, sample_rate,
> + ftdms / 1000000, (ftdms / 1000) % 1000,
> + n, cts);
> + } else
> + cts = 0;
>
> spin_lock_irq(&hdmi->audio_lock);
> hdmi->audio_n = n;
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH -next] f2fs: Use div_u64*() for 64-bit divisions
From: Geert Uytterhoeven @ 2019-06-20 14:38 UTC (permalink / raw)
To: Qiuyang Sun, Jaegeuk Kim, Chao Yu
Cc: linux-f2fs-devel, linux-next, linux-kernel, Geert Uytterhoeven
On 32-bit (e.g. m68k):
fs/f2fs/gc.o: In function `f2fs_resize_fs':
gc.c:(.text+0x3056): undefined reference to `__umoddi3'
gc.c:(.text+0x30c4): undefined reference to `__udivdi3'
Fix this by using div_u64_rem() and div_u64() for 64-by-32 modulo resp.
division operations.
Reported-by: noreply@ellerman.id.au
Fixes: d2ae7494d043bfaf ("f2fs: ioctl for removing a range from F2FS")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This assumes BLKS_PER_SEC(sbi) is 32-bit.
#define BLKS_PER_SEC(sbi) \
((sbi)->segs_per_sec * (sbi)->blocks_per_seg)
Notes:
1. f2fs_sb_info.segs_per_sec and f2fs_sb_info.blocks_per_seg are both
unsigned int,
2. The multiplication is done in 32-bit arithmetic, hence the result
is of type unsigned int.
3. Is it guaranteed that the result will always fit in 32-bit, or can
this overflow?
4. fs/f2fs/debug.c:update_sit_info() assigns BLKS_PER_SEC(sbi) to
unsigned long long blks_per_sec, anticipating a 64-bit value.
---
fs/f2fs/gc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 5b1076505ade9f84..c65f87f11de029f4 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1438,13 +1438,15 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
unsigned int secs;
int gc_mode, gc_type;
int err = 0;
+ __u32 rem;
old_block_count = le64_to_cpu(F2FS_RAW_SUPER(sbi)->block_count);
if (block_count > old_block_count)
return -EINVAL;
/* new fs size should align to section size */
- if (block_count % BLKS_PER_SEC(sbi))
+ div_u64_rem(block_count, BLKS_PER_SEC(sbi), &rem);
+ if (rem)
return -EINVAL;
if (block_count == old_block_count)
@@ -1463,7 +1465,7 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
freeze_bdev(sbi->sb->s_bdev);
shrunk_blocks = old_block_count - block_count;
- secs = shrunk_blocks / BLKS_PER_SEC(sbi);
+ secs = div_u64(shrunk_blocks, BLKS_PER_SEC(sbi));
spin_lock(&sbi->stat_lock);
if (shrunk_blocks + valid_user_blocks(sbi) +
sbi->current_reserved_blocks + sbi->unusable_block_count +
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] ath11k: clean up in htt ppdu stats
From: Kalle Valo @ 2019-06-20 14:37 UTC (permalink / raw)
To: Venkateswara Naralasetty; +Cc: ath11k
In-Reply-To: <1560855918-31801-1-git-send-email-vnaralas@codeaurora.org>
Venkateswara Naralasetty <vnaralas@codeaurora.org> wrote:
> Removed pointer arithmetic and the magic numbers
>
> Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath11k-bringup branch of ath.git, thanks.
6f55fd062ae0 ath11k: clean up in htt ppdu stats
--
https://patchwork.kernel.org/patch/11001383/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply
* Re: [PATCH nft v9]tests: py: fix pyhton3
From: Pablo Neira Ayuso @ 2019-06-20 14:37 UTC (permalink / raw)
To: Shekhar Sharma; +Cc: netfilter-devel
In-Reply-To: <20190619175741.22411-1-shekhar250198@gmail.com>
On Wed, Jun 19, 2019 at 11:27:41PM +0530, Shekhar Sharma wrote:
> This patch changes the file to run on both python2 and python3.
>
> The tempfile module has been imported and used.
> Although the previous replacement of cmp() by eric works,
> I have replaced cmp(a,b) by ((a>b)-(a<b)) which works correctly.
Any reason not to use Eric's approach? This ((a>b)-(a<b)) is
confusing.
> Thanks!
BTW, strictly place your patch description here.
Things like "Thanks!" to someone specifically and the cmp()
explanation should go below the --- marker, like versioning.
BTW, Cc Eric Garver in your patches, he's helping us with reviewing :-)
^ permalink raw reply
* [PATCH v7 3/5] arm64: dts: qcom: Add Lenovo Miix 630
From: Jeffrey Hugo @ 2019-06-20 14:37 UTC (permalink / raw)
To: bjorn.andersson, agross
Cc: benjamin.tissoires, dmitry.torokhov, jikos, hdegoede, lee.jones,
xnox, robh+dt, mark.rutland, linux-input, devicetree,
linux-arm-msm, linux-kernel, Jeffrey Hugo
In-Reply-To: <20190620142801.11827-1-jeffrey.l.hugo@gmail.com>
This adds the initial DT for the Lenovo Miix 630 laptop. Supported
functionality includes USB (host), microSD-card, keyboard, and trackpad.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/msm8998-clamshell.dtsi | 240 ++++++++++++++++++
.../boot/dts/qcom/msm8998-lenovo-miix-630.dts | 30 +++
3 files changed, 271 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 21d548f02d39..c3e4307bcbd4 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8998-lenovo-miix-630.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8998-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
new file mode 100644
index 000000000000..9682d4dd7496
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
+
+/*
+ * Common include for MSM8998 clamshell devices, ie the Lenovo Miix 630,
+ * Asus NovaGo TP370QL, and HP Envy x2. All three devices are basically the
+ * same, with differences in peripherals.
+ */
+
+#include "msm8998.dtsi"
+#include "pm8998.dtsi"
+#include "pm8005.dtsi"
+
+/ {
+ chosen {
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&qusb2phy {
+ status = "okay";
+
+ vdda-pll-supply = <&vreg_l12a_1p8>;
+ vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
+};
+
+&rpm_requests {
+ pm8998-regulators {
+ compatible = "qcom,rpm-pm8998-regulators";
+
+ vdd_s1-supply = <&vph_pwr>;
+ vdd_s2-supply = <&vph_pwr>;
+ vdd_s3-supply = <&vph_pwr>;
+ vdd_s4-supply = <&vph_pwr>;
+ vdd_s5-supply = <&vph_pwr>;
+ vdd_s6-supply = <&vph_pwr>;
+ vdd_s7-supply = <&vph_pwr>;
+ vdd_s8-supply = <&vph_pwr>;
+ vdd_s9-supply = <&vph_pwr>;
+ vdd_s10-supply = <&vph_pwr>;
+ vdd_s11-supply = <&vph_pwr>;
+ vdd_s12-supply = <&vph_pwr>;
+ vdd_s13-supply = <&vph_pwr>;
+ vdd_l1_l27-supply = <&vreg_s7a_1p025>;
+ vdd_l2_l8_l17-supply = <&vreg_s3a_1p35>;
+ vdd_l3_l11-supply = <&vreg_s7a_1p025>;
+ vdd_l4_l5-supply = <&vreg_s7a_1p025>;
+ vdd_l6-supply = <&vreg_s5a_2p04>;
+ vdd_l7_l12_l14_l15-supply = <&vreg_s5a_2p04>;
+ vdd_l9-supply = <&vph_pwr>;
+ vdd_l10_l23_l25-supply = <&vph_pwr>;
+ vdd_l13_l19_l21-supply = <&vph_pwr>;
+ vdd_l16_l28-supply = <&vph_pwr>;
+ vdd_l18_l22-supply = <&vph_pwr>;
+ vdd_l20_l24-supply = <&vph_pwr>;
+ vdd_l26-supply = <&vreg_s3a_1p35>;
+ vdd_lvs1_lvs2-supply = <&vreg_s4a_1p8>;
+
+ vreg_s3a_1p35: s3 {
+ regulator-min-microvolt = <1352000>;
+ regulator-max-microvolt = <1352000>;
+ };
+ vreg_s4a_1p8: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allow-set-load;
+ };
+ vreg_s5a_2p04: s5 {
+ regulator-min-microvolt = <1904000>;
+ regulator-max-microvolt = <2040000>;
+ };
+ vreg_s7a_1p025: s7 {
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1028000>;
+ };
+ vreg_l1a_0p875: l1 {
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-allow-set-load;
+ };
+ vreg_l2a_1p2: l2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-allow-set-load;
+ };
+ vreg_l3a_1p0: l3 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ };
+ vreg_l5a_0p8: l5 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ };
+ vreg_l6a_1p8: l6 {
+ regulator-min-microvolt = <1808000>;
+ regulator-max-microvolt = <1808000>;
+ };
+ vreg_l7a_1p8: l7 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ vreg_l8a_1p2: l8 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ vreg_l9a_1p8: l9 {
+ regulator-min-microvolt = <1808000>;
+ regulator-max-microvolt = <2960000>;
+ };
+ vreg_l10a_1p8: l10 {
+ regulator-min-microvolt = <1808000>;
+ regulator-max-microvolt = <2960000>;
+ };
+ vreg_l11a_1p0: l11 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ };
+ vreg_l12a_1p8: l12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ vreg_l13a_2p95: l13 {
+ regulator-min-microvolt = <1808000>;
+ regulator-max-microvolt = <2960000>;
+ };
+ vreg_l14a_1p88: l14 {
+ regulator-min-microvolt = <1880000>;
+ regulator-max-microvolt = <1880000>;
+ };
+ vreg_15a_1p8: l15 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ vreg_l16a_2p7: l16 {
+ regulator-min-microvolt = <2704000>;
+ regulator-max-microvolt = <2704000>;
+ };
+ vreg_l17a_1p3: l17 {
+ regulator-min-microvolt = <1304000>;
+ regulator-max-microvolt = <1304000>;
+ };
+ vreg_l18a_2p7: l18 {
+ regulator-min-microvolt = <2704000>;
+ regulator-max-microvolt = <2704000>;
+ };
+ vreg_l19a_3p0: l19 {
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3008000>;
+ };
+ vreg_l20a_2p95: l20 {
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-allow-set-load;
+ };
+ vreg_l21a_2p95: l21 {
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-allow-set-load;
+ regulator-system-load = <800000>;
+ };
+ vreg_l22a_2p85: l22 {
+ regulator-min-microvolt = <2864000>;
+ regulator-max-microvolt = <2864000>;
+ };
+ vreg_l23a_3p3: l23 {
+ regulator-min-microvolt = <3312000>;
+ regulator-max-microvolt = <3312000>;
+ };
+ vreg_l24a_3p075: l24 {
+ regulator-min-microvolt = <3088000>;
+ regulator-max-microvolt = <3088000>;
+ };
+ vreg_l25a_3p3: l25 {
+ regulator-min-microvolt = <3104000>;
+ regulator-max-microvolt = <3312000>;
+ };
+ vreg_l26a_1p2: l26 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ vreg_l28_3p0: l28 {
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3008000>;
+ };
+
+ vreg_lvs1a_1p8: lvs1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vreg_lvs2a_1p8: lvs2 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ };
+};
+
+&tlmm {
+ gpio-reserved-ranges = <0 4>, <81 4>;
+
+ touchpad: touchpad {
+ config {
+ pins = "gpio123";
+ bias-pull-up; /* pull up */
+ };
+ };
+};
+
+&sdhc2 {
+ status = "okay";
+
+ vmmc-supply = <&vreg_l21a_2p95>;
+ vqmmc-supply = <&vreg_l13a_2p95>;
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
+ pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off &sdc2_cd_off>;
+};
+
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ dr_mode = "host"; /* Force to host until we have Type-C hooked up */
+};
+
+&usb3phy {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l2a_1p2>;
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
new file mode 100644
index 000000000000..407c6a32911c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
+
+/dts-v1/;
+
+#include "msm8998-clamshell.dtsi"
+
+/ {
+ model = "Lenovo Miix 630";
+ compatible = "lenovo,miix-630", "qcom,msm8998";
+};
+
+&blsp1_i2c6 {
+ status = "okay";
+
+ keyboard@3a {
+ compatible = "hid-over-i2c";
+ interrupt-parent = <&tlmm>;
+ interrupts = <0x79 IRQ_TYPE_LEVEL_LOW>;
+ reg = <0x3a>;
+ hid-descr-addr = <0x0001>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&touchpad>;
+ };
+};
+
+&sdhc2 {
+ cd-gpios = <&tlmm 95 GPIO_ACTIVE_HIGH>;
+};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V2 1/4] ath11k: Clean up void *per_transfer_context[] in ce
From: Kalle Valo @ 2019-06-20 14:36 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: ath11k
In-Reply-To: <1561022229-854-1-git-send-email-vthiagar@codeaurora.org>
Vasanthakumar Thiagarajan <vthiagar@codeaurora.org> wrote:
> Since per_transfer_context is used as an array of skb pointer always
> no need that to be an array of void *.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
4 patches applied to ath11k-bringup branch of ath.git, thanks.
ac429efcdf8d ath11k: Clean up void *per_transfer_context[] in ce
4fd9eee9c2ef ath11k: Add peer.[ch] files for peer related util functions
9dff37f3c969 ath11k{dp, hal}: Endian macro related clean ups
74971a410d44 ath11k/dp_rx: Clean up void *rx_desc in struct ath11k_skb_rxcb
--
https://patchwork.kernel.org/patch/11006239/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply
* [Buildroot] [PATCH 24/27] package/tvheadend: re-enable package on microblaze
From: Thomas Petazzoni @ 2019-06-20 14:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190614210346.121013-25-giulio.benetti@micronovasrl.com>
On Fri, 14 Jun 2019 23:03:43 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
> Package tvheadend has been disabled on microblaze with this commit:
> https://git.buildroot.net/buildroot/commit/?id=e1a59357e4dfe8fe9c9119d4b2bc9e4ec36eb3d0
> but commit log says that build failure is due to "some assertion
> failure in binutils", that is true. But those assertion failures in
> binutils are caused by package's Makefile itself that has been fixed by
> previous patch. So re-enable package for microblaze.
>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> package/tvheadend/Config.in | 2 --
> 1 file changed, 2 deletions(-)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [Buildroot] [PATCH 23/27] package/tvheadend: fix PIE build failures
From: Thomas Petazzoni @ 2019-06-20 14:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190614210346.121013-24-giulio.benetti@micronovasrl.com>
On Fri, 14 Jun 2019 23:03:42 +0200
Giulio Benetti <giulio.benetti@micronovasrl.com> wrote:
> Package tvheadend builds using '-pie' linker flag in any case. This
> leads to linking failure if toolchain doesn't support 'pie'.
>
> Add patch to fix tvheadend's Makefile bug where '-pie' flag is hardcoded
> making it depend on '--disable-pie' as compiler's flags already are
> treated.
>
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> ---
> ...pie-linking-according-to-disable-pie.patch | 34 +++++++++++++++++++
> package/tvheadend/tvheadend.mk | 4 +++
> 2 files changed, 38 insertions(+)
> create mode 100644 package/tvheadend/0002-Makefile-fix-pie-linking-according-to-disable-pie.patch
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [Buildroot] [git commit] package/tvheadend: re-enable package on microblaze
From: Thomas Petazzoni @ 2019-06-20 14:36 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=a2cee5037f9a7dcb732c7cddb873537dae718068
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Package tvheadend has been disabled on microblaze with this commit:
https://git.buildroot.net/buildroot/commit/?id=e1a59357e4dfe8fe9c9119d4b2bc9e4ec36eb3d0
but commit log says that build failure is due to "some assertion
failure in binutils", that is true. But those assertion failures in
binutils are caused by package's Makefile itself that has been fixed by
previous patch. So re-enable package for microblaze.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/tvheadend/Config.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/package/tvheadend/Config.in b/package/tvheadend/Config.in
index 5db644400c..909d955c02 100644
--- a/package/tvheadend/Config.in
+++ b/package/tvheadend/Config.in
@@ -1,12 +1,10 @@
comment "tvheadend needs a toolchain w/ NPTL, headers >= 3.2, dynamic library"
- depends on !BR2_microblazeel
depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL || \
!BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2 || BR2_STATIC_LIBS
depends on BR2_TOOLCHAIN_HAS_SYNC_4
config BR2_PACKAGE_TVHEADEND
bool "tvheadend"
- depends on !BR2_microblazeel # assertion failure in binutils
depends on !BR2_STATIC_LIBS # dladdr()
depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.