On Mon, Oct 19, 2015 at 08:40:09AM -0700, Michael Turquette wrote:
> Quoting Viresh Kumar (2015-10-08 00:48:28)
> > On 07-10-15, 21:12, Arnd Bergmann wrote:
> > > I think it clearly makes sense to have a fixed length for each of these
> > > members:
> > >
> > > either 32 bit is enough to represent
Quoting Viresh Kumar (2015-10-08 00:48:28)
> On 07-10-15, 21:12, Arnd Bergmann wrote:
> > I think it clearly makes sense to have a fixed length for each of these
> > members:
> >
> > either 32 bit is enough to represent all possible values, then
> > there is no need to make them 'long' on 64-bit
Quoting Viresh Kumar (2015-10-08 00:48:28)
> On 07-10-15, 21:12, Arnd Bergmann wrote:
> > I think it clearly makes sense to have a fixed length for each of these
> > members:
> >
> > either 32 bit is enough to represent all possible values, then
> > there is no need to make them 'long' on 64-bit
On Mon, Oct 19, 2015 at 08:40:09AM -0700, Michael Turquette wrote:
> Quoting Viresh Kumar (2015-10-08 00:48:28)
> > On 07-10-15, 21:12, Arnd Bergmann wrote:
> > > I think it clearly makes sense to have a fixed length for each of these
> > > members:
> > >
> > > either 32 bit is enough to represent
On Thu, 8 Oct 2015, Viresh Kumar wrote:
> > In my patch, I assumed that if 32-bit architectures work fine today, then
> > we don't need more range on 64-bit architectures either.
>
> The problem here is that we haven't fixed it properly.
> - clock framework expects it to be unsigned long
> - DT
On 07-10-15, 21:12, Arnd Bergmann wrote:
> I think it clearly makes sense to have a fixed length for each of these
> members:
>
> either 32 bit is enough to represent all possible values, then
> there is no need to make them 'long' on 64-bit architectures, or 32 bit
> is not enough and then the
On 07-10-15, 21:12, Arnd Bergmann wrote:
> I think it clearly makes sense to have a fixed length for each of these
> members:
>
> either 32 bit is enough to represent all possible values, then
> there is no need to make them 'long' on 64-bit architectures, or 32 bit
> is not enough and then the
On Thu, 8 Oct 2015, Viresh Kumar wrote:
> > In my patch, I assumed that if 32-bit architectures work fine today, then
> > we don't need more range on 64-bit architectures either.
>
> The problem here is that we haven't fixed it properly.
> - clock framework expects it to be unsigned long
> - DT
On Wednesday 07 October 2015 18:33:24 Viresh Kumar wrote:
> Cc'ing Mike and Stephen..
>
> On 07-10-15, 13:57, Greg Kroah-Hartman wrote:
> > On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> > > On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > > > Why would you be wanting to create
On 07-10-15, 18:39, Greg Kroah-Hartman wrote:
> Why not? Why does this have to be exported in debugfs? Just delete it,
> who cares about it? It's just "debugging".
It is really useful to see all the freq/voltage combinations on which
a device can work on, specially the CPU. And there are some
On Wed, Oct 07, 2015 at 10:57:01PM +0530, Viresh Kumar wrote:
> On 07-10-15, 18:19, Greg Kroah-Hartman wrote:
> > Ok, then stop exporting it in debugfs and everyone will be happy :)
>
> Hehe, not really. See I am not happy :(
Why not? Why does this have to be exported in debugfs? Just delete
On 07-10-15, 18:19, Greg Kroah-Hartman wrote:
> Ok, then stop exporting it in debugfs and everyone will be happy :)
Hehe, not really. See I am not happy :(
So, what do you suggest? Should we create debugfs_create_ulong()? And
how to implement that? With existing u32/u64 APIs or from scratch?
--
On Wed, Oct 07, 2015 at 06:33:24PM +0530, Viresh Kumar wrote:
> Cc'ing Mike and Stephen..
>
> On 07-10-15, 13:57, Greg Kroah-Hartman wrote:
> > On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> > > On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > > > Why would you be wanting to
On 07-10-15, 17:33, Russell King - ARM Linux wrote:
> Don't you even think about doing that - that's totally broken no matter
> what, and this is a good example of why casts are Bad.
>
> debugfs_create_u64() will create a debugfs object that will want to
> access a 64-bit value, but the value
On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > Why would you be wanting to create a "unsigned long" as an api anyway?
> > Just force it to be u64 all the time, can't you do that?
>
> Okay, so the variable in question (lets say
Cc'ing Mike and Stephen..
On 07-10-15, 13:57, Greg Kroah-Hartman wrote:
> On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> > On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > > Why would you be wanting to create a "unsigned long" as an api anyway?
> > > Just force it to be u64 all
On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > Why would you be wanting to create a "unsigned long" as an api anyway?
> > Just force it to be u64 all the time, can't you do that?
>
> Okay, so the variable in question (lets say
On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> Why would you be wanting to create a "unsigned long" as an api anyway?
> Just force it to be u64 all the time, can't you do that?
Okay, so the variable in question (lets say frequency) is an 'unsigned
long' and that's how all the APIs of clock
On Wed, Oct 07, 2015 at 04:33:02PM +0530, Viresh Kumar wrote:
> On 07-10-15, 16:29, Viresh Kumar wrote:
> > What about adding something like debugfs_create_unsigned_long() for
> > such cases?
>
> And that can be as simple (or ugly, not sure if its buggy) as:
>
> debugfs_create_unsigned_long()
>
On 07-10-15, 16:29, Viresh Kumar wrote:
> What about adding something like debugfs_create_unsigned_long() for
> such cases?
And that can be as simple (or ugly, not sure if its buggy) as:
debugfs_create_unsigned_long()
{
if (sizeof(unsigned long) == sizeof(u32))
return
Hi Arnd,
On 07-10-15, 09:35, Arnd Bergmann wrote:
> The recently added debugfs support for OPP creates files using the
> debugfs_create_bool() and debugfs_create_u32() interfaces, but
> casts the data argument to u32*, which is broken on some architectures.
>
> In case of debugfs_create_bool(),
The recently added debugfs support for OPP creates files using the
debugfs_create_bool() and debugfs_create_u32() interfaces, but
casts the data argument to u32*, which is broken on some architectures.
In case of debugfs_create_bool(), the API has changed as of 621a5f7ad9cd
("debugfs: Pass bool
The recently added debugfs support for OPP creates files using the
debugfs_create_bool() and debugfs_create_u32() interfaces, but
casts the data argument to u32*, which is broken on some architectures.
In case of debugfs_create_bool(), the API has changed as of 621a5f7ad9cd
("debugfs: Pass bool
Hi Arnd,
On 07-10-15, 09:35, Arnd Bergmann wrote:
> The recently added debugfs support for OPP creates files using the
> debugfs_create_bool() and debugfs_create_u32() interfaces, but
> casts the data argument to u32*, which is broken on some architectures.
>
> In case of debugfs_create_bool(),
On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> Why would you be wanting to create a "unsigned long" as an api anyway?
> Just force it to be u64 all the time, can't you do that?
Okay, so the variable in question (lets say frequency) is an 'unsigned
long' and that's how all the APIs of clock
On 07-10-15, 16:29, Viresh Kumar wrote:
> What about adding something like debugfs_create_unsigned_long() for
> such cases?
And that can be as simple (or ugly, not sure if its buggy) as:
debugfs_create_unsigned_long()
{
if (sizeof(unsigned long) == sizeof(u32))
return
On Wed, Oct 07, 2015 at 04:33:02PM +0530, Viresh Kumar wrote:
> On 07-10-15, 16:29, Viresh Kumar wrote:
> > What about adding something like debugfs_create_unsigned_long() for
> > such cases?
>
> And that can be as simple (or ugly, not sure if its buggy) as:
>
> debugfs_create_unsigned_long()
>
On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > Why would you be wanting to create a "unsigned long" as an api anyway?
> > Just force it to be u64 all the time, can't you do that?
>
> Okay, so the variable in question (lets say
Cc'ing Mike and Stephen..
On 07-10-15, 13:57, Greg Kroah-Hartman wrote:
> On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> > On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > > Why would you be wanting to create a "unsigned long" as an api anyway?
> > > Just force it to be u64 all
On 07-10-15, 18:19, Greg Kroah-Hartman wrote:
> Ok, then stop exporting it in debugfs and everyone will be happy :)
Hehe, not really. See I am not happy :(
So, what do you suggest? Should we create debugfs_create_ulong()? And
how to implement that? With existing u32/u64 APIs or from scratch?
--
On Wed, Oct 07, 2015 at 10:57:01PM +0530, Viresh Kumar wrote:
> On 07-10-15, 18:19, Greg Kroah-Hartman wrote:
> > Ok, then stop exporting it in debugfs and everyone will be happy :)
>
> Hehe, not really. See I am not happy :(
Why not? Why does this have to be exported in debugfs? Just delete
On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > Why would you be wanting to create a "unsigned long" as an api anyway?
> > Just force it to be u64 all the time, can't you do that?
>
> Okay, so the variable in question (lets say
On Wednesday 07 October 2015 18:33:24 Viresh Kumar wrote:
> Cc'ing Mike and Stephen..
>
> On 07-10-15, 13:57, Greg Kroah-Hartman wrote:
> > On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> > > On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > > > Why would you be wanting to create
On 07-10-15, 18:39, Greg Kroah-Hartman wrote:
> Why not? Why does this have to be exported in debugfs? Just delete it,
> who cares about it? It's just "debugging".
It is really useful to see all the freq/voltage combinations on which
a device can work on, specially the CPU. And there are some
On 07-10-15, 17:33, Russell King - ARM Linux wrote:
> Don't you even think about doing that - that's totally broken no matter
> what, and this is a good example of why casts are Bad.
>
> debugfs_create_u64() will create a debugfs object that will want to
> access a 64-bit value, but the value
On Wed, Oct 07, 2015 at 06:33:24PM +0530, Viresh Kumar wrote:
> Cc'ing Mike and Stephen..
>
> On 07-10-15, 13:57, Greg Kroah-Hartman wrote:
> > On Wed, Oct 07, 2015 at 04:51:49PM +0530, Viresh Kumar wrote:
> > > On 07-10-15, 12:07, Greg Kroah-Hartman wrote:
> > > > Why would you be wanting to
36 matches
Mail list logo
