lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 1 Feb 2021 10:29:44 -0600 From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com> To: Vinod Koul <vkoul@...nel.org>, Bard Liao <yung-chuan.liao@...ux.intel.com> Cc: alsa-devel@...a-project.org, linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org, jank@...ence.com, srinivas.kandagatla@...aro.org, rander.wang@...ux.intel.com, ranjani.sridharan@...ux.intel.com, hui.wang@...onical.com, sanyog.r.kale@...el.com, bard.liao@...el.com Subject: Re: [PATCH 3/3] soundwire: bus: clear parity interrupt before the mask is enabled >> * Set SCP_INT1_MASK register, typically bus clash and >> diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c >> index f7ba1a77a1df..c1fdc85d0a74 100644 >> --- a/drivers/soundwire/intel.c >> +++ b/drivers/soundwire/intel.c >> @@ -1286,7 +1286,8 @@ static int sdw_master_read_intel_prop(struct sdw_bus *bus) >> if (quirk_mask & SDW_INTEL_QUIRK_MASK_BUS_DISABLE) >> prop->hw_disabled = true; >> >> - prop->quirks = SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH; >> + prop->quirks = SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH | >> + SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY; > > move this to intel patch please.. > >> >> return 0; >> } >> diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h >> index a2766c3b603d..30415354d419 100644 >> --- a/include/linux/soundwire/sdw.h >> +++ b/include/linux/soundwire/sdw.h >> @@ -426,6 +426,7 @@ struct sdw_master_prop { >> }; >> >> #define SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH BIT(0) >> +#define SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY BIT(1) > > Why not add this quirk in patch 1..? There is an element of history here. We first found out about the bus clash on multiple devices and dealt with a specific bug number. Then we spend weeks on the parity issue on a new platform and ultimately showed we needed a similar work-around. All these problems are not typical from a user perspective; they appear when loading/unloading modules in loops, at some point it seems some hardware devices don't always reset properly or there's something problematic in power delivery. I don't think it's an issue if we refactor the code to add the quirks first, and add the intel.c patches later. We probably want 2 intel changes to keep the references to the bugs though and the detailed explanations. > Also add comments about each quirk, hopefully it wont be a big table Sounds fine.
Powered by blists - more mailing lists