Currently the application with enabled shadow stack will crash
if it sets up return uprobe. The reason is the uretprobe kernel
code changes the user space task's stack, but does not update
shadow stack accordingly.
Adding new functions to update values on shadow stack and using
them in uprobe code
On Tue, 2024-05-21 at 12:48 +0200, Jiri Olsa wrote:
> Currently the application with enabled shadow stack will crash
> if it sets up return uprobe. The reason is the uretprobe kernel
> code changes the user space task's stack, but does not update
> shadow stack accordingly.
>
> Adding new function
Currently the application with enabled shadow stack will crash
if it sets up return uprobe. The reason is the uretprobe kernel
code changes the user space task's stack, but does not update
shadow stack accordingly.
Adding new functions to update values on shadow stack and using
them in uprobe code
On Tue, May 21, 2024 at 04:22:21PM +0200, Oleg Nesterov wrote:
> On 05/21, Jiri Olsa wrote:
> >
> > Currently the application with enabled shadow stack will crash
> > if it sets up return uprobe. The reason is the uretprobe kernel
> > code changes the user space task's stack, but does not update
>
On 05/21, Jiri Olsa wrote:
>
> Currently the application with enabled shadow stack will crash
> if it sets up return uprobe. The reason is the uretprobe kernel
> code changes the user space task's stack, but does not update
> shadow stack accordingly.
>
> Adding new functions to update values on sh
Currently the application with enabled shadow stack will crash
if it sets up return uprobe. The reason is the uretprobe kernel
code changes the user space task's stack, but does not update
shadow stack accordingly.
Adding new functions to update values on shadow stack and using
them in uprobe code
On Wed Mar 6, 2024 at 10:05 PM EET, Calvin Owens wrote:
> Hello all,
>
> This patchset makes it possible to use bpftrace with kprobes on kernels
> built without loadable module support.
>
> On a Raspberry Pi 4b, this saves about 700KB of memory where BPF is
> needed but loadable module support is n
On Thursday 03/07 at 18:55 -0800, Luis Chamberlain wrote:
> On Thu, Mar 7, 2024 at 6:50 PM Masami Hiramatsu wrote:
> >
> > On Wed, 6 Mar 2024 17:58:14 -0800
> > Song Liu wrote:
> >
> > > Hi Calvin,
> > >
> > > It is great to hear from you! :)
> > >
> > > On Wed, Mar 6, 2024 at 3:23 PM Calvin Owen
On Thu, Mar 7, 2024 at 6:50 PM Masami Hiramatsu wrote:
>
> On Wed, 6 Mar 2024 17:58:14 -0800
> Song Liu wrote:
>
> > Hi Calvin,
> >
> > It is great to hear from you! :)
> >
> > On Wed, Mar 6, 2024 at 3:23 PM Calvin Owens wrote:
> > >
> > > On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrot
On Wed, 6 Mar 2024 17:58:14 -0800
Song Liu wrote:
> Hi Calvin,
>
> It is great to hear from you! :)
>
> On Wed, Mar 6, 2024 at 3:23 PM Calvin Owens wrote:
> >
> > On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote:
> > > On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:
> >
follow up attempts [0]. As I see it,
> the EXECMEM stuff would be what we use instead then. Mike kept the
> module_alloc() and the execmem was just a wrapper but your move of the
> arch stuff makes sense as well and I think would complement his series
> nicely.
yeah, it is better to wo
Hi Calvin,
On Wed, Mar 06, 2024 at 03:23:22PM -0800, Calvin Owens wrote:
> On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote:
> > On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:
> > > Hello all,
> > >
> > > This patchset makes it possible to use bpftrace with kprobes on kern
Hi Calvin,
It is great to hear from you! :)
On Wed, Mar 6, 2024 at 3:23 PM Calvin Owens wrote:
>
> On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote:
> > On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:
> > > Hello all,
> > >
> > > This patchset makes it possible to use bpft
On Wednesday 03/06 at 13:34 -0800, Luis Chamberlain wrote:
> On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:
> > Hello all,
> >
> > This patchset makes it possible to use bpftrace with kprobes on kernels
> > built without loadable module support.
>
> This is a step in the right dire
On Wed, Mar 06, 2024 at 12:05:07PM -0800, Calvin Owens wrote:
> Hello all,
>
> This patchset makes it possible to use bpftrace with kprobes on kernels
> built without loadable module support.
This is a step in the right direction for another reason: clearly the
module_alloc() is not about modules
Hello all,
This patchset makes it possible to use bpftrace with kprobes on kernels
built without loadable module support.
On a Raspberry Pi 4b, this saves about 700KB of memory where BPF is
needed but loadable module support is not. These two kernels had
identical configurations, except CONFIG_MO
021: Patch v3 modified format and contents of changelog follow feedback
> from Johan Hovold .
> 03/04/2021: Patch v2 modified format patch as comment from
> Johan Hovold :
> 1. Break commit message lines at 80 cols
> 2. Use kernel u8 and u16 instead of the c99 ones.
> 03/01
ormat patch as comment from
Johan Hovold :
1. Break commit message lines at 80 cols
2. Use kernel u8 and u16 instead of the c99 ones.
03/01/2021: Initialed submission of patch "Make the CP210x driver work with
GPIOs of CP2108.".
drivers/usb/serial
f changelog follow feedback
> from Jonhan Hovold mailto:jo...@kernel.org>>.
> 03/04/2021: Patch v2 modified format patch as comment from
> Johan Hovold mailto:jo...@kernel.org>>:
> 1. Break commit message lines at 80 cols
> 2. Use kernel u8 and u16 types instead of the c99
g should go here (after the '---', not after the diff).
> 3/4/2021: Patch v2 Modify format patch as comment form Johan Hovold
> mailto:jo...@kernel.org>>
As I told when you submitted a previous patch; you need to be more
specific in your changelog. This doesn't say *wh
On Thu, Mar 04, 2021 at 09:50:47AM +, Pho Tran wrote:
> Similar to other CP210x devices, GPIO interfaces (gpiochip) should be
> supported for CP2108.
>
> CP2108 has 4 serial interfaces but only 1 set of GPIO pins are shared
> to all of those interfaces. So, just need to initialize GPIOs of CP2
The four simplest IOCTL's allow to create new filters, remove them
and pass control commands specific to each target.
Signed-off-by: Sergei Shtepa
---
drivers/md/Makefile | 2 +-
drivers/md/dm-ioctl.c | 22 ++
drivers/md/flt-ctl.c | 25
Similar to other CP210x devices, GPIO interfaces (gpiochip) should be
supported for CP2108.
CP2108 has 4 serial interfaces but only 1 set of GPIO pins are shared
to all of those interfaces. So, just need to initialize GPIOs of CP2108
with only one interface (I use interface 0). It means just only
On Mon, Mar 01, 2021 at 08:13:46AM +, Pho Tran wrote:
> Similar to other CP210x devices, GPIO interfaces (gpiochip) should be
> supported for CP2108.
>
> CP2108 has 4 serial interfaces but only 1 set of GPIO pins are shared to all
> of those interfaces.
> So, just need to initialize GPIOs of
Similar to other CP210x devices, GPIO interfaces (gpiochip) should be supported
for CP2108.
CP2108 has 4 serial interfaces but only 1 set of GPIO pins are shared to all of
those interfaces.
So, just need to initialize GPIOs of CP2108 with only one interface (I use
interface 0).
It means just on
On Tue, Feb 23, 2021 at 10:02:08AM +, Pho Tran wrote:
> Similar to other CP210x devices, GPIO interfaces (gpiochip) should be
> supported for CP2108.
>
> CP2108 has 4 serial interfaces but only 1 set of GPIO pins are shared to all
> of those interfaces.
> So, just need to initialize GPIOs of
On Wed, Feb 10, 2021 at 02:49:24PM +0800, Jisheng Zhang wrote:
> Hi,
>
> On Mon, 8 Feb 2021 16:56:00 +0300 Serge Semin wrote:
>
>
> >
> > Since commit bb3222f71b57 ("net: stmmac: platform: use optional clk/reset
> > get APIs") a manual implementation of the optional device reset control
> > fun
Hi,
On Mon, 8 Feb 2021 16:56:00 +0300 Serge Semin wrote:
>
> Since commit bb3222f71b57 ("net: stmmac: platform: use optional clk/reset
> get APIs") a manual implementation of the optional device reset control
> functionality has been replaced with using the
> devm_reset_control_get_optional() m
Since commit bb3222f71b57 ("net: stmmac: platform: use optional clk/reset
get APIs") a manual implementation of the optional device reset control
functionality has been replaced with using the
devm_reset_control_get_optional() method. But for some reason the optional
reset control handler usage has
tBSD.
Since GNU awk and modern versions of BSD awk (distributed with
FreeBSD/OpenBSD) are fine with either form, the definition of
'cmd_unroll' can be trivially tweaked to let the lib/raid6 Makefile
work with both old and new awk flag dialects.
Signed-off-by: John Millikin
Signed-off-b
tBSD.
Since GNU awk and modern versions of BSD awk (distributed with
FreeBSD/OpenBSD) are fine with either form, the definition of
'cmd_unroll' can be trivially tweaked to let the lib/raid6 Makefile
work with both old and new awk flag dialects.
Signed-off-by: John Millikin
Signed-off-b
Update arm-smmu-v3 context descriptor (CD) library driver to work
with iommu-pasid-table APIs. These APIs are then used in arm-smmu-v3
drivers to manage CD tables.
Signed-off-by: Vivek Gautam
Cc: Joerg Roedel
Cc: Will Deacon
Cc: Robin Murphy
Cc: Jean-Philippe Brucker
Cc: Eric Auger
Cc: Alex
tBSD.
Since GNU awk and modern versions of BSD awk (distributed with
FreeBSD/OpenBSD) are fine with either form, the definition of
'cmd_unroll' can be trivially tweaked to let the lib/raid6 Makefile
work with both old and new awk flag dialects.
Signed-off-by: John Millikin
Signed-off-b
tBSD.
Since GNU awk and modern versions of BSD awk (distributed with
FreeBSD/OpenBSD) are fine with either form, the definition of
'cmd_unroll' can be trivially tweaked to let the lib/raid6 Makefile
work with both old and new awk flag dialects.
Signed-off-by: John Millikin
Signed-off-b
On Friday 08 Jan 2021 at 16:46:53 (+0530), Viresh Kumar wrote:
> The AMU counters won't get used today if the cpufreq driver is built as
> a module as the amu core requires everything to be ready by late init.
>
> Fix that properly by registering for cpufreq policy notifier. Note that
> the amu co
The AMU counters won't get used today if the cpufreq driver is built as
a module as the amu core requires everything to be ready by late init.
Fix that properly by registering for cpufreq policy notifier. Note that
the amu core don't have any cpufreq dependency after the first time
CPUFREQ_CREATE_
On 08-01-21, 09:44, Ionela Voinescu wrote:
> Now that I think of it again (after spending 30 minutes trying to come
> up with a more clear solution) I realised this is not actually a
> problem :).
>
> The only location that checks the invariance status is schedutil, but
> what a cpufreq governor d
On Friday 08 Jan 2021 at 09:44:16 (+), Ionela Voinescu wrote:
> On Thursday 17 Dec 2020 at 16:20:49 (+0530), Viresh Kumar wrote:
> > On 16-12-20, 19:37, Ionela Voinescu wrote:
> > > I did not yet test this, but reading this comment made me wonder..
> > >
> > > arch_scale_freq_invariant() (or t
On Thursday 17 Dec 2020 at 16:20:49 (+0530), Viresh Kumar wrote:
> On 16-12-20, 19:37, Ionela Voinescu wrote:
> > I did not yet test this, but reading this comment made me wonder..
> >
> > arch_scale_freq_invariant() (or topology_scale_freq_invariant()) is also
> > called from schedutil when obtai
From: Jia Qingtong
Supply little-endian address bit definitions as well as
set proper endian swapping modes.
Signed-off-by: Jia Qingtong
---
fix pcie setup error when Octeon in little-endian mode
[] octeon_pcie_setup+0x264/0x4e8
[] do_one_initcall+0x54/0x190
[] kernel_init_freeable+0x1bc/0x230
On 16-12-20, 19:37, Ionela Voinescu wrote:
> I did not yet test this, but reading this comment made me wonder..
>
> arch_scale_freq_invariant() (or topology_scale_freq_invariant()) is also
> called from schedutil when obtaining the next frequency.
>
> So if we had a system that only partly suppor
Hi,
On Wednesday 16 Dec 2020 at 10:08:05 (+0530), Viresh Kumar wrote:
[..]
> > > +static void amu_fie_setup(const struct cpumask *cpus)
> > > {
> > > - cpumask_var_t valid_cpus;
> > > bool invariant;
> > > - int ret = 0;
> > > int cpu;
> > >
> > > - if (!zalloc_cpumask_var(&valid_cpus, GFP_
On 16-12-20, 00:03, Ionela Voinescu wrote:
> Hi,
>
> On Tuesday 15 Dec 2020 at 11:04:16 (+0530), Viresh Kumar wrote:
> > The AMU counters won't get used today if the cpufreq driver is built as
> > a module as the amu core requires everything to be ready by late init.
> >
> > Fix that properly by
Hi,
On Tuesday 15 Dec 2020 at 11:04:16 (+0530), Viresh Kumar wrote:
> The AMU counters won't get used today if the cpufreq driver is built as
> a module as the amu core requires everything to be ready by late init.
>
> Fix that properly by registering for cpufreq policy notifier. Note that
> the
Hi,
On Tuesday 15 Dec 2020 at 11:04:16 (+0530), Viresh Kumar wrote:
> The AMU counters won't get used today if the cpufreq driver is built as
> a module as the amu core requires everything to be ready by late init.
>
> Fix that properly by registering for cpufreq policy notifier. Note that
> the
The AMU counters won't get used today if the cpufreq driver is built as
a module as the amu core requires everything to be ready by late init.
Fix that properly by registering for cpufreq policy notifier. Note that
the amu core don't have any cpufreq dependency after the first time
CPUFREQ_CREATE_
Replace the manual implementation of the optional device reset control
functionality with using the devm_reset_control_get_optional() method in
order to improve the code maintainability and fix a potential bug. It
will come out if the reset control handler has been specified, but the
reset framewor
Hi Lukas,
see reply below
On Wed, Sep 16, 2020 at 7:48 AM Lukas Wunner wrote:
>
> On Tue, Sep 15, 2020 at 04:15:15PM +0200, Jinpu Wang wrote:
> > We are testing PCIe nvme SSD hotplug, it works out of box with kernel
> > 5.4.62,
> > dmesg during the hotplug:
> [...]
> > But with kernel 4.19.133,
On Tue, Sep 15, 2020 at 04:15:15PM +0200, Jinpu Wang wrote:
> We are testing PCIe nvme SSD hotplug, it works out of box with kernel 5.4.62,
> dmesg during the hotplug:
[...]
> But with kernel 4.19.133, pcieport core doesn't print anything, is
> there known problem with kernel 4.19 support for pcie
Hi folks,
We are testing PCIe nvme SSD hotplug, it works out of box with kernel 5.4.62,
dmesg during the hotplug:
[ 605.734513] pcieport :16:00.0: pciehp: Slot(0-3): Link Down
[ 605.734516] pcieport :16:00.0: pciehp: Slot(0-3): Card not present
[ 605.842634] blk_update_request: I/O err
Committer: Peter Zijlstra
CommitterDate: Wed, 26 Aug 2020 12:42:04 +02:00
lockdep: Extend __bfs() to work with multiple types of dependencies
Now we have four types of dependencies in the dependency graph, and not
all the pathes carry real dependencies (the dependencies that may cause
a deadlock
The core scheduling logic bypasses the scheduling class's
pick_next_task() which starts the hrtick logic usually. Instead,
it explicitly calls set_next_task() or leaves the current task
running without any callback into the CFS scheduler.
To ensure that we still configure the hrtick timer properly
From: John Stultz
Update the driver to work with v4.9 kernels
Signed-off-by: John Stultz
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/gpu/dw_drm_dsi.c | 4 +-
drivers/staging/hikey9xx/gpu/kirin_dpe_reg.h | 1 +
drivers/staging/hikey9xx/gpu/kirin_drm_drv.c | 3
Currently, this driver OOPSes. It turns that this driver
needs to be updated in order to work with the current
iommu kAPI.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/hisi_smmu.h | 2 +
drivers/staging/hikey9xx/hisi_smmu_lpae.c | 81 ---
2 files
Now we have four types of dependencies in the dependency graph, and not
all the pathes carry real dependencies (the dependencies that may cause
a deadlock), for example:
Given lock A and B, if we have:
CPU1CPU2
= ==
From: Jens Axboe
commit 807abcb0883439af5ead73f3308310453b97b624 upstream.
The double poll additions were centered around doing POLL_ADD on file
descriptors that use more than one waitqueue (typically one for read,
one for write) when being polled. However, it can also end up being
triggered for
From: hersen wu
commit b448d30b0c303d5454ea572b772d1ffae96bc6e7 upstream.
[Why]
amdgpu_dm->backlight_caps is for single eDP only. the caps are upddated
for very connector. Real eDP caps will be overwritten by other external
display. For OLED panel, caps->aux_support is set to 1 for OLED pnael.
a
Lothar
On 6/25/20 7:24 AM, Lothar Waßmann wrote:
Hi,
When trying to use the m_can driver on an stm32mp15 based system, I
found that I could not send or receive any data.
Analyzing the pinctrl registers revealed, that the pins were
configured for sleep state even when the can interfaces were in
Hi,
When trying to use the m_can driver on an stm32mp15 based system, I
found that I could not send or receive any data.
Analyzing the pinctrl registers revealed, that the pins were
configured for sleep state even when the can interfaces were in use.
Looking at the m_can_platform.c driver I found
While trying to use kexec on my desktop,
which has Titan Ridge Thunderbolt add-on card,
I noticed that after a kexec, system hangs
for about a minute in the 'wating for udev devices
to settle' phase of the boot.
I found out that if I unload the thunderbolt driver
prior to the kexec, then it works
While trying to use kexec on my desktop,
which has Titan Ridge Thunderbolt add-on card,
I noticed that after a kexec, system hangs
for about a minute in the 'wating for udev devices
to settle' phase of the boot.
I found out that if I unload the thunderbolt driver
prior to the kexec, then it works
Dear friend,
Please kindly work with me in this transaction for you will not regret
it at all.
First of all, I contacted you for us to work in this transaction because
you are bearing the same last name identity with a deceased customer of
our bank, therefore I
can present you as the true
Committer: Peter Zijlstra
CommitterDate: Thu, 30 Apr 2020 20:14:34 +02:00
x86/speculation: Change FILL_RETURN_BUFFER to work with objtool
Change FILL_RETURN_BUFFER so that objtool groks it and can generate
correct ORC unwind information.
- Since ORC is alternative invariant; that is, all
Change FILL_RETURN_BUFFER so that objtool groks it and can generate
correct ORC unwind information.
- Since ORC is alternative invariant; that is, all alternatives
should have the same ORC entries, the __FILL_RETURN_BUFFER body
can not be part of an alternative.
Therefore, move it out o
On Mon, 2019-10-14 at 14:47 +0800, Yu Zhang wrote:
> On Thu, Oct 03, 2019 at 02:23:48PM -0700, Rick Edgecombe wrote:
> > Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
> > guests view of gfn is used when high bits of the physical memory are
> > used as extra permissions bits.
On Thu, Oct 03, 2019 at 02:23:48PM -0700, Rick Edgecombe wrote:
> Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
> guests view of gfn is used when high bits of the physical memory are
> used as extra permissions bits. This supports the KVM XO feature.
>
> TODO: Since MTRR is
Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
guests view of gfn is used when high bits of the physical memory are
used as extra permissions bits. This supports the KVM XO feature.
TODO: Since MTRR is emulated using EPT permissions, the XO version of
the gpa range will not i
Hi Pavel,
On 9/17/19 2:42 PM, Pavel Machek wrote:
> Hi!
>
> +++ b/drivers/leds/leds-lm3532.c
> @@ -629,7 +629,7 @@ static int lm3532_parse_node(struct lm3532_data *priv)
>
> lm3532_init_registers(led);
>
> - ret = devm_led_classdev_register(priv->dev,
/lm3532-right-registration-to-work-with-LED-backlight/20190917-205315
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x
Hi!
> >>> +++ b/drivers/leds/leds-lm3532.c
> >>> @@ -629,7 +629,7 @@ static int lm3532_parse_node(struct lm3532_data *priv)
> >>>
> >>> lm3532_init_registers(led);
> >>>
> >>> - ret = devm_led_classdev_register(priv->dev, &led->led_dev);
> >>> + ret = devm_of_led_clas
Use new registration support, which will eventually be needed for
proper backlight support.
Signed-off-by: Pavel Machek
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
index 0507c65..23f49b6 100644
--- a/drivers/leds/leds-lm3532.c
+++ b/drivers/leds/leds-lm3532.c
@@ -577,6
On 9/8/19 10:03 AM, Pavel Machek wrote:
> On Wed 2019-08-28 22:32:57, Jacek Anaszewski wrote:
>> On 8/28/19 10:53 AM, Pavel Machek wrote:
>>> Hi!
>>>
>>> Eventually, these will be needed.
>>>
>>> Best regards,
>>> Pavel
>>>
>>> commit 38d9
On Wed 2019-08-28 22:32:57, Jacek Anaszewski wrote:
> On 8/28/19 10:53 AM, Pavel Machek wrote:
> > Hi!
> >
> > Eventually, these will be needed.
> >
> > Best regards,
> > Pavel
> >
> > commit 38d956977a7d6cbdc811676f9b4033da7487e045
> >
On 8/28/19 10:53 AM, Pavel Machek wrote:
> Hi!
>
> Eventually, these will be needed.
>
> Best regards,
> Pavel
>
> commit 38d956977a7d6cbdc811676f9b4033da7487e045
> Author: Pavel
> Date: Wed Aug 7 12:43:52 2019 +0200
>
> d4: l
Hi!
Eventually, these will be needed.
Best regards,
Pavel
commit 38d956977a7d6cbdc811676f9b4033da7487e045
Author: Pavel
Date: Wed Aug 7 12:43:52 2019 +0200
d4: lm3532 needs to use right register function for backlight to wor
> > > After Canonical developers triaged the bug they determined that the
> > > problem lies upstream, and instructed me to send mails to the relevant
> > > kernel module maintainers at Realtek and to the general kernel.org
> > > mailing list.
> > >
>
l.org
> > mailing list.
> >
> > I built kernel 5.3.0-rc1+ with the latest realtek drivers from
> > wireless-drivers-next but my Realtek r8822be doesn't work with
> > rtw88/rtwpci kernel modules.
> >
> > Please let me know if there is any a
realtek drivers from
> wireless-drivers-next but my Realtek r8822be doesn't work with
> rtw88/rtwpci kernel modules.
>
> Please let me know if there is any additional information I can
> provide that would help in debugging this issue.
Any chance this would help you?
https://pa
upstream, and instructed me to send mails to the relevant
kernel module maintainers at Realtek and to the general kernel.org
mailing list.
I built kernel 5.3.0-rc1+ with the latest realtek drivers from
wireless-drivers-next but my Realtek r8822be doesn't work with
rtw88/rtwpci kernel modules.
Pleas
Hi,
These 2 patches implement GPIOs lookup for boards still using static
properties (instead of OF or ACPI), which will allow drivers to abandon
the custom platform data structures and switch to using generic bindings
with gpiod_get_*() API working transparently.
The 2nd patch was posted in Septe
From: Anson Huang
On some i.MX8M platforms, clock driver uses platform driver
model and it is NOT ready during timer initialization phase,
the clock operations will fail and system counter driver will
fail too. As all the i.MX8M platforms' system counter clock
are from OSC which is always enabled
From: Anson Huang
On some i.MX8M platforms, clock driver uses platform driver
model and it is NOT ready during timer initialization phase,
the clock operations will fail and system counter driver will
fail too. As all the i.MX8M platforms' system counter clock
are from OSC which is always enabled
From: Anson Huang
On some i.MX8M platforms, clock driver uses platform driver
model and it is NOT ready during timer initialization phase,
the clock operations will fail and system counter driver will
fail too. As all the i.MX8M platforms' system counter clock
are from OSC which is always enabled
Hi, Daniel
> On 23/06/2019 14:38, anson.hu...@nxp.com wrote:
> > From: Anson Huang
> >
> > On some i.MX8M platforms, clock driver uses platform driver model and
> > it is NOT ready during timer initialization phase, the clock
> > operations will fail and system counter driver will fail too. As al
On 23/06/2019 14:38, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> On some i.MX8M platforms, clock driver uses platform driver
> model and it is NOT ready during timer initialization phase,
> the clock operations will fail and system counter driver will
> fail too. As all the i.MX8M platform
From: Anson Huang
On some i.MX8M platforms, clock driver uses platform driver
model and it is NOT ready during timer initialization phase,
the clock operations will fail and system counter driver will
fail too. As all the i.MX8M platforms' system counter clock
are from OSC which is always enabled
Also really the "Thor and Odin" style acidprophets we still see reflected in
people like Stallman is the big reggresion, and potentialiy block for greater
economic flow, and should be replaced by intercultural thinking, taking
monotheistic developments, and going further to prosperity.
Oase is
I worked with low-jitter on Linux, here earlier, and tested Available Source,
and found it to be of high quality, giving 172/3 frames with the jitter
sensitive 3-pass Doom 3 engine, from ID Software,then at 1080p res, some years
ago, a good test for the fastest bus in the system, and giving a go
On Wed, Apr 24, 2019 at 09:55:37AM -0700, Kees Cook wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code r
On Wed, Apr 24, 2019 at 09:55:37AM -0700, Kees Cook wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code r
On Wed, Apr 24, 2019 at 9:55 AM Kees Cook wrote:
>
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code refactor
Clang's integrated assembler does not allow assembly macros defined
in one inline asm block using the .macro directive to be used across
separate asm blocks. LLVM developers consider this a feature and not a
bug, recommending code refactoring:
https://bugs.llvm.org/show_bug.cgi?id=19749
As binu
Hi Kees,
On Tue, Apr 23, 2019 at 04:26:22PM -0700, Kees Cook wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommend
On Tue, Apr 23, 2019 at 4:26 PM Kees Cook wrote:
>
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code refactor
Clang's integrated assembler does not allow assembly macros defined
in one inline asm block using the .macro directive to be used across
separate asm blocks. LLVM developers consider this a feature and not a
bug, recommending code refactoring:
https://bugs.llvm.org/show_bug.cgi?id=19749
As binu
On Tue, Apr 23, 2019 at 4:00 PM Nick Desaulniers
wrote:
>
> On Tue, Apr 23, 2019 at 3:57 PM Ard Biesheuvel
> wrote:
> >
> > On Wed, 24 Apr 2019 at 00:55, Kees Cook wrote:
> > >
> > > On Mon, Apr 15, 2019 at 7:38 AM Kees Cook wrote:
> > > > +#define __msr_s(r, v)
On Tue, Apr 23, 2019 at 3:57 PM Ard Biesheuvel
wrote:
>
> On Wed, 24 Apr 2019 at 00:55, Kees Cook wrote:
> >
> > On Mon, Apr 15, 2019 at 7:38 AM Kees Cook wrote:
> > > +#define __msr_s(r, v) \
> > > + DEFINE_MSR_S
On Wed, 24 Apr 2019 at 00:55, Kees Cook wrote:
>
> On Mon, Apr 15, 2019 at 7:38 AM Kees Cook wrote:
> > +#define __msr_s(r, v) \
> > + DEFINE_MSR_S\
> > +" msr_s " __stringify(r) ", %x0\n"
On Mon, Apr 15, 2019 at 7:38 AM Kees Cook wrote:
> +#define __msr_s(r, v) \
> + DEFINE_MSR_S\
> +" msr_s " __stringify(r) ", %x0\n"\
> + UNDEFINE_MSR_S : : "rZ" (v)
BTW ..
On Tue, Apr 23, 2019 at 8:25 PM Kees Cook wrote:
> On Tue, Apr 23, 2019 at 11:15 AM Nick Desaulniers
> wrote:
> > On Tue, Apr 23, 2019 at 7:12 AM Mark Rutland wrote:
> > >
> > > On Mon, Apr 22, 2019 at 10:44:10AM -0700, Nick Desaulniers wrote:
> > > > On Tue, Apr 16, 2019 at 9:03 PM Kees Cook
1 - 100 of 1011 matches
Mail list logo
