* [PATCH v2] KVM: arm/arm64: vgic: Prevent access to invalid SPIs
From: Marc Zyngier @ 2016-11-01 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031172137.30807-1-andre.przywara@arm.com>
Hi Andre,
On Mon, Oct 31 2016 at 05:21:37 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> In our VGIC implementation we limit the number of SPIs to a number
> that the userland application told us. Accordingly we limit the
> allocation of memory for virtual IRQs to that number.
> However in our MMIO dispatcher we didn't check if we ever access an
> IRQ beyond that limit, leading to out-of-bound accesses.
> Add a test against the number of allocated SPIs in check_region().
> Adjust the VGIC_ADDR_TO_INTID macro to avoid an actual division, which
> is not implemented on ARM(32).
>
> [maz: cleaned-up original patch]
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Hi Marc,
>
> does the last hunk fix the GCC issue that your recent fix addresses
> as well? ilog2 seems to be pretty cheap on ARM and ARM64, so I wonder
> if this version of the fix is better, since smaller?
Thanks for looking into this. That seems to solve it for me (with GCC
6.1.1).
[...]
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
> index 4c34d39..dacd1155 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.h
> +++ b/virt/kvm/arm/vgic/vgic-mmio.h
> @@ -58,7 +58,7 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
> * numerator and denominator with 8 to support at most 64 bits per IRQ:
> */
> #define VGIC_ADDR_TO_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * \
> - 64 / (bits) / 8)
> + 64 >> (ilog2(bits) + 3))
Given that it's taken me the best of 10 minutes to convince myself that
this was correct, can you please save everybody some time by updating
the comment above the #define?
Please respin this as soon as you can.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.9
From: Fabio Estevam @ 2016-10-31 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhSHqs_WfxkdUn7yrT_9g1CO1cqXGzQ2Y1Y-+-tY1KNmw@mail.gmail.com>
Hi Olof,
On Mon, Oct 31, 2016 at 8:39 PM, Olof Johansson <olof@lixom.net> wrote:
> Fabio,
>
> I've got multi_v7 booting now, but imx_v6_v7 is still broken on both
> hummingboard and wandboard.
>
> Hummingboard doesn't even output anything on serial during boot, bug
> with DEBUG_LL I got some more info
>
> (No output boot at
> http://arm-soc.lixom.net/bootlogs/mainline/v4.9-rc3/hummingboard-arm-imx_v6_v7_defconfig.html,
> not very useful).
>
> This one seems to be due to CONFIG_PCI_IMX6, which is off on
> multi_v7_defconfig. Hard hang(?), last output is:
>
> [ 0.490643] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
> [ 0.496540] OF: PCI: No bus range found for /soc/pcie at 0x01000000,
> using [bus 00-ff]
> [ 0.504512] OF: PCI: IO 0x01f80000..0x01f8ffff -> 0x00000000
> [ 0.510559] OF: PCI: MEM 0x01000000..0x01efffff -> 0x01000000
>
I think this will be fixed with this pcie-designware patch:
http://www.spinics.net/lists/linux-pci/msg55244.html
> Wandboard, has a peculiar MMC error. First I thought it was just the
> card going bad, but now I'm not so sure since multi_v7 boots just fine
> on the same hardware:
Yes, I have been noticing this mmc error reported in your autobooter
and I also thought it was some kind of a bad SD card.
This particular error I have never been able to reproduce. Also
checked kernelci and do not see this mmc error there.
Interesting that it happens only with imx_v6_v7_defconfig and not with
multi_v7_defconfig.
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Stephen Boyd @ 2016-10-31 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXA-hemOT=ZysEfettei9=HsDddGhqddkw38hwRrdeagw@mail.gmail.com>
On 10/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen, Arnd, Olof, Kevin,
>
> Is the merge strategy [see ##### below] OK for you?
> Thanks a lot!
>
> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> >> <geert+renesas@glider.be> wrote:
> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> >> > state of the mode pins either by a call from the platform code, or
> >> > directly by using a hardcoded register access. This is a bit messy, and
> >> > creates a dependency between driver and platform code.
> >> >
> >> > This patch series converts the various Renesas R-Car clock drivers
> >> > and support code from reading the mode pin states using a hardcoded
> >> > register access to using a new minimalistic R-Car RST driver.
> >> >
> >> > All R-Car clock drivers will rely on the presence in DT of a device node
> >> > for the RST module. Backwards compatibility with old DTBs is retained
> >> > only for R-Car Gen2, which has fallback code using its own private copy
> >> > of rcar_gen2_read_mode_pins().
> >> >
> >> > After this, there is still one remaining user of
> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >> >
> >> > This series consists of 5 parts:
> >> > A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >> > driver,
> >> > B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >> > files,
> >> > C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >> > RST driver,
> >> > D. Patches 18-20 remove passing mode pin state to the clock drivers
> >> > from the platform code,
> >> > E. Patches 21-23 remove dead code from the clock drivers.
> >> >
> >> > As is usually the case with moving functionality from platform code to
> >> > DT, there are lots of hard dependencies:
> >> > - The DT updates in Part B can be merged as soon as the DT bindings in
> >> > Part A have been approved,
> >> > - The clock driver updates in Part C depend functionally on the driver
> >> > code in Part A, and on the DT updates in Part B,
> >> > - The board code cleanups in Part D depend on the clock driver updates
> >> > in Part C,
> >> > - The block driver cleanups in part E depend on the board code
> >> > cleanups in part D.
> >> >
> >> > Hence to maintain the required lockstep between SoC driver, clock
> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> >> > all patches in a single branch against v4.9-rc1, and send pull requests
> >> > to both Mike/Stephen (clock) and Simon (rest).
> >> >
> >> > ***
> >>
> >> > - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >> > approach above?
> >>
> >> Is this OK for you?
>
> #####
>
> (link to the full series at
> https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)
Would the pull requests for clk also have dts changes at the base
of the tree? Perhaps clk side can just ack the clk patches and
then have it all routed through arm-soc? The only worry I have is
if we need to make some sort of change in clk side that conflicts
with these changes. I don't usually like taking dts changes
through clk tree, so I'd like to avoid that if possible.
Part E could happen anytime after everything else happens, so
that doesn't seem like a concern. Part C could also be made to
only call into the new reset drivers if the reset dts nodes are
present? If that's done then we could merge clk patches anytime
and remove the dead code and the node search at some later time
when everything has settled?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [rjarzmik:work/ac97 15/15] sound/ac97/bus.c:285:5: error: redefinition of 'snd_ac97_controller_register'
From: kbuild test robot @ 2016-10-31 23:04 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/rjarzmik/linux work/ac97
head: 84dce0ccc786a2af4266cb85cab983abf4c53a91
commit: 84dce0ccc786a2af4266cb85cab983abf4c53a91 [15/15] ASoC: pxa: switch to new ac97 bus support
config: arm-em_x270_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 84dce0ccc786a2af4266cb85cab983abf4c53a91
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
>> sound/ac97/bus.c:168:5: error: redefinition of 'snd_ac97_codec_driver_register'
int snd_ac97_codec_driver_register(struct ac97_codec_driver *drv)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from sound/ac97/bus.c:19:0:
include/sound/ac97/codec.h:85:1: note: previous definition of 'snd_ac97_codec_driver_register' was here
snd_ac97_codec_driver_register(struct ac97_codec_driver *drv)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/ac97/bus.c:188:6: error: redefinition of 'snd_ac97_codec_driver_unregister'
void snd_ac97_codec_driver_unregister(struct ac97_codec_driver *drv)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from sound/ac97/bus.c:19:0:
include/sound/ac97/codec.h:90:1: note: previous definition of 'snd_ac97_codec_driver_unregister' was here
snd_ac97_codec_driver_unregister(struct ac97_codec_driver *drv)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/ac97/bus.c:285:5: error: redefinition of 'snd_ac97_controller_register'
int snd_ac97_controller_register(const struct ac97_controller_ops *ops,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from sound/ac97/bus.c:20:0:
include/sound/ac97/controller.h:71:1: note: previous definition of 'snd_ac97_controller_register' was here
snd_ac97_controller_register(const struct ac97_controller_ops *ops,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/ac97/bus.c:324:5: error: redefinition of 'snd_ac97_controller_unregister'
int snd_ac97_controller_unregister(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from sound/ac97/bus.c:20:0:
include/sound/ac97/controller.h:79:19: note: previous definition of 'snd_ac97_controller_unregister' was here
static inline int snd_ac97_controller_unregister(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
sound/soc/codecs/wm9712.c: In function 'ac97_read':
sound/soc/codecs/wm9712.c:497:10: error: 'soc_ac97_ops' undeclared (first use in this function)
return soc_ac97_ops->read(wm9712->ac97, reg);
^~~~~~~~~~~~
sound/soc/codecs/wm9712.c:497:10: note: each undeclared identifier is reported only once for each function it appears in
sound/soc/codecs/wm9712.c: In function 'ac97_write':
sound/soc/codecs/wm9712.c:514:2: error: 'soc_ac97_ops' undeclared (first use in this function)
soc_ac97_ops->write(wm9712->ac97, reg, val);
^~~~~~~~~~~~
sound/soc/codecs/wm9712.c: In function 'wm9712_soc_resume':
sound/soc/codecs/wm9712.c:638:4: error: 'soc_ac97_ops' undeclared (first use in this function)
soc_ac97_ops->write(wm9712->ac97, i, cache[i>>1]);
^~~~~~~~~~~~
sound/soc/codecs/wm9712.c: In function 'wm9712_soc_probe':
>> sound/soc/codecs/wm9712.c:650:17: error: implicit declaration of function 'snd_soc_new_ac97_codec' [-Werror=implicit-function-declaration]
wm9712->ac97 = snd_soc_new_ac97_codec(codec, WM9712_VENDOR_ID,
^~~~~~~~~~~~~~~~~~~~~~
>> sound/soc/codecs/wm9712.c:650:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
wm9712->ac97 = snd_soc_new_ac97_codec(codec, WM9712_VENDOR_ID,
^
sound/soc/codecs/wm9712.c: In function 'wm9712_soc_remove':
>> sound/soc/codecs/wm9712.c:668:2: error: implicit declaration of function 'snd_soc_free_ac97_codec' [-Werror=implicit-function-declaration]
snd_soc_free_ac97_codec(wm9712->ac97);
^~~~~~~~~~~~~~~~~~~~~~~
sound/soc/codecs/wm9712.c: In function 'ac97_read':
sound/soc/codecs/wm9712.c:506:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
cc1: some warnings being treated as errors
vim +/snd_ac97_controller_register +285 sound/ac97/bus.c
92c123dd Robert Jarzmik 2016-04-16 162 *
92c123dd Robert Jarzmik 2016-04-16 163 * Register an AC97 codec driver to the ac97 bus driver, aka. the AC97 digital
92c123dd Robert Jarzmik 2016-04-16 164 * controller.
92c123dd Robert Jarzmik 2016-04-16 165 *
92c123dd Robert Jarzmik 2016-04-16 166 * Returns 0 on success or error code
92c123dd Robert Jarzmik 2016-04-16 167 */
92c123dd Robert Jarzmik 2016-04-16 @168 int snd_ac97_codec_driver_register(struct ac97_codec_driver *drv)
92c123dd Robert Jarzmik 2016-04-16 169 {
92c123dd Robert Jarzmik 2016-04-16 170 int ret;
92c123dd Robert Jarzmik 2016-04-16 171
92c123dd Robert Jarzmik 2016-04-16 172 drv->driver.bus = &ac97_bus_type;
92c123dd Robert Jarzmik 2016-04-16 173
92c123dd Robert Jarzmik 2016-04-16 174 ret = driver_register(&drv->driver);
92c123dd Robert Jarzmik 2016-04-16 175 if (!ret)
92c123dd Robert Jarzmik 2016-04-16 176 ac97_rescan_all_controllers();
92c123dd Robert Jarzmik 2016-04-16 177
92c123dd Robert Jarzmik 2016-04-16 178 return ret;
92c123dd Robert Jarzmik 2016-04-16 179 }
92c123dd Robert Jarzmik 2016-04-16 180 EXPORT_SYMBOL(snd_ac97_codec_driver_register);
92c123dd Robert Jarzmik 2016-04-16 181
92c123dd Robert Jarzmik 2016-04-16 182 /**
92c123dd Robert Jarzmik 2016-04-16 183 * snd_ac97_codec_driver_unregister - unregister an AC97 codec driver
92c123dd Robert Jarzmik 2016-04-16 184 * @dev: AC97 codec driver to unregister
92c123dd Robert Jarzmik 2016-04-16 185 *
92c123dd Robert Jarzmik 2016-04-16 186 * Unregister a previously registered ac97 codec driver.
92c123dd Robert Jarzmik 2016-04-16 187 */
92c123dd Robert Jarzmik 2016-04-16 @188 void snd_ac97_codec_driver_unregister(struct ac97_codec_driver *drv)
92c123dd Robert Jarzmik 2016-04-16 189 {
92c123dd Robert Jarzmik 2016-04-16 190 driver_unregister(&drv->driver);
92c123dd Robert Jarzmik 2016-04-16 191 }
92c123dd Robert Jarzmik 2016-04-16 192 EXPORT_SYMBOL(snd_ac97_codec_driver_unregister);
92c123dd Robert Jarzmik 2016-04-16 193
92c123dd Robert Jarzmik 2016-04-16 194 /**
92c123dd Robert Jarzmik 2016-04-16 195 * snd_ac97_codec_get_platdata - get platform_data
92c123dd Robert Jarzmik 2016-04-16 196 * @adev: the ac97 codec device
92c123dd Robert Jarzmik 2016-04-16 197 *
92c123dd Robert Jarzmik 2016-04-16 198 * For legacy platforms, in order to have platform_data in codec drivers
92c123dd Robert Jarzmik 2016-04-16 199 * available, while ac97 device are auto-created upon probe, this retrieves the
92c123dd Robert Jarzmik 2016-04-16 200 * platdata which was setup on ac97 controller registration.
92c123dd Robert Jarzmik 2016-04-16 201 *
92c123dd Robert Jarzmik 2016-04-16 202 * Returns the platform data pointer
92c123dd Robert Jarzmik 2016-04-16 203 */
92c123dd Robert Jarzmik 2016-04-16 204 void *snd_ac97_codec_get_platdata(const struct ac97_codec_device *adev)
92c123dd Robert Jarzmik 2016-04-16 205 {
92c123dd Robert Jarzmik 2016-04-16 206 struct ac97_controller *ac97_ctrl = adev->ac97_ctrl;
92c123dd Robert Jarzmik 2016-04-16 207
92c123dd Robert Jarzmik 2016-04-16 208 return ac97_ctrl->codecs_pdata[adev->num];
92c123dd Robert Jarzmik 2016-04-16 209 }
92c123dd Robert Jarzmik 2016-04-16 210 EXPORT_SYMBOL(snd_ac97_codec_get_platdata);
92c123dd Robert Jarzmik 2016-04-16 211
92c123dd Robert Jarzmik 2016-04-16 212 static struct ac97_controller *ac97_ctrl_find(struct device *dev)
92c123dd Robert Jarzmik 2016-04-16 213 {
92c123dd Robert Jarzmik 2016-04-16 214 struct ac97_controller *ac97_ctrl, *tmp;
92c123dd Robert Jarzmik 2016-04-16 215
92c123dd Robert Jarzmik 2016-04-16 216 list_for_each_entry_safe(ac97_ctrl, tmp, &ac97_controllers,
92c123dd Robert Jarzmik 2016-04-16 217 controllers)
92c123dd Robert Jarzmik 2016-04-16 218 if (ac97_ctrl->dev == dev)
92c123dd Robert Jarzmik 2016-04-16 219 return ac97_ctrl;
92c123dd Robert Jarzmik 2016-04-16 220
92c123dd Robert Jarzmik 2016-04-16 221 return NULL;
92c123dd Robert Jarzmik 2016-04-16 222 }
92c123dd Robert Jarzmik 2016-04-16 223 static int ac97_ctrl_codecs_unregister(struct ac97_controller *ac97_ctrl)
92c123dd Robert Jarzmik 2016-04-16 224 {
92c123dd Robert Jarzmik 2016-04-16 225 int i;
92c123dd Robert Jarzmik 2016-04-16 226
92c123dd Robert Jarzmik 2016-04-16 227 for (i = 0; i < AC97_BUS_MAX_CODECS; i++)
92c123dd Robert Jarzmik 2016-04-16 228 if (ac97_ctrl->codecs[i])
92c123dd Robert Jarzmik 2016-04-16 229 put_device(&ac97_ctrl->codecs[i]->dev);
92c123dd Robert Jarzmik 2016-04-16 230
92c123dd Robert Jarzmik 2016-04-16 231 return 0;
92c123dd Robert Jarzmik 2016-04-16 232 }
92c123dd Robert Jarzmik 2016-04-16 233
92c123dd Robert Jarzmik 2016-04-16 234 static ssize_t cold_reset_store(struct device *dev,
92c123dd Robert Jarzmik 2016-04-16 235 struct device_attribute *attr, const char *buf,
92c123dd Robert Jarzmik 2016-04-16 236 size_t len)
92c123dd Robert Jarzmik 2016-04-16 237 {
92c123dd Robert Jarzmik 2016-04-16 238 struct ac97_controller *ac97_ctrl = ac97_ctrl_find(dev);
92c123dd Robert Jarzmik 2016-04-16 239
92c123dd Robert Jarzmik 2016-04-16 240 if (!dev)
92c123dd Robert Jarzmik 2016-04-16 241 return -ENODEV;
92c123dd Robert Jarzmik 2016-04-16 242
92c123dd Robert Jarzmik 2016-04-16 243 ac97_ctrl->ops->reset(ac97_ctrl);
92c123dd Robert Jarzmik 2016-04-16 244 return len;
92c123dd Robert Jarzmik 2016-04-16 245 }
92c123dd Robert Jarzmik 2016-04-16 246 static DEVICE_ATTR_WO(cold_reset);
92c123dd Robert Jarzmik 2016-04-16 247
92c123dd Robert Jarzmik 2016-04-16 248 static ssize_t warm_reset_store(struct device *dev,
92c123dd Robert Jarzmik 2016-04-16 249 struct device_attribute *attr, const char *buf,
92c123dd Robert Jarzmik 2016-04-16 250 size_t len)
92c123dd Robert Jarzmik 2016-04-16 251 {
92c123dd Robert Jarzmik 2016-04-16 252 struct ac97_controller *ac97_ctrl = ac97_ctrl_find(dev);
92c123dd Robert Jarzmik 2016-04-16 253
92c123dd Robert Jarzmik 2016-04-16 254 if (!dev)
92c123dd Robert Jarzmik 2016-04-16 255 return -ENODEV;
92c123dd Robert Jarzmik 2016-04-16 256
92c123dd Robert Jarzmik 2016-04-16 257 ac97_ctrl->ops->warm_reset(ac97_ctrl);
92c123dd Robert Jarzmik 2016-04-16 258 return len;
92c123dd Robert Jarzmik 2016-04-16 259 }
92c123dd Robert Jarzmik 2016-04-16 260 static DEVICE_ATTR_WO(warm_reset);
92c123dd Robert Jarzmik 2016-04-16 261
92c123dd Robert Jarzmik 2016-04-16 262 static struct attribute *ac97_controller_device_attrs[] = {
92c123dd Robert Jarzmik 2016-04-16 263 &dev_attr_cold_reset.attr,
92c123dd Robert Jarzmik 2016-04-16 264 &dev_attr_warm_reset.attr,
92c123dd Robert Jarzmik 2016-04-16 265 NULL
92c123dd Robert Jarzmik 2016-04-16 266 };
92c123dd Robert Jarzmik 2016-04-16 267
92c123dd Robert Jarzmik 2016-04-16 268 static const struct attribute_group ac97_controller_attr_group = {
92c123dd Robert Jarzmik 2016-04-16 269 .name = "ac97_operations",
92c123dd Robert Jarzmik 2016-04-16 270 .attrs = ac97_controller_device_attrs,
92c123dd Robert Jarzmik 2016-04-16 271 };
92c123dd Robert Jarzmik 2016-04-16 272
92c123dd Robert Jarzmik 2016-04-16 273 /**
92c123dd Robert Jarzmik 2016-04-16 274 * snd_ac97_controller_register - register an ac97 controller
92c123dd Robert Jarzmik 2016-04-16 275 * @ops: the ac97 bus operations
92c123dd Robert Jarzmik 2016-04-16 276 * @dev: the device providing the ac97 DC function
92c123dd Robert Jarzmik 2016-04-16 277 * @slots_available: mask of the ac97 codecs that can be scanned and probed
92c123dd Robert Jarzmik 2016-04-16 278 * bit0 => codec 0, bit1 => codec 1 ... bit 3 => codec 3
92c123dd Robert Jarzmik 2016-04-16 279 *
92c123dd Robert Jarzmik 2016-04-16 280 * Register a digital controller which can control up to 4 ac97 codecs. This is
92c123dd Robert Jarzmik 2016-04-16 281 * the controller side of the AC97 AC-link, while the slave side are the codecs.
92c123dd Robert Jarzmik 2016-04-16 282 *
92c123dd Robert Jarzmik 2016-04-16 283 * Returns 0 upon success, negative value upon error
92c123dd Robert Jarzmik 2016-04-16 284 */
92c123dd Robert Jarzmik 2016-04-16 @285 int snd_ac97_controller_register(const struct ac97_controller_ops *ops,
92c123dd Robert Jarzmik 2016-04-16 286 struct device *dev,
92c123dd Robert Jarzmik 2016-04-16 287 unsigned short slots_available,
92c123dd Robert Jarzmik 2016-04-16 288 void **codecs_pdata)
92c123dd Robert Jarzmik 2016-04-16 289 {
92c123dd Robert Jarzmik 2016-04-16 290 struct ac97_controller *ac97_ctrl;
92c123dd Robert Jarzmik 2016-04-16 291 int ret, i;
92c123dd Robert Jarzmik 2016-04-16 292
92c123dd Robert Jarzmik 2016-04-16 293 ac97_ctrl = kzalloc(sizeof(*ac97_ctrl), GFP_KERNEL);
92c123dd Robert Jarzmik 2016-04-16 294 if (!ac97_ctrl)
92c123dd Robert Jarzmik 2016-04-16 295 return -ENOMEM;
92c123dd Robert Jarzmik 2016-04-16 296
92c123dd Robert Jarzmik 2016-04-16 297 for (i = 0; i < AC97_BUS_MAX_CODECS && codecs_pdata; i++)
92c123dd Robert Jarzmik 2016-04-16 298 ac97_ctrl->codecs_pdata[i] = codecs_pdata[i];
92c123dd Robert Jarzmik 2016-04-16 299
92c123dd Robert Jarzmik 2016-04-16 300 ret = sysfs_create_group(&dev->kobj, &ac97_controller_attr_group);
92c123dd Robert Jarzmik 2016-04-16 301 if (ret)
92c123dd Robert Jarzmik 2016-04-16 302 return ret;
92c123dd Robert Jarzmik 2016-04-16 303
92c123dd Robert Jarzmik 2016-04-16 304 mutex_lock(&ac97_controllers_mutex);
92c123dd Robert Jarzmik 2016-04-16 305 ac97_ctrl->ops = ops;
92c123dd Robert Jarzmik 2016-04-16 306 ac97_ctrl->slots_available = slots_available;
92c123dd Robert Jarzmik 2016-04-16 307 ac97_ctrl->dev = dev;
92c123dd Robert Jarzmik 2016-04-16 308 list_add(&ac97_ctrl->controllers, &ac97_controllers);
92c123dd Robert Jarzmik 2016-04-16 309 mutex_unlock(&ac97_controllers_mutex);
92c123dd Robert Jarzmik 2016-04-16 310
92c123dd Robert Jarzmik 2016-04-16 311 ac97_bus_reset(ac97_ctrl);
92c123dd Robert Jarzmik 2016-04-16 312 ac97_bus_scan(ac97_ctrl);
92c123dd Robert Jarzmik 2016-04-16 313
92c123dd Robert Jarzmik 2016-04-16 314 return 0;
92c123dd Robert Jarzmik 2016-04-16 315 }
92c123dd Robert Jarzmik 2016-04-16 316 EXPORT_SYMBOL(snd_ac97_controller_register);
92c123dd Robert Jarzmik 2016-04-16 317
92c123dd Robert Jarzmik 2016-04-16 318 /**
92c123dd Robert Jarzmik 2016-04-16 319 * snd_ac97_controller_unregister - unregister an ac97 controller
92c123dd Robert Jarzmik 2016-04-16 320 * @dev: the device previously provided to ac97_controller_register()
92c123dd Robert Jarzmik 2016-04-16 321 *
92c123dd Robert Jarzmik 2016-04-16 322 * Returns 0 on success, negative upon error
92c123dd Robert Jarzmik 2016-04-16 323 */
92c123dd Robert Jarzmik 2016-04-16 @324 int snd_ac97_controller_unregister(struct device *dev)
92c123dd Robert Jarzmik 2016-04-16 325 {
92c123dd Robert Jarzmik 2016-04-16 326 struct ac97_controller *ac97_ctrl;
92c123dd Robert Jarzmik 2016-04-16 327 int ret = -ENODEV, i;
:::::: The code at line 285 was first introduced by commit
:::::: 92c123ddf9fbf8eb9fbcbde0ce958a888cc15081 ALSA: ac97: add an ac97 bus
:::::: TO: Robert Jarzmik <robert.jarzmik@free.fr>
:::::: CC: Robert Jarzmik <robert.jarzmik@free.fr>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18037 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161101/11cd59ce/attachment-0001.gz>
^ permalink raw reply
* [PATCH net-next 2/2] drivers: net: xgene: fix: Coalescing values for v2 hardware
From: Iyappan Subramanian @ 2016-10-31 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477954827-9951-1-git-send-email-isubramanian@apm.com>
Changing the interrupt trigger region id to 2 and the
corresponding threshold set0/set1 values to 8/16.
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: Toan Le <toanle@apm.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 2 ++
drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c | 12 +++++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index 8456337..06e598c 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -55,8 +55,10 @@ enum xgene_enet_rm {
#define PREFETCH_BUF_EN BIT(21)
#define CSR_RING_ID_BUF 0x000c
#define CSR_PBM_COAL 0x0014
+#define CSR_PBM_CTICK0 0x0018
#define CSR_PBM_CTICK1 0x001c
#define CSR_PBM_CTICK2 0x0020
+#define CSR_PBM_CTICK3 0x0024
#define CSR_THRESHOLD0_SET1 0x0030
#define CSR_THRESHOLD1_SET1 0x0034
#define CSR_RING_NE_INT_MODE 0x017c
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c b/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
index 2b76732..af51dd5 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
@@ -30,7 +30,7 @@ static void xgene_enet_ring_init(struct xgene_enet_desc_ring *ring)
ring_cfg[0] |= SET_VAL(X2_INTLINE, ring->id & RING_BUFNUM_MASK);
ring_cfg[3] |= SET_BIT(X2_DEQINTEN);
}
- ring_cfg[0] |= SET_VAL(X2_CFGCRID, 1);
+ ring_cfg[0] |= SET_VAL(X2_CFGCRID, 2);
addr >>= 8;
ring_cfg[2] |= QCOHERENT | SET_VAL(RINGADDRL, addr);
@@ -192,13 +192,15 @@ static u32 xgene_enet_ring_len(struct xgene_enet_desc_ring *ring)
static void xgene_enet_setup_coalescing(struct xgene_enet_desc_ring *ring)
{
- u32 data = 0x7777;
+ u32 data = 0x77777777;
xgene_enet_ring_wr32(ring, CSR_PBM_COAL, 0x8e);
+ xgene_enet_ring_wr32(ring, CSR_PBM_CTICK0, data);
xgene_enet_ring_wr32(ring, CSR_PBM_CTICK1, data);
- xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data << 16);
- xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x40);
- xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x80);
+ xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data);
+ xgene_enet_ring_wr32(ring, CSR_PBM_CTICK3, data);
+ xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x08);
+ xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x10);
}
struct xgene_ring_ops xgene_ring2_ops = {
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 1/2] drivers: net: xgene: fix: Disable coalescing on v1 hardware
From: Iyappan Subramanian @ 2016-10-31 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477954827-9951-1-git-send-email-isubramanian@apm.com>
Since ethernet v1 hardware has a bug related to coalescing, disabling
this feature.
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: Toan Le <toanle@apm.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 12 ------------
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 3 ++-
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index c481f10..5390ae8 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -204,17 +204,6 @@ static u32 xgene_enet_ring_len(struct xgene_enet_desc_ring *ring)
return num_msgs;
}
-static void xgene_enet_setup_coalescing(struct xgene_enet_desc_ring *ring)
-{
- u32 data = 0x7777;
-
- xgene_enet_ring_wr32(ring, CSR_PBM_COAL, 0x8e);
- xgene_enet_ring_wr32(ring, CSR_PBM_CTICK1, data);
- xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data << 16);
- xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x40);
- xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x80);
-}
-
void xgene_enet_parse_error(struct xgene_enet_desc_ring *ring,
struct xgene_enet_pdata *pdata,
enum xgene_enet_err_code status)
@@ -929,5 +918,4 @@ struct xgene_ring_ops xgene_ring1_ops = {
.clear = xgene_enet_clear_ring,
.wr_cmd = xgene_enet_wr_cmd,
.len = xgene_enet_ring_len,
- .coalesce = xgene_enet_setup_coalescing,
};
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 3fc7b0d..1352b52 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1188,7 +1188,8 @@ static int xgene_enet_create_desc_rings(struct net_device *ndev)
tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
}
- pdata->ring_ops->coalesce(pdata->tx_ring[0]);
+ if (pdata->ring_ops->coalesce)
+ pdata->ring_ops->coalesce(pdata->tx_ring[0]);
pdata->tx_qcnt_hi = pdata->tx_ring[0]->slots - 128;
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 0/2] drivers: net: xgene: Fix coalescing bugs
From: Iyappan Subramanian @ 2016-10-31 23:00 UTC (permalink / raw)
To: linux-arm-kernel
This patch set fixes the following,
1. Since ethernet v1 hardware has a bug related to coalescing,
disabling this feature
2. Fixing ethernet v2 hardware, interrupt trigger region
id to 2, to kickoff coalescing
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
---
Iyappan Subramanian (2):
drivers: net: xgene: fix: Disable coalescing on v1 hardware
drivers: net: xgene: fix: Coalescing values for v2 hardware
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 12 ------------
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 2 ++
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 3 ++-
drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c | 12 +++++++-----
4 files changed, 11 insertions(+), 18 deletions(-)
--
1.9.1
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.9
From: Olof Johansson @ 2016-10-31 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024140622.GM30578@tiger>
Fabio,
I've got multi_v7 booting now, but imx_v6_v7 is still broken on both
hummingboard and wandboard.
Hummingboard doesn't even output anything on serial during boot, bug
with DEBUG_LL I got some more info
(No output boot at
http://arm-soc.lixom.net/bootlogs/mainline/v4.9-rc3/hummingboard-arm-imx_v6_v7_defconfig.html,
not very useful).
This one seems to be due to CONFIG_PCI_IMX6, which is off on
multi_v7_defconfig. Hard hang(?), last output is:
[ 0.490643] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
[ 0.496540] OF: PCI: No bus range found for /soc/pcie at 0x01000000,
using [bus 00-ff]
[ 0.504512] OF: PCI: IO 0x01f80000..0x01f8ffff -> 0x00000000
[ 0.510559] OF: PCI: MEM 0x01000000..0x01efffff -> 0x01000000
Wandboard, has a peculiar MMC error. First I thought it was just the
card going bad, but now I'm not so sure since multi_v7 boots just fine
on the same hardware:
http://arm-soc.lixom.net/bootlogs/mainline/v4.9-rc3/wandboard-arm-imx_v6_v7_defconfig.html
Not sure what's going on here, since bisecting between two configs is
a pain. When I disabled CONFIG_PCI, the error seems to be less likely
to happen (some boots succeed, sometimes it happens later during
boot).
-Olof
On Mon, Oct 24, 2016 at 7:06 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.9
>
> for you to fetch changes up to 4edd601c5a9c5094daa714e65063e623826f3bcc:
>
> ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031 (2016-10-24 21:26:01 +0800)
>
> ----------------------------------------------------------------
> The i.MX fixes for 4.9:
> - A couple of patches from Fabio to fix the GPC power domain regression
> which is caused by PM Domain core change 0159ec670763dd
> ("PM / Domains: Verify the PM domain is present when adding a
> provider"), and a related kernel crash seen with multi_v7_defconfig
> build.
> - Correct the PHY ID mask for AR8031 to match phy driver code.
> - Apply new added timer erratum A008585 for LS1043A and LS2080A SoC.
> - Correct vf610 global timer IRQ flag to avoid warning from gic driver
> after commit 992345a58e0c ("irqchip/gic: WARN if setting the
> interrupt type for a PPI fails").
>
> ----------------------------------------------------------------
> Fabio Estevam (3):
> ARM: imx: gpc: Initialize all power domains
> ARM: imx: gpc: Fix the imx_gpc_genpd_init() error path
> ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031
>
> Scott Wood (1):
> arm64: dts: Add timer erratum property for LS2080A and LS1043A
>
> Stefan Agner (1):
> ARM: dts: vf610: fix IRQ flag of global timer
>
> arch/arm/boot/dts/vf500.dtsi | 2 +-
> arch/arm/mach-imx/gpc.c | 15 ++++++++++++---
> arch/arm/mach-imx/mach-imx6q.c | 2 +-
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
> 5 files changed, 16 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH V4 10/10] arm64: KVM: add guest SEA support
From: Baicar, Tyler @ 2016-10-31 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031100206.GX1041@n2100.armlinux.org.uk>
Hello Russell,
On 10/31/2016 4:02 AM, Russell King - ARM Linux wrote:
> The subject line on this patch is misleading - it's not only ARM64
> specific...
Thank you for the feedback!
I only put ARM64 in the subject line because this patch only really adds
guest SEA support for the ARM64 KVM code. The ARM code had to be edited
since both the ARM and ARM64 KVM code use arch/arm/kvm/mmu.c. I can
change the subject line to "arm/arm64: KVM: add guest SEA support" if
you think that is better.
> On Fri, Oct 21, 2016 at 11:30:13AM -0600, Tyler Baicar wrote:
>> diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
>> index a3d61ad..86e1faa 100644
>> --- a/arch/arm/include/asm/system_misc.h
>> +++ b/arch/arm/include/asm/system_misc.h
>> @@ -24,4 +24,9 @@ extern unsigned int user_debug;
>>
>> #endif /* !__ASSEMBLY__ */
>>
>> +inline int handle_guest_sea(unsigned long addr, unsigned int esr)
> This needs to be static.
I'll make this static.
Thanks,
Tyler
>> +{
>> + return -1;
>> +}
>> +
>> #endif /* __ASM_ARM_SYSTEM_MISC_H */
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: dts: msm8974: Remove "unused" reserved region
From: Bjorn Andersson @ 2016-10-31 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027232306.13653-1-sboyd@codeaurora.org>
On Thu 27 Oct 16:23 PDT 2016, Stephen Boyd wrote:
> From what I can tell by looking at the android 3.10 kernel
> sources for msm8974, this isn't actually a reserved region.
> Instead it's marked as "unused" for reserved regions. Let's
> remove it so we get back a good chunk of memory.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/boot/dts/qcom-msm8974.dtsi | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 561d4d136762..5f4752696171 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -58,11 +58,6 @@
> reg = <0x0fd80000 0x180000>;
> no-map;
> };
> -
> - unused at 0ff00000 {
> - reg = <0x0ff00000 0x10100000>;
> - no-map;
> - };
> };
>
> cpus {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* [PATCHv2 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: Thor Thayer @ 2016-10-31 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031080222.GM13127@dell>
Hi Lee,
On 10/31/2016 03:02 AM, Lee Jones wrote:
> On Thu, 27 Oct 2016, tthayer at opensource.altera.com wrote:
>
>> From: Thor Thayer <tthayer@opensource.altera.com>
>>
>> Add the Altera Arria10 DevKit System Resource Monitor functionality
>> to the MFD device.
>>
>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>> ---
>> v2 Change from -mon to -monitor for clarity
>> ---
>> drivers/mfd/altera-a10sr.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
>> index 06e1f7f..30de652 100644
>> --- a/drivers/mfd/altera-a10sr.c
>> +++ b/drivers/mfd/altera-a10sr.c
>> @@ -33,6 +33,10 @@
>> .name = "altr_a10sr_gpio",
>> .of_compatible = "altr,a10sr-gpio",
>> },
>> + {
>> + .name = "altr_a10sr_monitor",
>> + .of_compatible = "altr,a10sr-monitor",
>
> So long as you use whichever compatible you agree on with Rob:
>
> For my own reference:
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>
I'm getting a "Non-standard signature" warning for this (even if I make
everything lower-case).
Would you prefer I submit it with the warning or should I change it to
"Acked-by"?
Thanks for reviewing!
Thor
>> + },
>> };
>>
>> static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
>
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Ray Jui @ 2016-10-31 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6ryMbF8kVUYOfhre4qtZp5haa2Shijcv40AXsjL_jZL=JQ@mail.gmail.com>
Hi Rafal,
On 10/31/2016 3:16 PM, Rafa? Mi?ecki wrote:
> On 31 October 2016 at 23:05, Scott Branden <scott.branden@broadcom.com> wrote:
>> On 16-10-31 02:56 PM, Florian Fainelli wrote:
>>> - fixups the aborts in the kernel, look where they come from, by using
>>> some bit of magic, looking at PCIe registers and whatnot (provided that
>>> is even possible), not too hard, but can take a while, and is error prone
>>
>> Option 4 sounds like the proper solution - check the range the abort is due
>> to the PCI device enumeration and only ignore those aborts.
>
> This was already suggested by Arnd:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/422873.html
> and Ray was checking some internal datasheets, but I'm afraid he never
> found info on checking if error was caused by PCIe controller.
>
Correct. Based on response from our ASIC team, on Northstar, 1) we
cannot distinguish between various external imprecise aborts; 2) nor can
we use the internal PCIe controller register to disable unsupported
request from being forwarded as APB bus error (and therefore causes the
abort).
All subsequent iProc SoCs can disable this error forwarding from the
iProc PCIe controller.
> Maybe we could think about some BCM5301X API (extra symbol exported by
> arch code) for starting ignoring aborts and stopping that. We could
> ignore aborts during scanning only but honestly it sounds like a bit
> hacky solution to me.
>
>
Correct, one possible solution is to only ignoring the aborts during
condiguration space register access of an endpoint device. Below is the
logic how I only disable the APB bus error forwarding during these
accesses (for all other iProc SoCs):
+/**
+ * APB error forwarding can be disabled during access of configuration
+ * registers of the endpoint device, to prevent unsupported requests
+ * (typically seen during enumeration with multi-function devices) from
+ * triggering a system exception
+ */
+static inline void iproc_pcie_apb_err_disable(struct pci_bus *bus,
+ bool disable)
+{
+ struct iproc_pcie *pcie = iproc_data(bus);
+ u32 val;
+
+ if (bus->number && pcie->has_apb_err_disable) {
+ val = iproc_pcie_read_reg(pcie, IPROC_PCIE_APB_ERR_EN);
+ if (disable)
+ val &= ~APB_ERR_EN;
+ else
+ val |= APB_ERR_EN;
+ iproc_pcie_write_reg(pcie, IPROC_PCIE_APB_ERR_EN, val);
+ }
+}
+
[...]
+static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int
devfn,
+ int where, int size, u32 *val)
+{
+ int ret;
+
+ iproc_pcie_apb_err_disable(bus, true);
+ ret = pci_generic_config_read32(bus, devfn, where, size, val);
+ iproc_pcie_apb_err_disable(bus, false);
+
+ return ret;
+}
+
+static int iproc_pcie_config_write32(struct pci_bus *bus, unsigned int
devfn,
+ int where, int size, u32 val)
+{
+ int ret;
+
+ iproc_pcie_apb_err_disable(bus, true);
+ ret = pci_generic_config_write32(bus, devfn, where, size, val);
+ iproc_pcie_apb_err_disable(bus, false);
+
+ return ret;
+}
+
static struct pci_ops iproc_pcie_ops = {
.map_bus = iproc_pcie_map_cfg_bus,
- .read = pci_generic_config_read32,
- .write = pci_generic_config_write32,
+ .read = iproc_pcie_config_read32,
+ .write = iproc_pcie_config_write32,
};
>>> I can certainly advocate that option 3 is the one that gives a working
>>> device, and this is what matters from a distribution perspective like
>>> LEDE/OpenWrt.
>>>
>> Since I don't use BCM5301x option 3 is fine by me.
>
> So for it seems like the best solution to me, but I'm open for changes
> if someone points another that is clean & better one.
>
I agree with that option 3 is probably the best solution for now, from a
distribution's perspective.
Thanks,
Ray
^ permalink raw reply
* [PATCH v3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Bjorn Andersson @ 2016-10-31 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477473794-26030-1-git-send-email-linus.walleij@linaro.org>
On Wed 26 Oct 02:23 PDT 2016, Linus Walleij wrote:
> This adds the MPU-3050 gyroscope and the KXSD9 accelerometer to
> the Qualcomm APQ8060 Dragonboard. The KXSD9 is mounted beyond the
> MPU-3050 and appear as a subdevice beyond it. We set up the
> required GPIO and interrupt lines to make the devices work.
>
I'm concerned about the interrupt below, but apart from that
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v3:
> - Should be fine to apply now: all bindings and requirements are
> merged.
> ChangeLog v1->v2:
> - Use the new I2C mux gate bindings from Peter Rosin (merged to
> the I2C subsystem)
> ---
> arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 53 ++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
[..]
> + mpu3050 at 68 {
> + compatible = "invensense,mpu3050";
> + reg = <0x68>;
> + /*
> + * GPIO17 has interrupt 208 on the
> + * PM8058, it is pulled high by a 10k
> + * resistor to VLOGIC so needs to be
> + * active low/falling edge.
> + */
> + interrupt-parent = <&pm8058_gpio>;
> + interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
To remove the need of resetting the interrupt-parent in each child you
can use the following form:
interrupts-extended = <&pm8058_gpio 208 IRQ_TYPE_EDGE_FALLING>;
But, if we correct the ssbi gpio driver then this would no longer be
interrupt 208 in this parent, right?. I believe that if you say
<&pmicintc 208 IRQ_TYPE_EDGE_FALLING> instead, which should work even
after we correct the gpio translation.
(Which probably means we need to get that redesigned, before we
introduce to many of these)
> + pinctrl-names = "default";
> + pinctrl-0 = <&dragon_mpu3050_gpios>;
> + vlogic-supply = <&pm8058_lvs0>; // 1.8V
> + vdd-supply = <&pm8058_l14>; // 2.85V
> +
> + /*
> + * The MPU-3050 acts as a hub for the
> + * accelerometer.
> + */
> + i2c-gate {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + kxsd9 at 18 {
> + compatible = "kionix,kxsd9";
> + reg = <0x18>;
> + interrupt-parent = <&tlmm>;
> + interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&dragon_kxsd9_gpios>;
> + iovdd-supply = <&pm8058_lvs0>; // 1.8V
> + vdd-supply = <&pm8058_l14>; // 2.85V
> + };
> + };
> + };
Regards,
Bjorn
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Rafał Miłecki @ 2016-10-31 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3847db9f-a8e1-b7fe-c2fa-19ea893bae5f@broadcom.com>
On 31 October 2016 at 23:05, Scott Branden <scott.branden@broadcom.com> wrote:
> On 16-10-31 02:56 PM, Florian Fainelli wrote:
>> - fixups the aborts in the kernel, look where they come from, by using
>> some bit of magic, looking at PCIe registers and whatnot (provided that
>> is even possible), not too hard, but can take a while, and is error prone
>
> Option 4 sounds like the proper solution - check the range the abort is due
> to the PCI device enumeration and only ignore those aborts.
This was already suggested by Arnd:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/422873.html
and Ray was checking some internal datasheets, but I'm afraid he never
found info on checking if error was caused by PCIe controller.
Maybe we could think about some BCM5301X API (extra symbol exported by
arch code) for starting ignoring aborts and stopping that. We could
ignore aborts during scanning only but honestly it sounds like a bit
hacky solution to me.
>> I can certainly advocate that option 3 is the one that gives a working
>> device, and this is what matters from a distribution perspective like
>> LEDE/OpenWrt.
>>
> Since I don't use BCM5301x option 3 is fine by me.
So for it seems like the best solution to me, but I'm open for changes
if someone points another that is clean & better one.
--
Rafa?
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18db27c7-1055-ff3c-0b0b-eeeaf5f3f5e0@gmail.com>
On 16-10-31 02:56 PM, Florian Fainelli wrote:
> On 10/31/2016 02:46 PM, Scott Branden wrote:
>>
>>
>> On 16-10-31 02:01 PM, Florian Fainelli wrote:
>>> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>>>
>>>>
>>>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>>>> Hi Rafal,
>>>>>
>>>>>
>>>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>>
>>>>>> Since early BCM5301X days we got abort handler that was removed by
>>>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise
>>>>>> abort
>>>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>>>
>>>>>> When probing PCI config space (device enumeration) it is expected to
>>>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>>>> Northstar (BCM5301X) one.
>>>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>>>
>>>> I think all the supported northstar devices have a PCIe controller. We
>>>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>>>
>>> Actually, I do see a couple disadvantages if we gate this with
>>> CONFIG_PCI: if this problem shows up irrespective of your kernel
>>> configuration, you want the error handler to clear it, not rely on
>>> CONFIG_PCI to be enabled for the error to go away and also, without an
>>> additional ifdef, additional compiler coverage.
>>>
>> A problem with reintroducing this change is that all imprecise data
>> aborts are ignored, not just PCI. So if you don't actually use PCI in
>> your system and want to debug other aborts you are unable to. I don't
>> know if we care about such situation.
>
> Considering that any abort is pretty much fatal, the options are:
>
> - update the freaking bootloader to a version where there are no such
> aborts generated, not an option on consumer devices, unclear which
> version (if any) fixes that
>
> - fixups the aborts externally, via a boot wrapper, which is going to
> take some time to develop, causes additional burden on the distributors
> to provide instructions/build images on how to do it
I think the abort is already fixed in the kernel now on boot so option 1
and 2 were not needed - and abort handler was removed as detailed by
Rafal in the commit. Only outstanding issue is now this new PCI
enumeration issue.
>
> - fixups the aborts in the kernel, irrespective of where they come from,
> simple and easy
>
> - fixups the aborts in the kernel, look where they come from, by using
> some bit of magic, looking at PCIe registers and whatnot (provided that
> is even possible), not too hard, but can take a while, and is error prone
Option 4 sounds like the proper solution - check the range the abort is
due to the PCI device enumeration and only ignore those aborts.
>
> I can certainly advocate that option 3 is the one that gives a working
> device, and this is what matters from a distribution perspective like
> LEDE/OpenWrt.
>
Since I don't use BCM5301x option 3 is fine by me.
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Rafał Miłecki @ 2016-10-31 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18db27c7-1055-ff3c-0b0b-eeeaf5f3f5e0@gmail.com>
On 31 October 2016 at 22:56, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 10/31/2016 02:46 PM, Scott Branden wrote:
>> A problem with reintroducing this change is that all imprecise data
>> aborts are ignored, not just PCI. So if you don't actually use PCI in
>> your system and want to debug other aborts you are unable to. I don't
>> know if we care about such situation.
>
> Considering that any abort is pretty much fatal, the options are:
>
> - update the freaking bootloader to a version where there are no such
> aborts generated, not an option on consumer devices, unclear which
> version (if any) fixes that
>
> - fixups the aborts externally, via a boot wrapper, which is going to
> take some time to develop, causes additional burden on the distributors
> to provide instructions/build images on how to do it
In practice updating bootloader is not possible (as you noticed) but I
don't think it's even possible to fix this problem at bootloader /
extra loader level. If this was a matter of hardware setup, we could
handle it in kernel as well I believe. Ray actually verified it's
controller limitation on Northstar platform.
It sounds a bit like you're thinking about MMU and Dcache Northstar
problem when writing that e-mail.
> - fixups the aborts in the kernel, irrespective of where they come from,
> simple and easy
>
> - fixups the aborts in the kernel, look where they come from, by using
> some bit of magic, looking at PCIe registers and whatnot (provided that
> is even possible), not too hard, but can take a while, and is error prone
>
> I can certainly advocate that option 3 is the one that gives a working
> device, and this is what matters from a distribution perspective like
> LEDE/OpenWrt.
--
Rafa?
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Florian Fainelli @ 2016-10-31 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dcb21fe4-672f-4545-5b47-d764f390e741@broadcom.com>
On 10/31/2016 02:46 PM, Scott Branden wrote:
>
>
> On 16-10-31 02:01 PM, Florian Fainelli wrote:
>> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>>
>>>
>>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>>> Hi Rafal,
>>>>
>>>>
>>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>
>>>>> Since early BCM5301X days we got abort handler that was removed by
>>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise
>>>>> abort
>>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>>
>>>>> When probing PCI config space (device enumeration) it is expected to
>>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>>> Northstar (BCM5301X) one.
>>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>>
>>> I think all the supported northstar devices have a PCIe controller. We
>>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>>
>> Actually, I do see a couple disadvantages if we gate this with
>> CONFIG_PCI: if this problem shows up irrespective of your kernel
>> configuration, you want the error handler to clear it, not rely on
>> CONFIG_PCI to be enabled for the error to go away and also, without an
>> additional ifdef, additional compiler coverage.
>>
> A problem with reintroducing this change is that all imprecise data
> aborts are ignored, not just PCI. So if you don't actually use PCI in
> your system and want to debug other aborts you are unable to. I don't
> know if we care about such situation.
Considering that any abort is pretty much fatal, the options are:
- update the freaking bootloader to a version where there are no such
aborts generated, not an option on consumer devices, unclear which
version (if any) fixes that
- fixups the aborts externally, via a boot wrapper, which is going to
take some time to develop, causes additional burden on the distributors
to provide instructions/build images on how to do it
- fixups the aborts in the kernel, irrespective of where they come from,
simple and easy
- fixups the aborts in the kernel, look where they come from, by using
some bit of magic, looking at PCIe registers and whatnot (provided that
is even possible), not too hard, but can take a while, and is error prone
I can certainly advocate that option 3 is the one that gives a working
device, and this is what matters from a distribution perspective like
LEDE/OpenWrt.
--
Florian
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Bjorn Helgaas @ 2016-10-31 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921223805.21652-1-cov@codeaurora.org>
On Wed, Sep 21, 2016 at 06:38:05PM -0400, Christopher Covington wrote:
> The Qualcomm Technologies QDF2432 SoC does not support accesses smaller
> than 32 bits to the PCI configuration space. Register the appropriate
> quirk.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
Hi Christopher,
Can you rebase this against v4.9-rc1? It no longer applies to my tree.
Note that this hardware is not spec-compliant since it doesn't support
sub-32 bit config writes. I just proposed a patch to warn about that
[1], so if/when we merge that patch and this one, you'll start seeing
those warnings.
[1] http://lkml.kernel.org/r/20161031213902.6340.96123.stgit at bhelgaas-glaptop.roam.corp.google.com
> ---
> drivers/acpi/pci_mcfg.c | 8 ++++++++
> drivers/pci/ecam.c | 10 ++++++++++
> include/linux/pci-ecam.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 245b79f..212334f 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -96,6 +96,14 @@ static struct mcfg_fixup mcfg_quirks[] = {
> THUNDER_ECAM_MCFG(2, 12),
> THUNDER_ECAM_MCFG(2, 13),
> #endif
> + { "QCOM ", "QDF2432 ", 1, 0, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 1, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 2, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 3, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 4, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
> };
>
> static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
> index 43ed08d..c3b3063 100644
> --- a/drivers/pci/ecam.c
> +++ b/drivers/pci/ecam.c
> @@ -162,3 +162,13 @@ struct pci_ecam_ops pci_generic_ecam_ops = {
> .write = pci_generic_config_write,
> }
> };
> +
> +/* ops for 32 bit config space access quirk */
> +struct pci_ecam_ops pci_32b_ops = {
> + .bus_shift = 20,
> + .pci_ops = {
> + .map_bus = pci_ecam_map_bus,
> + .read = pci_generic_config_read32,
> + .write = pci_generic_config_write32,
> + }
> +};
> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> index 35f0e81..a6cffb8 100644
> --- a/include/linux/pci-ecam.h
> +++ b/include/linux/pci-ecam.h
> @@ -65,6 +65,7 @@ extern struct pci_ecam_ops pci_thunder_pem_ops;
> #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> extern struct pci_ecam_ops pci_thunder_ecam_ops;
> #endif
> +extern struct pci_ecam_ops pci_32b_ops;
>
> #ifdef CONFIG_PCI_HOST_GENERIC
> /* for DT-based PCI controllers that support ECAM */
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
> Forum, a Linux Foundation Collaborative Project.
>
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb2c36cb-6f85-1a6d-160a-c50e22d6c46b@gmail.com>
On 16-10-31 02:01 PM, Florian Fainelli wrote:
> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>
>>
>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>> Hi Rafal,
>>>
>>>
>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>
>>>> Since early BCM5301X days we got abort handler that was removed by
>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>
>>>> When probing PCI config space (device enumeration) it is expected to
>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>> Northstar (BCM5301X) one.
>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>
>> I think all the supported northstar devices have a PCIe controller. We
>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>
> Actually, I do see a couple disadvantages if we gate this with
> CONFIG_PCI: if this problem shows up irrespective of your kernel
> configuration, you want the error handler to clear it, not rely on
> CONFIG_PCI to be enabled for the error to go away and also, without an
> additional ifdef, additional compiler coverage.
>
A problem with reintroducing this change is that all imprecise data
aborts are ignored, not just PCI. So if you don't actually use PCI in
your system and want to debug other aborts you are unable to. I don't
know if we care about such situation.
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-10-31 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ_EiSRzmQHLP2PTfzsLF4uWgYgCiRGsSk=MHbtOC5rgXnnFpw@mail.gmail.com>
On Mon 2016-10-31 13:22:18, Matt Ranostay wrote:
> On Tue, Oct 25, 2016 at 11:47 AM, Matt Ranostay <mranostay@gmail.com> wrote:
> > On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
> >>> Pavel + Sebastian this is the patchset that need I some input on :)
> >>
> >> Better then previous one.
> >>
> >> But my version of bq27xxx_battery.c already contains this:
> >
> > This is for allowing udev rule to set the properties as well.
> > otherwise a kinda crude RUN = " echo value >
> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>
> Any thoughts on this?
I'd say echo value >
/sys/module/bq27xxx_battery/parameters/poll_interval .. is quite
adequate solution...?
Alternatively, convince us that something else is useful for everyone,
and we can do the right thing (poll more often when battery is nearly
empty), automatically...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/bb28809e/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: mediatek: clean up mach-mediatek/Makefile
From: Matthias Brugger @ 2016-10-31 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAQbaQ38RZqgmJJW+BHOthrK5tPZ5JPPh9N9ry58YZ=kdg@mail.gmail.com>
On 10/31/2016 07:15 AM, Masahiro Yamada wrote:
> Hi Matthias,
>
>
> Can you pick up this for your next pull request?
>
Sure, pushed to v4.9-next/kconfig
Next time please don't forget to send your patches to the mediatek
mailinglist:
linux-mediatek at lists.infradead.org
This makes it easier for me to track the patches.
Thanks,
Matthias
>
>
> 2016-09-19 3:11 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
>> Kbuild descends into arch/arm/mach-mediatek/Makefile only when
>> CONFIG_ARCH_MEDIATEK is enabled. So, obj-$(CONFIG_ARCH_MEDIATEK)
>> is always equivalent to obj-y in this Makefile.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> arch/arm/mach-mediatek/Makefile | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-mediatek/Makefile b/arch/arm/mach-mediatek/Makefile
>> index 2116460..dadae67 100644
>> --- a/arch/arm/mach-mediatek/Makefile
>> +++ b/arch/arm/mach-mediatek/Makefile
>> @@ -1,4 +1,2 @@
>> -ifeq ($(CONFIG_SMP),y)
>> -obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o
>> -endif
>> -obj-$(CONFIG_ARCH_MEDIATEK) += mediatek.o
>> +obj-$(CONFIG_SMP) += platsmp.o
>> +obj-y += mediatek.o
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
^ permalink raw reply
* [PATCH V7 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eric Anholt @ 2016-10-31 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477363675.2298.2.camel@intel.com>
Zhang Rui <rui.zhang@intel.com> writes:
> On Mon, 2016-10-24 at 20:25 +0200, Stefan Wahren wrote:
>> >
>> > Eric Anholt <eric@anholt.net> hat am 24. Oktober 2016 um 18:38
>> > geschrieben:
>> >
>> >
>> > Stefan Wahren <stefan.wahren@i2se.com> writes:
>> >
>> > >
>> > > Hi Martin,
>> > >
>> > > Am 28.09.2016 um 23:10 schrieb Eric Anholt:
>> > > >
>> > > > kernel at martin.sperl.org writes:
>> > > >
>> > > > >
>> > > > > From: Martin Sperl <kernel@martin.sperl.org>
>> > > > >
>> > > > > Add basic thermal driver for bcm2835 SOC.
>> > > > >
>> > > > > This driver currently relies on the firmware setting up the
>> > > > > tsense HW block and does not set it up itself.
>> > > > >
>> > > > > Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>> > > > > Acked-by: Eric Anholt <eric@anholt.net>
>> > > > > Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>> > > > What's the status of merging this one???I'd like to merge the
>> > > > other
>> > > > patches.
>> > > i think it's necessary to rebase the whole series. Maybe we could
>> > > get it
>> > > into 4.10.
>> > Why would it need to be rebased???The status, as far as I know, is
>> > that
>> > we're still waiting for the subsystem maintainer to respond.
>> Since at least this patch won't apply anymore, but feedback from
>> maintainer is
>> still good :-)
>>
>> Sorry for this impatience, but i'm afraid that we possibly miss 4.10.
>
> Eduardo,
>
> any comments on this patchset?
It's been a month on v7 of this patch. Can we please merge it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/4847b7b1/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/3] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
From: Dave Gerlach @ 2016-10-31 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028040507.GJ10423@vireshk-i7>
On 10/27/2016 11:05 PM, Viresh Kumar wrote:
> On 27-10-16, 16:41, Dave Gerlach wrote:
>> Move _of_get_opp_desc_node into include/linux/pm_opp.h and rename it
>> dev_pm_opp_of_get_opp_desc_node to allow other drivers, such as platform
>> OPP and cpufreq drivers, to make use of it.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> drivers/base/power/opp/of.c | 8 ++++----
>> drivers/base/power/opp/opp.h | 1 -
>> include/linux/pm_opp.h | 6 ++++++
>> 3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
>> index 5552211e6fcd..215f5a538c78 100644
>> --- a/drivers/base/power/opp/of.c
>> +++ b/drivers/base/power/opp/of.c
>> @@ -198,7 +198,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
>> EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
>>
>> /* Returns opp descriptor node for a device, caller must do of_node_put() */
>> -struct device_node *_of_get_opp_desc_node(struct device *dev)
>> +struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
>
> Export as well ?
>
Whoops, yes will need to do that. I'll give some time for comments on
any other patches before sending v3.
Thanks,
Dave
^ permalink raw reply
* [PATCH v2] staging: vc04_services: setup DMA and coherent mask
From: Michael Zoran @ 2016-10-31 21:02 UTC (permalink / raw)
To: linux-arm-kernel
VCHI messages between the CPU and firmware use 32-bit
bus addresses. Explicitly set the DMA mask and coherent
on all platforms.
Signed-off-by: Michael Zoran <mzoran@crowfest.net>
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index a5afcc5..ba77fd8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -97,6 +97,15 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
int slot_mem_size, frag_mem_size;
int err, irq, i;
+ /*
+ * VCHI messages between the CPU and firmware use
+ * 32-bit bus addresses.
+ */
+ err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+
+ if (err < 0)
+ return err;
+
(void)of_property_read_u32(dev->of_node, "cache-line-size",
&g_cache_line_size);
g_fragments_size = 2 * g_cache_line_size;
--
2.10.1
^ permalink raw reply related
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Florian Fainelli @ 2016-10-31 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6e252703-0010-83ae-fa14-57352add007a@hauke-m.de>
On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>
>
> On 10/31/2016 07:08 PM, Scott Branden wrote:
>> Hi Rafal,
>>
>>
>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>
>>> Since early BCM5301X days we got abort handler that was removed by
>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>>> fault handler"). It assumed we need to deal only with pending aborts
>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>
>>> When probing PCI config space (device enumeration) it is expected to
>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>> Northstar (BCM5301X) one.
>> Should we only add this workaround code if CONFIG_PCI is on then?
>
> I think all the supported northstar devices have a PCIe controller. We
> could add such a CONFIG_PCI check, but I do not see a big advantage.
Actually, I do see a couple disadvantages if we gate this with
CONFIG_PCI: if this problem shows up irrespective of your kernel
configuration, you want the error handler to clear it, not rely on
CONFIG_PCI to be enabled for the error to go away and also, without an
additional ifdef, additional compiler coverage.
--
Florian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox