Editing is it
Do you have photos for cutting out,or adding clipping path? We are here to help you for that also including retouching. Both for product photos and portrait photos. Yours, Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
It's time to start it
Do you have photos for cutting out,or adding clipping path? We are here to help you for that also including retouching. Both for product photos and portrait photos. Yours, Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Mobile App Development
Hello, Do you have an idea for a mobile application or is your business in need of a mobile application? We are India located. We have been developing mobile applications from last 6 years. We are a team of 100+ web & mobile app development professionals who are ready to serve you. We have developed more than 350 mobile applications ranging from simple business App to enterprise level complexity. We have developed expertise on iOS, Android, Ionic and PhoneGap based platforms and various libraries. Services that we offer: • Mobile App Consulting • Mobile App UI/UX Designing • Mobile App Development • Mobile App Maintenance & Support • Website and eCommerce portal Development Industries we have catered: Business, Games and Entertainment, Life Style, Social Media, Hospitality, eCommerce (m-commerce), Banks and Financial, Food and Beverages, etc…. We can share the references of our work on demand. 3 Simple steps to get started: 1. Respond to this Email 2. We will provide an Action Plan and Cost 3. Get your Mobile App Development started We are waiting for your response. Best Regards, Jason Taylor ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Do It Yourself, Clear, No Slip floor Treatment
Do It Yourself, Clear, No Slip floor Treatment Our Anti-Slip Floor Treatment Makes all types of hard mineral surface floors slip resistant and safe for a minimum of 4 Years-Guaranteed Indoors or outdoors Walk on immediately after a treatment. Use on ceramic, porcelain and quarry tiles, marble, granite, concrete, etc. Typical Applications - Restaurant Kitchen Floors, Hotels, Hospitals, Office Buildings, etc. Some of our satisfied customers include: McDonald's, Kroger, Holiday Inn, Miami Children's Hospital, Pfizer, etc. Please contact us for additional information. Jason Email: york...@sina.com If you are located outside the U.S., there may be a Distributorship available in your country. Send for details. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 02/17] compat_ioctl: move drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 05:01:03PM +0200, Arnd Bergmann wrote:
> Each of these drivers has a copy of the same trivial helper function to
> convert the pointer argument and then call the native ioctl handler.
>
> We now have a generic implementation of that, so use it.
>
> Signed-off-by: Arnd Bergmann
> drivers/char/ppdev.c | 12 +-
> drivers/char/tpm/tpm_vtpm_proxy.c | 12 +-
> drivers/firewire/core-cdev.c | 12 +-
> drivers/hid/usbhid/hiddev.c | 11 +
> drivers/hwtracing/stm/core.c | 12 +-
> drivers/misc/mei/main.c | 22 +
> drivers/mtd/ubi/cdev.c| 36 +++-
> drivers/net/tap.c | 12 +-
> drivers/staging/pi433/pi433_if.c | 12 +-
> drivers/usb/core/devio.c | 16 +
> drivers/vfio/vfio.c | 39 +++
> drivers/vhost/net.c | 12 +-
> drivers/vhost/scsi.c | 12 +-
> drivers/vhost/test.c | 12 +-
> drivers/vhost/vsock.c | 12 +-
> fs/fat/file.c | 13 +--
> 16 files changed, 20 insertions(+), 237 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 87a0ce47f201..a170f5ca7416 100644
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -678,20 +678,10 @@ static long vtpmx_fops_ioctl(struct file *f, unsigned
> int ioctl,
> }
> }
>
> -#ifdef CONFIG_COMPAT
> -static long vtpmx_fops_compat_ioctl(struct file *f, unsigned int ioctl,
> - unsigned long arg)
> -{
> - return vtpmx_fops_ioctl(f, ioctl, (unsigned long)compat_ptr(arg));
> -}
> -#endif
> -
> static const struct file_operations vtpmx_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = vtpmx_fops_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = vtpmx_fops_compat_ioctl,
> -#endif
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> .llseek = noop_llseek,
> };
For vtpm:
Reviewed-by: Jason Gunthorpe
Arnd, would you consider including a patch as part of/after this
series to make compat_ioctl in drivers/infiniband/core/uverbs_main.c
use this as well? Looks like a bug too?
Thanks,
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> drivers/android/binder.c| 2 +-
> drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
> drivers/dma-buf/dma-buf.c | 4 +---
> drivers/dma-buf/sw_sync.c | 2 +-
> drivers/dma-buf/sync_file.c | 2 +-
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +-
> drivers/hid/hidraw.c| 4 +---
> drivers/iio/industrialio-core.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 4 ++--
> drivers/media/rc/lirc_dev.c | 4 +---
> drivers/mfd/cros_ec_dev.c | 4 +---
> drivers/misc/vmw_vmci/vmci_host.c | 2 +-
> drivers/nvdimm/bus.c| 4 ++--
> drivers/nvme/host/core.c| 2 +-
> drivers/pci/switch/switchtec.c | 2 +-
> drivers/platform/x86/wmi.c | 2 +-
> drivers/rpmsg/rpmsg_char.c | 4 ++--
> drivers/sbus/char/display7seg.c | 2 +-
> drivers/sbus/char/envctrl.c | 4 +---
> drivers/scsi/3w-.c | 4 +---
> drivers/scsi/cxlflash/main.c| 2 +-
> drivers/scsi/esas2r/esas2r_main.c | 2 +-
> drivers/scsi/pmcraid.c | 4 +---
> drivers/staging/android/ion/ion.c | 4 +---
> drivers/staging/vme/devices/vme_user.c | 2 +-
> drivers/tee/tee_core.c | 2 +-
> drivers/usb/class/cdc-wdm.c | 2 +-
> drivers/usb/class/usbtmc.c | 4 +---
> drivers/video/fbdev/ps3fb.c | 2 +-
> drivers/virt/fsl_hypervisor.c | 2 +-
> fs/btrfs/super.c| 2 +-
> fs/ceph/dir.c | 2 +-
> fs/ceph/file.c | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/notify/fanotify/fanotify_user.c | 2 +-
> fs/userfaultfd.c| 2 +-
> net/rfkill/core.c | 2 +-
> 37 files changed, 40 insertions(+), 58 deletions(-)
> diff --git a/drivers/infiniband/core/uverbs_main.c
> b/drivers/infiniband/core/uverbs_main.c
> index 823beca448e1..f4755c1c9cfa 100644
> +++ b/drivers/infiniband/core/uverbs_main.c
> @@ -930,7 +930,7 @@ static const struct file_operations uverbs_fops = {
> .release = ib_uverbs_close,
> .llseek = no_llseek,
> .unlocked_ioctl = ib_uverbs_ioctl,
> - .compat_ioctl = ib_uverbs_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> static const struct file_operations uverbs_mmap_fops = {
> @@ -941,7 +941,7 @@ static const struct file_operations uverbs_mmap_fops = {
> .release = ib_uverbs_close,
> .llseek = no_llseek,
> .unlocked_ioctl = ib_uverbs_ioctl,
> - .compat_ioctl = ib_uverbs_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> static struct ib_client uverbs_client = {
For uverbs:
Acked-by: Jason Gunthorpe
It is very strange, this patch did not appear in the RDMA patchworks,
I almost missed it :|
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote: > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > > > Acked-by: Darren Hart (VMware) > > > > > > As for a longer term solution, would it be possible to init fops in such > > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg > > > so we don't have to duplicate this boilerplate for every ioctl fops > > > structure? > > > > Bad idea, that... Because several years down the road somebody will add > > an ioctl that takes an unsigned int for argument. Without so much as > > looking > > at your magical mystery macro being used to initialize file_operations. > > Fair, being explicit in the declaration as it is currently may be > preferable then. It would be much cleaner and safer if you could arrange things to add something like this to struct file_operations: long (*ptr_ioctl) (struct file *, unsigned int, void __user *); Where the core code automatically converts the unsigned long to the void __user * as appropriate. Then it just works right always and the compiler will help address Al's concern down the road. Cheers, Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote: > On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe wrote: > > > > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote: > > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > > > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > > > > > > > Acked-by: Darren Hart (VMware) > > > > > > > > > > As for a longer term solution, would it be possible to init fops in > > > > > such > > > > > a way that the compat_ioctl call defaults to > > > > > generic_compat_ioctl_ptrarg > > > > > so we don't have to duplicate this boilerplate for every ioctl fops > > > > > structure? > > > > > > > > Bad idea, that... Because several years down the road somebody > > > > will add > > > > an ioctl that takes an unsigned int for argument. Without so much as > > > > looking > > > > at your magical mystery macro being used to initialize file_operations. > > > > > > Fair, being explicit in the declaration as it is currently may be > > > preferable then. > > > > It would be much cleaner and safer if you could arrange things to add > > something like this to struct file_operations: > > > > long (*ptr_ioctl) (struct file *, unsigned int, void __user *); > > > > Where the core code automatically converts the unsigned long to the > > void __user * as appropriate. > > > > Then it just works right always and the compiler will help address > > Al's concern down the road. > > I think if we wanted to do this with a new file operation, the best > way would be to do the copy_from_user()/copy_to_user() in the caller > as well. > > We already do this inside of some subsystems, notably drivers/media/, > and it simplifies the implementation of the ioctl handler function > significantly. We obviously cannot do this in general, both because of > traditional drivers that have 16-bit command codes (drivers/tty and others) > and also because of drivers that by accident defined the commands > incorrectly and use the wrong type or the wrong direction in the > definition. That could work well, but the first idea could be done globally and mechanically, while this would require very careful per-driver investigation. Particularly if the core code has worse performance.. ie due to kmalloc calls or something. I think it would make more sense to start by having the core do the case to __user and then add another entry point to have the core do the copy_from_user, and so on. Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] treewide: cleanup unreachable breaks
On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote: > On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote: > > > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > > From: Tom Rix > > > > > > This is a upcoming change to clean up a new warning treewide. > > > I am wondering if the change could be one mega patch (see below) or > > > normal patch per file about 100 patches or somewhere half way by > > > collecting > > > early acks. > > > > Please break it up into one-patch-per-subsystem, like normal, and get it > > merged that way. > > > > Sending us a patch, without even a diffstat to review, isn't going to > > get you very far... > > Tom, > If you're able to automate this cleanup, I suggest checking in a > script that can be run on a directory. Then for each subsystem you > can say in your commit "I ran scripts/fix_whatever.py on this subdir." > Then others can help you drive the tree wide cleanup. Then we can > enable -Wunreachable-code-break either by default, or W=2 right now > might be a good idea. I remember using clang-modernize in the past to fix issues very similar to this, if clang machinery can generate the warning, can't something like clang-tidy directly generate the patch? You can send me a patch for drivers/infiniband/* as well Thanks, Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote: > IB/hfi1: Fix fall-through warnings for Clang > IB/mlx4: Fix fall-through warnings for Clang > IB/qedr: Fix fall-through warnings for Clang > RDMA/mlx5: Fix fall-through warnings for Clang I picked these four to the rdma tree, thanks Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'
On Wed, Feb 13, 2019 at 03:04:51PM -0800, ira.we...@intel.com wrote: > From: Ira Weiny > > To facilitate additional options to get_user_pages_fast() change the > singular write parameter to be gup_flags. So now we have: long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages, struct page **pages, unsigned int gup_flags); and int get_user_pages_fast(unsigned long start, int nr_pages, unsigned int gup_flags, struct page **pages) Does this make any sense? At least the arguments should be in the same order, I think. Also this comment: /* * get_user_pages_unlocked() is suitable to replace the form: * * down_read(&mm->mmap_sem); * get_user_pages(tsk, mm, ..., pages, NULL); * up_read(&mm->mmap_sem); * * with: * * get_user_pages_unlocked(tsk, mm, ..., pages); * * It is functionally equivalent to get_user_pages_fast so * get_user_pages_fast should be used instead if specific gup_flags * (e.g. FOLL_FORCE) are not required. */ Needs some attention as the recommendation is now nonsense. Honestly a proper explanation of why two functions exist would be great at this point :) Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: skein: fixed sparse warnings related to static declarations
On Sat, Nov 08, 2014 at 04:49:18PM +0100, Niklas Svensson wrote: > drivers/staging/skein/skein_generic.c:30:5: warning: symbol 'skein256_update' > was not declared. Should it be static? > drivers/staging/skein/skein_generic.c:65:5: warning: symbol 'skein512_update' > was not declared. Should it be static? > drivers/staging/skein/skein_generic.c:100:5: warning: symbol > 'skein1024_update' was not declared. Should it be static? > > Signed-off-by: Niklas Svensson > --- > drivers/staging/skein/skein_generic.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) What tree/tag is this patch against? There've been quite a few changes to the api this time around. thx, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: skein: fixed sparse warnings related to static declarations
On Sun, Nov 09, 2014 at 07:51:36PM +0100, Niklas Svensson wrote: > > On 11/08/2014 08:56 PM, Jason Cooper wrote: > > On Sat, Nov 08, 2014 at 04:49:18PM +0100, Niklas Svensson wrote: > >> drivers/staging/skein/skein_generic.c:30:5: warning: symbol > >> 'skein256_update' was not declared. Should it be static? > >> drivers/staging/skein/skein_generic.c:65:5: warning: symbol > >> 'skein512_update' was not declared. Should it be static? > >> drivers/staging/skein/skein_generic.c:100:5: warning: symbol > >> 'skein1024_update' was not declared. Should it be static? > >> > >> Signed-off-by: Niklas Svensson > >> --- > >> drivers/staging/skein/skein_generic.c | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > > What tree/tag is this patch against? There've been quite a few changes > > to the api this time around. > > > linux-next, > tag: next-20141106 > > also applicable for gregkg's staging-next tree Perfect. Acked-by: Jason Cooper thx, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block
On 11/24/2014 01:56 PM, Dexuan Cui wrote:
> If num_ballooned is not 0, we shouldn't neglect the already-allocated 2MB
> memory block(s).
>
> Cc: K. Y. Srinivasan
> Cc:
> Signed-off-by: Dexuan Cui
> ---
> drivers/hv/hv_balloon.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 5e90c5d..cba2d3b 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -1091,6 +1091,8 @@ static void balloon_up(struct work_struct *dummy)
> bool done = false;
> int i;
>
> + /* The host does balloon_up in 2MB. */
> + WARN_ON(num_pages % PAGES_IN_2M != 0);
>
> /*
>* We will attempt 2M allocations. However, if we fail to
> @@ -,7 +1113,7 @@ static void balloon_up(struct work_struct *dummy)
> bl_resp, alloc_unit,
>&alloc_error);
>
> - if ((alloc_error) && (alloc_unit != 1)) {
> + if (alloc_error && (alloc_unit != 1) && num_ballooned == 0) {
> alloc_unit = 1;
> continue;
> }
Before the change, we may retry the 4K allocation when part or all 2M
allocations were failed. This makes sense when memory is fragmented. But
after the change, if part of 2M allocation were failed, we won't retry
4K allocation. Is this expected?
Btw, can host just require 1M? If yes, should alloc_balloon_pages() set
alloc_error if num_pages < alloc_unit for caller to catch this and retry
4K allocation?
Thanks
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block
On 11/24/2014 02:08 PM, Dexuan Cui wrote:
>> -Original Message-
>> > From: Jason Wang [mailto:jasow...@redhat.com]
>> > Sent: Monday, November 24, 2014 13:18 PM
>> > To: Dexuan Cui; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
>> > driverdev-devel@linuxdriverproject.org; o...@aepfle.de;
>> > a...@canonical.com; KY Srinivasan
>> > Cc: Haiyang Zhang
>> > Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of
>> > 2MB memory block
>> >
>> > On 11/24/2014 01:56 PM, Dexuan Cui wrote:
>>> > > If num_ballooned is not 0, we shouldn't neglect the already-allocated
>> > 2MB
>>> > > memory block(s).
>>> > >
>>> > > Cc: K. Y. Srinivasan
>>> > > Cc:
>>> > > Signed-off-by: Dexuan Cui
>>> > > ---
>>> > > drivers/hv/hv_balloon.c | 4 +++-
>>> > > 1 file changed, 3 insertions(+), 1 deletion(-)
>>> > >
>>> > > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
>>> > > index 5e90c5d..cba2d3b 100644
>>> > > --- a/drivers/hv/hv_balloon.c
>>> > > +++ b/drivers/hv/hv_balloon.c
>>> > > @@ -1091,6 +1091,8 @@ static void balloon_up(struct work_struct
>> > *dummy)
>>> > > bool done = false;
>>> > > int i;
>>> > >
>>> > > + /* The host does balloon_up in 2MB. */
>>> > > + WARN_ON(num_pages % PAGES_IN_2M != 0);
>>> > >
>>> > > /*
>>> > > * We will attempt 2M allocations. However, if we fail to
>>> > > @@ -,7 +1113,7 @@ static void balloon_up(struct work_struct
>> > *dummy)
>>> > > bl_resp, alloc_unit,
>>> > > &alloc_error);
>>> > >
>>> > > - if ((alloc_error) && (alloc_unit != 1)) {
>>> > > + if (alloc_error && (alloc_unit != 1) && num_ballooned
>>> > > == 0)
>> > {
>>> > > alloc_unit = 1;
>>> > > continue;
>>> > > }
>> >
>> > Before the change, we may retry the 4K allocation when part or all 2M
>> > allocations were failed. This makes sense when memory is fragmented. But
> Yes, but all the partially-allocated 2MB memory blocks are lost(mem leak).
>
>> > after the change, if part of 2M allocation were failed, we won't retry
>> > 4K allocation. Is this expected?
> Hi Jason,
> The patch doesn't break the "try 2MB first; then try 4K" logic:
>
> With the change, we'll retry the 2MB allocation in the next iteration of the
> same while (!done) loop -- we expect this retry will cause
> "alloc_error && (alloc_unit != 1) && num_ballooned == 0" to be true,
> so we'll later try 4K allocation, as we did before.
If I read the code correctly, if part of 2M allocation fails.
alloc_balloon_pages() will have a non zero return value with alloc_error
set. Then it will match the following check:
if ((alloc_error) || (num_ballooned == num_pages))
{
which will set done to true. So there's no second iteration of while
(!done) loop?
Probably you need something like:
if ((alloc_unit != 1) && (num_ballooned == 0)) {
alloc_unit = 1;
continue;
}
if ((alloc_unit == 1) || (num_ballooned = num_pages)) {
...
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block
On 11/24/2014 03:54 PM, Dexuan Cui wrote:
>> -Original Message-
>> From: Jason Wang [mailto:jasow...@redhat.com]
>> Sent: Monday, November 24, 2014 15:28 PM
>> To: Dexuan Cui; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
>> driverdev-devel@linuxdriverproject.org; o...@aepfle.de;
>> a...@canonical.com; KY Srinivasan
>> Cc: Haiyang Zhang
>> Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of
>> 2MB memory block
>>
>> On 11/24/2014 02:08 PM, Dexuan Cui wrote:
>>>> -Original Message-
>>>>> From: Jason Wang [mailto:jasow...@redhat.com]
>>>>> Sent: Monday, November 24, 2014 13:18 PM
>>>>> To: Dexuan Cui; gre...@linuxfoundation.org; linux-
>> ker...@vger.kernel.org;
>>>>> driverdev-devel@linuxdriverproject.org; o...@aepfle.de;
>>>>> a...@canonical.com; KY Srinivasan
>>>>> Cc: Haiyang Zhang
>>>>> Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on
>> alloc_error of
>>>>> 2MB memory block
>>>>>
>>>>> On 11/24/2014 01:56 PM, Dexuan Cui wrote:
>>>>>>> If num_ballooned is not 0, we shouldn't neglect the already-
>> allocated
>>>>> 2MB
>>>>>>> memory block(s).
>>>>>>>
>>>>>>> Cc: K. Y. Srinivasan
>>>>>>> Cc:
>>>>>>> Signed-off-by: Dexuan Cui
>>>>>>> ---
>>>>>>> drivers/hv/hv_balloon.c | 4 +++-
>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
>>>>>>> index 5e90c5d..cba2d3b 100644
>>>>>>> --- a/drivers/hv/hv_balloon.c
>>>>>>> +++ b/drivers/hv/hv_balloon.c
>>>>>>> @@ -1091,6 +1091,8 @@ static void balloon_up(struct
>> work_struct
>>>>> *dummy)
>>>>>>> bool done = false;
>>>>>>> int i;
>>>>>>>
>>>>>>> + /* The host does balloon_up in 2MB. */
>>>>>>> + WARN_ON(num_pages % PAGES_IN_2M != 0);
>>>>>>>
>>>>>>> /*
>>>>>>> * We will attempt 2M allocations. However, if we fail to
>>>>>>> @@ -,7 +1113,7 @@ static void balloon_up(struct
>> work_struct
>>>>> *dummy)
>>>>>>> bl_resp, alloc_unit,
>>>>>>> &alloc_error);
>>>>>>>
>>>>>>> - if ((alloc_error) && (alloc_unit != 1)) {
>>>>>>> + if (alloc_error && (alloc_unit != 1) &&
>> num_ballooned == 0)
>>>>> {
>>>>>>> alloc_unit = 1;
>>>>>>> continue;
>>>>>>> }
>>>>> Before the change, we may retry the 4K allocation when part or all 2M
>>>>> allocations were failed. This makes sense when memory is fragmented.
>> But
>>> Yes, but all the partially-allocated 2MB memory blocks are lost(mem leak).
>>>
>>>>> after the change, if part of 2M allocation were failed, we won't retry
>>>>> 4K allocation. Is this expected?
>>> Hi Jason,
>>> The patch doesn't break the "try 2MB first; then try 4K" logic:
>>>
>>> With the change, we'll retry the 2MB allocation in the next iteration of the
>>> same while (!done) loop -- we expect this retry will cause
>>> "alloc_error && (alloc_unit != 1) && num_ballooned == 0" to be true,
>>> so we'll later try 4K allocation, as we did before.
>> If I read the code correctly, if part of 2M allocation fails.
>> alloc_balloon_pages() will have a non zero return value with alloc_error
>> set. Then it will match the following check:
>>
>> if ((alloc_error) || (num_ballooned == num_pages))
>> {
>>
>> which will set done to true. So there's no second iteration of while
>> (!done) loop?
> Oh... I see the issue in my patch.
> Thanks for pointing this out, Jason!
>
>> Probably you need something like:
>>
>> if ((alloc_unit != 1) && (num_ballooned == 0)) {
>> alloc_u
Re: [PATCH v2] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block
On 11/25/2014 12:32 PM, Dexuan Cui wrote:
> If num_ballooned is not 0, we shouldn't neglect the
> already-partially-allocated 2MB memory block(s).
>
> Cc: Jason Wang
> Cc: K. Y. Srinivasan
> Signed-off-by: Dexuan Cui
> ---
>
> v2: I fixed the logic error in v1, pointed by Jason Wang:
> In v1: in the case of partially-allocated 2MB, alloc_error is true,
> so we'll run "done = true" and hence we won't proceed with
> the next iteration of trying 4K allocation.
>
> I also changed the WARN_ON to WARN_ON_ONCE in case the host behavior
> changes in the future.
>
> drivers/hv/hv_balloon.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 5e90c5d..b958ded 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -1087,10 +1087,12 @@ static void balloon_up(struct work_struct *dummy)
> struct dm_balloon_response *bl_resp;
> int alloc_unit;
> int ret;
> - bool alloc_error = false;
> + bool alloc_error;
> bool done = false;
> int i;
>
> + /* The host balloons pages in 2M granularity. */
> + WARN_ON_ONCE(num_pages % PAGES_IN_2M != 0);
>
> /*
>* We will attempt 2M allocations. However, if we fail to
> @@ -1107,16 +1109,18 @@ static void balloon_up(struct work_struct *dummy)
>
>
> num_pages -= num_ballooned;
> + alloc_error = false;
> num_ballooned = alloc_balloon_pages(&dm_device, num_pages,
> bl_resp, alloc_unit,
>&alloc_error);
>
> - if ((alloc_error) && (alloc_unit != 1)) {
> + if (alloc_unit != 1 && num_ballooned == 0) {
> alloc_unit = 1;
> continue;
> }
>
> - if ((alloc_error) || (num_ballooned == num_pages)) {
> + if ((alloc_unit == 1 && alloc_error) ||
> + (num_ballooned == num_pages)) {
> bl_resp->more_pages = 0;
> done = true;
> dm_device.state = DM_INITIALIZED;
Acked-by: Jason Wang
Thanks
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] hv: hv_fcopy: drop the obsolete message on transfer failure
- Original Message -
> In the case the user-space daemon crashes, hangs or is killed, we
> need to down the semaphore, otherwise, after the daemon starts next
> time, the obsolete data in fcopy_transaction.message or
> fcopy_transaction.fcopy_msg will be used immediately.
>
> Reviewed-by: Vitaly Kuznetsov
> Cc: K. Y. Srinivasan
> Signed-off-by: Dexuan Cui
> ---
>
> v2: I removed the "FCP" prefix as Greg asked.
>
> I also updated the output message a little:
> "FCP: failed to acquire the semaphore" -->
> "can not acquire the semaphore: it is benign"
>
> drivers/hv/hv_fcopy.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
> index 23b2ce2..c518ad9 100644
> --- a/drivers/hv/hv_fcopy.c
> +++ b/drivers/hv/hv_fcopy.c
> @@ -86,6 +86,15 @@ static void fcopy_work_func(struct work_struct *dummy)
>* process the pending transaction.
>*/
> fcopy_respond_to_host(HV_E_FAIL);
> +
> + /* In the case the user-space daemon crashes, hangs or is killed, we
> + * need to down the semaphore, otherwise, after the daemon starts next
> + * time, the obsolete data in fcopy_transaction.message or
> + * fcopy_transaction.fcopy_msg will be used immediately.
> + */
Looks still racy, what happens if the daemon start before down_trylock()
but after fcopy_respont_to_host() here?
> + if (down_trylock(&fcopy_transaction.read_sema))
> + pr_debug("can not acquire the semaphore: it is benign\n");
typo
> +
> }
>
> static int fcopy_handle_handshake(u32 version)
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2] hv: hv_fcopy: drop the obsolete message on transfer failure
On Thu, Nov 27, 2014 at 4:50 PM, Dexuan Cui wrote:
-Original Message-
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, November 27, 2014 15:15 PM
To: Dexuan Cui
Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
driverdev-
de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
Subject: Re: [PATCH v2] hv: hv_fcopy: drop the obsolete message on
transfer
failure
- Original Message -
> In the case the user-space daemon crashes, hangs or is killed, we
> need to down the semaphore, otherwise, after the daemon starts
next
> time, the obsolete data in fcopy_transaction.message or
> fcopy_transaction.fcopy_msg will be used immediately.
>
> Reviewed-by: Vitaly Kuznetsov
> Cc: K. Y. Srinivasan
> Signed-off-by: Dexuan Cui
> ---
>
> v2: I removed the "FCP" prefix as Greg asked.
>
> I also updated the output message a little:
> "FCP: failed to acquire the semaphore" -->
> "can not acquire the semaphore: it is benign"
>
> drivers/hv/hv_fcopy.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
> index 23b2ce2..c518ad9 100644
> --- a/drivers/hv/hv_fcopy.c
> +++ b/drivers/hv/hv_fcopy.c
> @@ -86,6 +86,15 @@ static void fcopy_work_func(struct work_struct
*dummy)
>* process the pending transaction.
>*/
> fcopy_respond_to_host(HV_E_FAIL);
> +
> + /* In the case the user-space daemon crashes, hangs or is
killed, we
> + * need to down the semaphore, otherwise, after the daemon
starts
next
> + * time, the obsolete data in fcopy_transaction.message or
> + * fcopy_transaction.fcopy_msg will be used immediately.
> + */
Looks still racy, what happens if the daemon start before
down_trylock()
but after fcopy_respont_to_host() here?
Jason,
Thanks for pointing this out!
IMO we can resolve this by adding down_trylock() in fcopy_release().
What's your opinion?
Looks better and need to cancel the timeout also here?
> + if (down_trylock(&fcopy_transaction.read_sema))
> + pr_debug("can not acquire the semaphore: it is benign\n");
typo
> +
> }
Sorry -- what typo do you mean?
s/benign/begin/ ?
Thanks,
-- Dexuan
�NrybXǧv^){.n+{zXܨ}Ơz&j:+vzZ++zfh~iz w?&)ߢf^jǫym@Aa 0hi
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure
On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui wrote:
In the case the user-space daemon crashes, hangs or is killed, we
need to down the semaphore, otherwise, after the daemon starts next
time, the obsolete data in fcopy_transaction.message or
fcopy_transaction.fcopy_msg will be used immediately.
Cc: Jason Wang
Cc: Vitaly Kuznetsov
Cc: K. Y. Srinivasan
Signed-off-by: Dexuan Cui
---
v2: I removed the "FCP" prefix as Greg asked.
I also updated the output message a little:
"FCP: failed to acquire the semaphore" -->
"can not acquire the semaphore: it is benign"
v3: I added the code in fcopy_release() as Jason Wang suggested.
I removed the pr_debug (it isn't so meaningful)and added a
comment instead.
drivers/hv/hv_fcopy.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index 23b2ce2..faa6ba6 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -86,6 +86,18 @@ static void fcopy_work_func(struct work_struct
*dummy)
* process the pending transaction.
*/
fcopy_respond_to_host(HV_E_FAIL);
+
+ /* In the case the user-space daemon crashes, hangs or is killed, we
+ * need to down the semaphore, otherwise, after the daemon starts
next
+* time, the obsolete data in fcopy_transaction.message or
+* fcopy_transaction.fcopy_msg will be used immediately.
+*
+ * NOTE: fcopy_read() happens to get the semaphore (very rare)?
We're
+* still OK, because we've reported the failure to the host.
+*/
+ if (down_trylock(&fcopy_transaction.read_sema))
+ ;
Sorry, I'm not quite understand how if () ; can help here.
Btw, a question not relate to this patch.
What happens if a daemon is resume from SIGSTOP and expires the check
here?
+
}
static int fcopy_handle_handshake(u32 version)
@@ -351,6 +363,13 @@ static int fcopy_release(struct inode *inode,
struct file *f)
*/
in_hand_shake = true;
opened = false;
+
+ if (cancel_delayed_work_sync(&fcopy_work)) {
+ /* We haven't up()-ed the semaphore(very rare)? */
+ if (down_trylock(&fcopy_transaction.read_sema))
+ ;
And this.
+ fcopy_respond_to_host(HV_E_FAIL);
+ }
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure
On Fri, Nov 28, 2014 at 4:36 PM, Dexuan Cui wrote:
-Original Message-
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Friday, November 28, 2014 14:47 PM
To: Dexuan Cui
Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
driverdev-
de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
Subject: Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message on
transfer
failure
On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui
wrote:
> In the case the user-space daemon crashes, hangs or is killed, we
> need to down the semaphore, otherwise, after the daemon starts
next
> time, the obsolete data in fcopy_transaction.message or
> fcopy_transaction.fcopy_msg will be used immediately.
>
> Cc: Jason Wang
> Cc: Vitaly Kuznetsov
> Cc: K. Y. Srinivasan
> Signed-off-by: Dexuan Cui
> ---
>
> v2: I removed the "FCP" prefix as Greg asked.
>
> I also updated the output message a little:
> "FCP: failed to acquire the semaphore" -->
> "can not acquire the semaphore: it is benign"
>
> v3: I added the code in fcopy_release() as Jason Wang suggested.
> I removed the pr_debug (it isn't so meaningful)and added a
> comment instead.
>
> drivers/hv/hv_fcopy.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
> index 23b2ce2..faa6ba6 100644
> --- a/drivers/hv/hv_fcopy.c
> +++ b/drivers/hv/hv_fcopy.c
> @@ -86,6 +86,18 @@ static void fcopy_work_func(struct work_struct
> *dummy)
>* process the pending transaction.
>*/
> fcopy_respond_to_host(HV_E_FAIL);
> +
> + /* In the case the user-space daemon crashes, hangs or is
killed, we
> + * need to down the semaphore, otherwise, after the daemon
starts
> next
> + * time, the obsolete data in fcopy_transaction.message or
> + * fcopy_transaction.fcopy_msg will be used immediately.
> + *
> + * NOTE: fcopy_read() happens to get the semaphore (very rare)?
> We're
> + * still OK, because we've reported the failure to the host.
> + */
> + if (down_trylock(&fcopy_transaction.read_sema))
> + ;
Sorry, I'm not quite understand how if () ; can help here.
Btw, a question not relate to this patch.
What happens if a daemon is resume from SIGSTOP and expires the
check
here?
Hi Jason,
My idea is: here we need down_trylock(), but in case we can't get the
semaphore, it's OK anyway:
Scenario 1):
1.1: when the daemon is blocked on the pread(), the daemon receives
SIGSTOP;
1.2: the host user runs the PowerShell Copy-VMFile command;
1.3.1: the driver reports the failure to the host user in 5s and
1.3.2: the driver down()-es the semaphore;
1.4: the daemon receives SIGCONT and it will be still blocked on the
pread().
Without the down_trylock(), in 1.4, the daemon can receive an
obsolete message.
NOTE: in this scenario, the daemon is not killed.
Scenario 2):
In senario 1), if the daemon receives SIGCONT between 1.3.1 and 1.3.2
and
do down() in fcopy_read(), it will receive the message but: the
driver has
reported the failure to the host user and the driver's 1.3.2 can't
get the
semaphore -- IMO this is acceptably OK, though in the VM, an
incomplete
file will be left there.
BTW, I think in the daemon's hv_start_fcopy() we should add a
close(target_fd) before open()-ing a new one.
Right, but how about the case when resuming from SIGSTOP but no timeout?
Looks like in this case userspace() may wait in down_interruptible()
until timeout. We probably need something like this:
if (down_interruptible(&fcopy_transaction.read_sema)) {
up(&fcopy_transaction.read_sema);
return -EINTR;
}
This should synchronize with the timeout work for sure.
But how about only schedule it after this?
It does not may sense to start the timer during interrupt
since the file may not even opened and it may take time
to handle signals?
>
> +
> }
>
> static int fcopy_handle_handshake(u32 version)
> @@ -351,6 +363,13 @@ static int fcopy_release(struct inode *inode,
> struct file *f)
>*/
> in_hand_shake = true;
> opened = false;
> +
> + if (cancel_delayed_work_sync(&fcopy_work)) {
> + /* We haven't up()-ed the semaphore(very rare)? */
> + if (down_trylock(&fcopy_transaction.read_sema))
> + ;
And this.
Scenario 3):
When the daemon exits(e.g., SIGKILL received), if there is a
fcopy_work
pending (scheduled but not start to run yet), we should cancel the
work (as you suggested) and down() the semaphore, otherwise, the
obsolete message will be received by the next instance
RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure
On Fri, Nov 28, 2014 at 7:54 PM, Dexuan Cui wrote: -Original Message- From: Jason Wang [mailto:jasow...@redhat.com] Sent: Friday, November 28, 2014 18:13 PM To: Dexuan Cui Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev- de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY Srinivasan; vkuzn...@redhat.com; Haiyang Zhang Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure On Fri, Nov 28, 2014 at 4:36 PM, Dexuan Cui wrote: >> -Original Message- >> From: Jason Wang [mailto:jasow...@redhat.com] >> Sent: Friday, November 28, 2014 14:47 PM >> To: Dexuan Cui >> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; >> driverdev- >> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY >> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang >> Subject: Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message on >> transfer >> failure >> On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui >> wrote: >> > In the case the user-space daemon crashes, hangs or is killed, we >> > need to down the semaphore, otherwise, after the daemon starts >> next >> > time, the obsolete data in fcopy_transaction.message or >> > fcopy_transaction.fcopy_msg will be used immediately. >> > >> > Cc: Jason Wang >> > Cc: Vitaly Kuznetsov >> > Cc: K. Y. Srinivasan >> > Signed-off-by: Dexuan Cui >> > --- >> > >> > v2: I removed the "FCP" prefix as Greg asked. >> > >> > I also updated the output message a little: >> > "FCP: failed to acquire the semaphore" --> >> > "can not acquire the semaphore: it is benign" >> > >> > v3: I added the code in fcopy_release() as Jason Wang suggested. >> > I removed the pr_debug (it isn't so meaningful)and added a >> > comment instead. >> > >> > drivers/hv/hv_fcopy.c | 19 +++ >> > 1 file changed, 19 insertions(+) >> > >> > diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c >> > index 23b2ce2..faa6ba6 100644 >> > --- a/drivers/hv/hv_fcopy.c >> > +++ b/drivers/hv/hv_fcopy.c >> > @@ -86,6 +86,18 @@ static void fcopy_work_func(struct work_struct >> > *dummy) >> > * process the pending transaction. >> > */ >> > fcopy_respond_to_host(HV_E_FAIL); >> > + >> > + /* In the case the user-space daemon crashes, hangs or is >> killed, we >> > +* need to down the semaphore, otherwise, after the daemon >> starts >> > next >> > +* time, the obsolete data in fcopy_transaction.message or >> > +* fcopy_transaction.fcopy_msg will be used immediately. >> > + * >> > + * NOTE: fcopy_read() happens to get the semaphore (very rare)? >> > We're >> > +* still OK, because we've reported the failure to the host. >> > +*/ >> > + if (down_trylock(&fcopy_transaction.read_sema)) >> > + ; >> >> Sorry, I'm not quite understand how if () ; can help here. >> >> Btw, a question not relate to this patch. >> >> What happens if a daemon is resume from SIGSTOP and expires the >> check >> here? > Hi Jason, > My idea is: here we need down_trylock(), but in case we can't get the > semaphore, it's OK anyway: > > Scenario 1): > 1.1: when the daemon is blocked on the pread(), the daemon receives > SIGSTOP; > 1.2: the host user runs the PowerShell Copy-VMFile command; > 1.3.1: the driver reports the failure to the host user in 5s and > 1.3.2: the driver down()-es the semaphore; > 1.4: the daemon receives SIGCONT and it will be still blocked on the > pread(). > Without the down_trylock(), in 1.4, the daemon can receive an > obsolete message. > NOTE: in this scenario, the daemon is not killed. > > Scenario 2): > In senario 1), if the daemon receives SIGCONT between 1.3.1 and 1.3.2 > and > do down() in fcopy_read(), it will receive the message but: the > driver has > reported the failure to the host user and the driver's 1.3.2 can't > get the > semaphore -- IMO this is acceptably OK, though in the VM, an > incomplete > file will be left there. > BTW, I think in the daemon's hv_start_fcopy() we should add a > close(ta
RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure
On Mon, Dec 1, 2014 at 5:47 PM, Dexuan Cui wrote: -Original Message- From: Jason Wang [mailto:jasow...@redhat.com] Sent: Monday, December 1, 2014 16:23 PM To: Dexuan Cui Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev- de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY Srinivasan; vkuzn...@redhat.com; Haiyang Zhang Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure On Fri, Nov 28, 2014 at 7:54 PM, Dexuan Cui wrote: >> -Original Message- >> From: Jason Wang [mailto:jasow...@redhat.com] >> Sent: Friday, November 28, 2014 18:13 PM >> To: Dexuan Cui >> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; >> driverdev- >> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY >> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang >> Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on >> transfer >> failure >> On Fri, Nov 28, 2014 at 4:36 PM, Dexuan Cui >> wrote: >> >> -Original Message- >> >> From: Jason Wang [mailto:jasow...@redhat.com] >> >> Sent: Friday, November 28, 2014 14:47 PM >> >> To: Dexuan Cui >> >> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; >> >> driverdev- >> >> de...@linuxdriverproject.org; o...@aepfle.de; >> a...@canonical.com; KY >> >> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang >> >> Subject: Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message >> on >> >> transfer >> >> failure >> >> On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui >> >> >> wrote: >> >> > In the case the user-space daemon crashes, hangs or is >> killed, we >> >> > need to down the semaphore, otherwise, after the daemon starts >> >> next >> >> > time, the obsolete data in fcopy_transaction.message or >> >> > fcopy_transaction.fcopy_msg will be used immediately. >> >> > >> >> > Cc: Jason Wang >> >> > Cc: Vitaly Kuznetsov >> >> > Cc: K. Y. Srinivasan >> >> > Signed-off-by: Dexuan Cui >> >> > --- >> >> > >> >> > v2: I removed the "FCP" prefix as Greg asked. >> >> > >> >> > I also updated the output message a little: >> >> > "FCP: failed to acquire the semaphore" --> >> >> > "can not acquire the semaphore: it is benign" >> >> > >> >> > v3: I added the code in fcopy_release() as Jason Wang >> suggested. >> >> > I removed the pr_debug (it isn't so meaningful)and added a >> >> > comment instead. >> >> > >> >> > drivers/hv/hv_fcopy.c | 19 +++ >> >> > 1 file changed, 19 insertions(+) >> >> > >> >> > diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c >> >> > index 23b2ce2..faa6ba6 100644 >> >> > --- a/drivers/hv/hv_fcopy.c >> >> > +++ b/drivers/hv/hv_fcopy.c >> >> > @@ -86,6 +86,18 @@ static void fcopy_work_func(struct >> work_struct >> >> > *dummy) >> >> >* process the pending transaction. >> >> >*/ >> >> > fcopy_respond_to_host(HV_E_FAIL); >> >> > + >> >> > + /* In the case the user-space daemon crashes, hangs or is >> >> killed, we >> >> > + * need to down the semaphore, otherwise, after the daemon >> >> starts >> >> > next >> >> > + * time, the obsolete data in fcopy_transaction.message or >> >> > + * fcopy_transaction.fcopy_msg will be used immediately. >> >> > + * >> >> > + * NOTE: fcopy_read() happens to get the semaphore (very >> rare)? >> >> > We're >> >> > + * still OK, because we've reported the failure to the host. >> >> > + */ >> >> > + if (down_trylock(&fcopy_transaction.read_sema)) >> >> > + ; >> >> >> >> Sorry, I'm not quite understand how if () ; can help here. >> >> >> >> Btw, a question not relate to this patch. &g
RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure
On Tue, Dec 2, 2014 at 1:33 PM, Dexuan Cui wrote: -Original Message- From: KY Srinivasan Sent: Monday, December 1, 2014 23:55 PM To: Dexuan Cui; Jason Wang Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev- de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; Haiyang Zhang Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure > -Original Message- > From: Dexuan Cui > Sent: Monday, December 1, 2014 3:01 AM > To: Jason Wang > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev- > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY > Srinivasan; vkuzn...@redhat.com; Haiyang Zhang > Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer > failure > > > -----Original Message- > > From: Jason Wang [mailto:jasow...@redhat.com] > > Sent: Monday, December 1, 2014 18:18 PM > > To: Dexuan Cui > > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > > driverdev- de...@linuxdriverproject.org; o...@aepfle.de; > > a...@canonical.com; KY Srinivasan; vkuzn...@redhat.com; Haiyang Zhang > > Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on > > transfer failure > > > > > > > > On Mon, Dec 1, 2014 at 5:47 PM, Dexuan Cui > wrote: > > >> -Original Message- > > >> From: Jason Wang [mailto:jasow...@redhat.com] > > >> Sent: Monday, December 1, 2014 16:23 PM > > >> To: Dexuan Cui > > >> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > > >> driverdev- > > >> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > > >> KY Srinivasan; vkuzn...@redhat.com; Haiyang Zhang > > >> Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on > > >> transfer failure On Fri, Nov 28, 2014 at 7:54 PM, Dexuan Cui > > >> > > >> wrote: > > >> >> -Original Message- > > >> >> From: Jason Wang [mailto:jasow...@redhat.com] >> Sent: > > >> Friday, November 28, 2014 18:13 PM >> To: Dexuan Cui >> Cc: > > >> gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; >> > > >> driverdev- >> de...@linuxdriverproject.org; o...@aepfle.de; > > >> a...@canonical.com; KY >> Srinivasan; vkuzn...@redhat.com; Haiyang > > >> Zhang >> Subject: RE: [PATCH v3] hv: hv_fcopy: drop the obsolete > > >> message on >> transfer >> failure >> On Fri, Nov 28, 2014 at > > >> 4:36 PM, Dexuan Cui >> wrote: > > >> >> >> -Original Message- >> >> From: Jason Wang > > >> [mailto:jasow...@redhat.com] >> >> Sent: Friday, November 28, > > >> 2014 14:47 PM >> >> To: Dexuan Cui >> >> Cc: > > >> gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; >> >> > > >> driverdev- >> >> de...@linuxdriverproject.org; o...@aepfle.de; > > >> >> a...@canonical.com; KY >> >> Srinivasan; vkuzn...@redhat.com; > > >> Haiyang Zhang >> >> Subject: Re: [PATCH v3] hv: hv_fcopy: drop > > >> the obsolete message >> on >> >> transfer >> >> failure >> > > >> >> On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui >> > > >> >> >> wrote: > > >> >> >> > In the case the user-space daemon crashes, hangs or is > > >> >> killed, we >> >> > need to down the semaphore, otherwise, > > >> after the daemon starts >> >> next >> >> > time, the obsolete > > >> data in fcopy_transaction.message or >> >> > > > >> fcopy_transaction.fcopy_msg will be used immediately. > > >> >> >> > > > >> >> >> > Cc: Jason Wang >> >> > Cc: > > >> Vitaly Kuznetsov >> >> > Cc: K. Y. > > >> Srinivasan >> >> > Signed-off-by: Dexuan Cui > > >> >> >> > --- >> >> > >> >> > v2: I > > >> removed the "FCP" prefix as Greg asked. > > >> >> >> > > > >> >> >> >
Re: [PATCH V2 1/1] Drivers: hv: vmbus: Implement a clockevent device
nt_page[cpu])
free_page((unsigned long)hv_context.synic_event_page[cpu]);
if (hv_context.synic_message_page[cpu])
@@ -388,6 +457,15 @@ void hv_synic_init(void *arg)
hv_context.vp_index[cpu] = (u32)vp_index;
INIT_LIST_HEAD(&hv_context.percpu_list[cpu]);
+
+ /*
+* Register the per-cpu clockevent source.
+*/
+ if (ms_hyperv.features & HV_X64_MSR_SYNTIMER_AVAILABLE)
+ clockevents_config_and_register(hv_context.clk_evt[cpu],
+ HV_TIMER_FREQUENCY,
+ HV_MIN_DELTA_TICKS,
+ HV_MAX_MAX_DELTA_TICKS);
return;
}
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index c386d8d..44b1c94 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -178,6 +178,23 @@ struct hv_message_header {
};
};
+/*
+ * Timer configuration register.
+ */
+union hv_timer_config {
+ u64 as_uint64;
+ struct {
+ u64 enable:1;
+ u64 periodic:1;
+ u64 lazy:1;
+ u64 auto_enable:1;
+ u64 reserved_z0:12;
+ u64 sintx:4;
+ u64 reserved_z1:44;
+ };
+};
+
+
/* Define timer message payload structure. */
struct hv_timer_message_payload {
u32 timer_index;
@@ -519,6 +536,10 @@ struct hv_context {
* buffer to post messages to the host.
*/
void *post_msg_page[NR_CPUS];
+ /*
+* Support PV clockevent device.
+*/
+ struct clock_event_device *clk_evt[NR_CPUS];
};
extern struct hv_context hv_context;
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 4d6b269..9e57c07 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -578,6 +579,37 @@ static void vmbus_onmessage_work(struct
work_struct *work)
kfree(ctx);
}
+void hv_process_timer_expiration(struct hv_message *msg, int cpu)
+{
+ struct clock_event_device *dev = hv_context.clk_evt[cpu];
+
+ if (msg->header.message_type == HVMSG_NONE)
+ return;
Nitpick: caller has checked this.
+
+ if (dev->event_handler)
+ dev->event_handler(dev);
+
+ msg->header.message_type = HVMSG_NONE;
+
+ /*
+* Make sure the write to MessageType (ie set to
+* HVMSG_NONE) happens before we read the
+* MessagePending and EOMing. Otherwise, the EOMing
+* will not deliver any more messages since there is
+* no empty slot
+*/
+ mb();
+
+ if (msg->header.message_flags.msg_pending) {
+ /*
+* This will cause message queue rescan to
+* possibly deliver another msg from the
+* hypervisor
+*/
+ wrmsrl(HV_X64_MSR_EOM, 0);
+ }
+}
+
static void vmbus_on_msg_dpc(unsigned long data)
{
int cpu = smp_processor_id();
@@ -667,8 +699,12 @@ static void vmbus_isr(void)
msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
/* Check if there are actual msgs to be processed */
- if (msg->header.message_type != HVMSG_NONE)
- tasklet_schedule(&msg_dpc);
+ if (msg->header.message_type != HVMSG_NONE) {
+ if (msg->header.message_type == HVMSG_TIMER_EXPIRED)
+ hv_process_timer_expiration(msg, cpu);
+ else
+ tasklet_schedule(&msg_dpc);
+ }
}
/*
--
1.7.4.1
Reviewed-by: Jason Wang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 6/6] ARM: socfpga: defconfig: enable fpga manager
On Wed, Dec 17, 2014 at 09:32:16AM -0800, Greg KH wrote: > On Wed, Dec 17, 2014 at 10:54:49AM -0600, at...@opensource.altera.com wrote: > > From: Alan Tull > > > > Enable FPGA manager for Altera socfpga. > > > > Signed-off-by: Alan Tull > > --- > > v5: s/CONFIG_FPGA_MGR_ALTERA/CONFIG_FPGA_MGR_SOCFPGA/ > > --- > > arch/arm/configs/socfpga_defconfig |4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/arm/configs/socfpga_defconfig > > b/arch/arm/configs/socfpga_defconfig > > index a2956c3..f1d6a3b 100644 > > --- a/arch/arm/configs/socfpga_defconfig > > +++ b/arch/arm/configs/socfpga_defconfig > > @@ -86,6 +86,10 @@ CONFIG_USB_DWC2=y > > CONFIG_USB_DWC2_HOST=y > > CONFIG_MMC=y > > CONFIG_MMC_DW=y > > +CONFIG_STAGING=y > > +CONFIG_FPGA=y > > +CONFIG_FPGA_MGR_SYSFS=y > > +CONFIG_FPGA_MGR_SOCFPGA=y > > CONFIG_EXT2_FS=y > > CONFIG_EXT2_FS_XATTR=y > > CONFIG_EXT2_FS_POSIX_ACL=y > > Do defconfigs really matter anymore? Very much so. arm-soc uses them as a standard build test target and boot target on their bootfarms. Please see the arm-buildbot mailinglist at: http://lists.linaro.org/mailman/listinfo/kernel-build-reports And December's results so far: http://lists.linaro.org/pipermail/kernel-build-reports/2014-December/thread.html hth, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: skein: Fixing various coding style problems
Mathieu,
On Sun, Dec 21, 2014 at 05:09:48PM -0700, mathieu.poir...@linaro.org wrote:
> From: Mathieu Poirier
>
> Fixing errors related to the usage of do {} while (0) loop
> in single statement macros, trailing semicolon in macros and
> trailing whitespace.
Huh. iirc, I added those do {} while(0)s to keep checkpatch happy.
Either it's gotten smarter, or something is off.
At any rate, the whole macro menagerie in here concerns me a bit and I'm
reluctant to change it until I have some time to refresh my memory on
what this code is doing.
It would be helpful if you could give scripts/objdiff a try on the
before and after effects of your patch. If the object code doesn't
change, then we can be more confident that the patch is just style
changes. Please also check when SKEIN_UNROLL_* is set/unset.
I really should put the patch series together to move this driver out of
staging. Then maybe folks will stop running checkpatch against it :-)
thx,
Jason.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] skein: checkpatch: trailing whitespace
Andreas,
On Tue, Dec 30, 2014 at 12:33:34AM +0100, Andreas Siegling wrote:
> This small patch will fix the trailing whitespace in
> drivers/staging/skein/skein_generic.c.
>
> After applying the patch, there will only remain the checkpatch warning:
> WARNING: Single statement macros should not use a do {} while (0) loop
> in files which are in the directory drivers/staging/skein/
>
> Signed-off-by: Andreas Siegling
> Signed-off-by: Zhutao Lu
Why do you have have two S-o-b's?
> ---
> drivers/staging/skein/skein_generic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/skein/skein_generic.c
> b/drivers/staging/skein/skein_generic.c
> index 85bd7d0..4eaae1d 100644
> --- a/drivers/staging/skein/skein_generic.c
> +++ b/drivers/staging/skein/skein_generic.c
> @@ -191,7 +191,7 @@ static int __init skein_generic_init(void)
>
> return 0;
>
> -
> +
Hmm, this extra line should just be deleted.
thx,
Jason.
> unreg512:
> crypto_unregister_shash(&alg512);
> unreg256:
> --
> 1.9.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/2] staging: skein: Fixing various coding style problems
Mathieu,
On Mon, Dec 22, 2014 at 08:20:37AM -0700, mathieu.poir...@linaro.org wrote:
> From: Mathieu Poirier
>
> This patchset is fixing miscellaneous coding style problems as reported
> by checkpatch. More interesting is the removal of 'do {} while (0) loop'
> statements for single line macros. The following provides a guarantee the
> semantic of the object code hasn't been altered by the rectification:
>
> mpoirier@t430:~/work/kernel1$
> 146320048532 staging: skein: Fixing single statement macro checkpatch warning
> ef68ffa9fd3e staging: skein: Fixing trailing whitespace error
> 97bf6af1f928 Linux 3.19-rc1
> mpoirier@t430:~/work/kernel1$ git reset --hard 97bf6af1f928
> HEAD is now at 97bf6af1f928 Linux 3.19-rc1
> mpoirier@t430:~/work/kernel1$ make drivers/staging/skein/skein_block.o
> CHK include/config/kernel.release
> UPD include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> UPD include/generated/utsrelease.h
> CALLscripts/checksyscalls.sh
> CC drivers/staging/skein/skein_block.o
> mpoirier@t430:~/work/kernel1$ ./scripts/objdiff record
> drivers/staging/skein/skein_block.o
> mpoirier@t430:~/work/kernel1$ git reset --hard 146320048532
> HEAD is now at 146320048532 staging: skein: Fixing single statement macro
> checkpatch warning
> mpoirier@t430:~/work/kernel1$ make drivers/staging/skein/skein_block.o
> CHK include/config/kernel.release
> UPD include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> UPD include/generated/utsrelease.h
> CALLscripts/checksyscalls.sh
> CC drivers/staging/skein/skein_block.o
> mpoirier@t430:~/work/kernel1$ ./scripts/objdiff record
> drivers/staging/skein/skein_block.o
> mpoirier@t430:~/work/kernel1$ ./scripts/objdiff diff 97bf6af1f928 146320048532
> mpoirier@t430:~/work/kernel1$
>
> New to this patchset:
> . Introduction of a cover letter that includes a scripts/objdiff snapshot
> . Splitting of the change set by semantic
>
> Mathieu Poirier (2):
> staging: skein: Fixing trailing whitespace error
> staging: skein: Fixing single statement macro checkpatch warning
>
> drivers/staging/skein/skein_block.c | 17 -----
> drivers/staging/skein/skein_generic.c | 1 -
> 2 files changed, 4 insertions(+), 14 deletions(-)
Awesome! For the whole series,
Acked-by: Jason Cooper
thx,
Jason.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: skein: Fix checkpatch warnings
Arno,
On Sat, Jan 10, 2015 at 04:00:47PM +0100, Arno Tiemersma wrote:
> Remove do {} while (0) loops around single statements in
> skein/skein_block.c
>
> Signed-off-by: Arno Tiemersma
> ---
> drivers/staging/skein/skein_block.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
Is this a V2? Several people have been submitting patches for this
checkpatch issue. Please check the staging ML and deconflict with other
submitters.
thx,
Jason.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: skein: Remove all do{} while (0) loop from single statement.
On Sun, Jan 11, 2015 at 03:41:05PM -0800, Shirish Gajera wrote:
> This patch fixes the checkpatch.pl warning:
>
> WARNING: Single statement macros should not use a do {} while (0) loop
>
> I remove do while from the single statement macro.
>
> Signed-off-by: Shirish Gajera
> ---
> drivers/staging/skein/skein_block.c | 31 +--
> 1 file changed, 9 insertions(+), 22 deletions(-)
Several people have submitted patches for this checkpatch warning.
Please check the mailinglist archives and deconflict with the other
submitters.
thx,
Jason.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: skein: Fix checkpatch warnings
On Mon, Jan 12, 2015 at 05:33:47PM +0300, Dan Carpenter wrote:
> On Mon, Jan 12, 2015 at 09:14:18AM -0500, Jason Cooper wrote:
> > Arno,
> >
> > On Sat, Jan 10, 2015 at 04:00:47PM +0100, Arno Tiemersma wrote:
> > > Remove do {} while (0) loops around single statements in
> > > skein/skein_block.c
> > >
> > > Signed-off-by: Arno Tiemersma
> > > ---
> > > drivers/staging/skein/skein_block.c | 16
> > > 1 file changed, 4 insertions(+), 12 deletions(-)
> >
> > Is this a V2? Several people have been submitting patches for this
> > checkpatch issue. Please check the staging ML and deconflict with other
> > submitters.
>
> Why would it be a v2?
I had asked one person to do a little extra work validating that
removing the do{}while's hadn't changed the resulting object code.
Unfortunately, I forgot who that was :( Only because there have been so
many people submitting the exact same thing, though...
> It's really normal to get a wave of people sending the exact same patch.
> There was one time where 7 people deleted the same whitespace in
> panel.c.
I suspect this is a combination of a) checkpatch.pl getting a more
enhanced handling of do{}while's in macros, and b) more folks doing the
Eudiptula (sp?) challenge.
> Don't worry too much about conflicts. It either applies when Greg reads
> it or it doesn't and he kicks off an email. Not a big deal.
Agreed from a patch management side. I was attempting to encourage the
new submitters to starting integrating the mailinglist into their
workflow.
thx,
Jason.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote: > the FPGA image. If someone wants there to be only one FPGA image on > the FGPA forever, they will probably not be using this framework; their > FPGA will probably be loaded before Linux boots up. Nonsense, loading the FPGA through Linux is much better, it avoids having to deal with this complexity in the boot loader and means that Linux can be used to locate the huge image in some kind of sensible filesystem, log failures, do any FPGA startup sequence/etc. With hotplug and DT I find this this works very well. The FPGA devices simply are not registered with the kernel until userspace gives the OK (in future a DT overload can handle this) If you keep with the notion that the DT overload specifies the matching FPGA firmware then it makes alot more sense to me to use DT overlays as the API to change the file name - not sysfs. To reload a FPGA, unload the DT overlay (this would have to disconnect all the drivers), de-program the FPGA, the load a new DT overlay, which reprograms and re-binds the new drivers. All those steps have to be done anyhow, you can't just swap the HW while drivers are attached. .. and if there are no drivers then Alan is right, this is the wrong interface for the 'FPGA as a user space co-processor' model. I would also re-iterate my earlier comments: requiring the whole FPGA image to be held in ram makes this useless for any of my applications. Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote: > There are plenty of people today who treat the FPGA as an entirely > dynamic resource. It's not like flashing a controller, its near > immediate. But this is a completely different use case. Remember, there are *megabytes* of internal state in a FPGA, and it isn't really feasible to dump/restore that state. It is one thing to context switch a maths algorithm that is built to be stateless, it is quite another to context switch between, say an ethernet core with an operating Linux Net driver doing DMA and a maths algorithm. A DT overlay approach where the overlay has to be unloaded to 'free' the FPGA makes alot of sense to me for the stateful kernel driver environment, and open/close/etc makes alot of sense for the stateless switchable userspace environment - other than sharing configuration code, is there any overlap between these use cases > Its completely dynamic and it will get more so as we switch from the > painful world of VHDL and friends to high level parallel aware language > compilers for FPGAs and everyone will be knocking up quick FPGA hacks. Only for some users. In my world FPGAs are filled with bus interface logic, ethernet controllers, memory controllers, packet processing engines, etc. This is all incredibly stateful - both in the FPGA itself, and in the Linux side w/ drviers. It certainly will not ever work in the model you are talking about. Even if the digital state could somehow be frozen, dumped and restored, all the FPGA external interface logic has *ANALOG* state that cannot ever be dump/restored. It just isn't feasible for that class of application. Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND 1/1] X86: Mark the Hyper-V clocksource as being continuous
On Tue, Jan 13, 2015 at 8:26 AM, K. Y. Srinivasan
wrote:
The Hyper-V clocksource is continuous; mark it accordingly.
Signed-off-by: K. Y. Srinivasan
Cc: stable
---
arch/x86/kernel/cpu/mshyperv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Acked-by: Jason Wang
diff --git a/arch/x86/kernel/cpu/mshyperv.c
b/arch/x86/kernel/cpu/mshyperv.c
index a450373..939155f 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -107,6 +107,7 @@ static struct clocksource hyperv_cs = {
.rating = 400, /* use this when running on Hyperv*/
.read = read_hv_clock,
.mask = CLOCKSOURCE_MASK(64),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
static void __init ms_hyperv_init_platform(void)
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Tue, Jan 13, 2015 at 04:28:47PM +, One Thousand Gnomes wrote:
> There is a lot of code overlap in things like loading the bitstreams,
> there is also some overlap because you want to be able to assign FPGA
> resources. For example if you have four FPGAs and you want to use one for
> OS stuff (say video) you want the other three to be open/close
> accessible, but if you've not got a video driver loaded and are running
> the same board headless you'd like all four to be handed out as normal
> resources.
>
> So IMHO it's no different to say kmalloc. We don't pre-empt kernel memory
> and give it to users but we don't reserve memory for kernel and not use
> it.
I do agree with this, and I think this is where this patch set goes so
wrong.
Just exposing all sorts of controls to userspace and having a way for
the kernel to load/unload a bitstream compleletely misses the point that
the two main ways to use FPGAs *require* some kind of kernel side
driver suppport on the FPGA.
Even if it is just a maths FPGA kernel side has to be involved in some
way to restrict DMAs, MMIO, by the user process. Obviously a FPGA that
uses kernel drivers needs kernel side help to bind those drivers.
Plonking /sys/class/fpga_manager//reset for either case is more
likely than not to completely crash the system.
I would look at this problem from a completely different angle - the
90% case is a single FPGA that is loaded to provide HW that Linux
drivers bind to, these days the majority use DT.
So..
soc
{
zynq_cfg: ps7-dev-cfg@f8007000 { compatible = "xlnx,zynq-devcfg-1.0"; }
fpga@pl {
compatible = "..";
fpga,api = "gpio-api1";
fpga,controller = &zynq_cfg;
gp0_axi: axi@4000 {
gpio3: klina_gpio@80010 {
#gpio-cells = <2>;
compatible = "linux,basic-mmio-gpio";
gpio-controller;
reg-names = "dat", "set", "dirin";
reg = <0x80010 4>,
<0x80014 4>,
<0x80018 4>;
};
}
}
}
Make it so linux can boot, automatically fetch the gpio-api1 bit file
and load it into the chip and then bind the GPIO driver to the FPGA
resource. All without userspace involvment, all potentially done
before calling INIT.
Make it so via sysfs we can reverse this process and reboot the FPGA.
Make it so userspace can't do something to the FPGA without first
unloading the drivers.
Then worry about how to change the FPGA, or providing more user space
control over the process (DT overlays are a natural answer).
Providing a roll-your-own approach via a bunch of sysfs controls
satisfies the 'make the HW work' need without actually providing the
overall architecture someone needs to *make use* of this mechanism.
And no, this isn't just a 'theory', I have 4 shipping products today
that work pretty much exactly like this, including a Zynq
design. Binding kernel drivers to a FPGA once it is loaded is a big
functionality gap, and an annoying problem. Programming the actual
FPGA? That is the *EASIEST* part of this whole thing!
Honestly, I'd much rather see the above use case solved properly
without sysfs support and then go from there to build a replacable
FPGA scheme on the same concepts.
Providing a 'build your own' solution with sysfs controls just seems
to completely miss the mark to me.
> So IMHO it's no different to say kmalloc. We don't pre-empt kernel memory
> and give it to users but we don't reserve memory for kernel and not use
> it.
I think we see a kernel side with more structure, that knows when the
FPGA is in use or not, there is a pretty clear path to later add a
/dev/ scheme for user space use that can properly interlock.
A /dev/ scheme doesn't make much sense to bind kernel drivers...
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Tue, Jan 13, 2015 at 03:37:14PM -0600, atull wrote: > > I do agree with this, and I think this is where this patch set goes so > > wrong. > > > > Just exposing all sorts of controls to userspace and having a way for > > the kernel to load/unload a bitstream compleletely misses the point that > > the two main ways to use FPGAs *require* some kind of kernel side > > driver suppport on the FPGA. > > Hi Jason, > > I may be misunderstanding. I thought you wanted lots of user control > a couple years ago. > > https://lkml.org/lkml/2013/9/18/490 Yes, that is absolutely true, that is certainly where my projects have been historically, and in the context of requiring user space to manage the whole process I think that is completely right. But - I like Alan's point - this should be a higher level thing, the kernel should be able to load the FPGA, and handle binding the drivers so user space doesn't need to be involved, and it makes sense that should be the place to start the API design. > Your feedback carried a lot of weight as I've been developing this patchset > although I didn't do absolutely everything you asked for. Back then you > were asking for lots of user control including being able to reset the FPGA > and being able to know from userspace what configuration steps failed (if > any). Yes, this is all true. Since my FPGAs all seem to require a software mediated startup sequence the dream of having a DT scheme like I described is farther away for me, but I think that is not the 90% case. Almost all vendor IP designs do not require a SW startup and auto-start after programming. 90% of designs can program and then immediately connect drivers. > I'm glad you like DT support for FPGA images + drivers loading since I've > been pushing that since April and have submitted several earlier versions > of this patchset which included it. Yes, I do, thank you for working on this! > I think your arguements against the current patchset are a bit over > the top here. Perhaps, and I apologize. But as you know I've never liked the sysfs interface, and I think Pavel is right. catting a file name just so you can call request_firmware on that file in the kernel is a bad design. The request_firmware interface should be for the DT overlay path, and other schemes shouldn't use it. The name should come from the DT and no place else. > > Make it so linux can boot, automatically fetch the gpio-api1 bit file > > and load it into the chip and then bind the GPIO driver to the FPGA > > resource. All without userspace involvment, all potentially done > > before calling INIT. > > Where would the fpga image be fetch from? What is the mechanism for > doing that? Do we need to reqire everybody to do that or can > firmware be one of the available mechanisms? I see there are three options: 1) The bootloader programs the FPGA and passes a DT to the kernel that completely describes the hard and soft logic, the kernel doesn't need FPGA bitfile management code or other special support. Obviously things like reprogram on resume have to be done by the bootloader, there is no handoff here where the kernel takes over control of the bitfile programming. I think that is fine, #2/#3 are better choices for most people anyhow. 2) The bootloader starts the kernel and passes a DT that describes the hard logic and soft logic using a scheme like I outlined. The kernel is responsible to request_firmware the bitfile and start the FPGA and connect the drivers. DT purists will rightly point out that this isn't great, but it is a simple and pragmatic solution. This probably falls out automatically if #3 is implemented.. 3) The bootloader starts the kernel with a DT that only describes the hard logic. Userspace must load a DT overlay early on. Otherwise proceeds like #2. In both 2 and 3 the FPGA can be reprogrammed on resume by re-doing request_firmware. And for folks that need more control, expose all the knobs explicitly to user space: 4) There is a /dev/ node for the fpga that allows - ioctl to program via mmap'd file (no request_firmware) The ioctl has an option for the kernel to hang on to the mmap for the repogram on resume case. - ioctl to get status/error reporting/etc - ioctl to load/bind a DT overlay to the FPGA instance This provides a gap where userspace can boot and configure the FPGA internals before binding the kernel drivers. (end result is the same as #3 case, but no request_firmware) - (future) ioctl to load a swappable FPGA (what Alan is talking about) The key thing is that we have a FPGA object that can be associated with some DT element, and the kernel can then keep track if the FPGA is is in use
RE: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure
On Wed, Jan 14, 2015 at 9:43 AM, Dexuan Cui wrote: -Original Message- From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] Sent: Tuesday, January 13, 2015 21:52 PM To: Dexuan Cui; KY Srinivasan Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev- de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Haiyang Zhang Subject: Re: [PATCH v3] hv: hv_fcopy: drop the obsolete message on transfer failure Dexuan Cui writes: > In the case the user-space daemon crashes, hangs or is killed, we > need to down the semaphore, otherwise, after the daemon starts next > time, the obsolete data in fcopy_transaction.message or > fcopy_transaction.fcopy_msg will be used immediately. It seems this patch got lost and I don't see it in recent 'resend' series. K.Y., Dexuan, can you please take a look? Hi Vitaly, Jason, The patch can't fix all the corner cases (it would need non-trivial efforts for that) as we discussed, but I think it would be better for us to have it as it can indeed fix an obvious issue and doesn't introduce new issues. I think I can document the known discussed corner cases in the patch as TODOs and resend the patch. Please let me know if you have different opinions. :-) Thanks, -- Dexuan Yes, I think it's ok. We can do other fixes on top. Thanks ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote: > and I think you effectively have the user usage covered here for such > things. It much like GPIO pins - we can describe them but we can also > declare they are not visible to the user. A missing element in mainline is a kind of VFIO scheme to let user space access the FPGA registers designated for user space use. We have been using these patches since 2.6.16 to allow user space to access the FPGA register resources via a PCI like /sys/../resource0 mmapable: https://github.com/jgunthorpe/linux/commit/59d5d13ddeffa8980ccc6248ebb5f1678ccb23f4 https://github.com/jgunthorpe/linux/commit/7c29c4344627be8a3906d64d32db533bc131df86 https://github.com/jgunthorpe/linux/commit/e41bb4a197368a9d505d66b627aee82f2d2b8895 We deliberately split up the FPGA registers and the assign user space permissions to the resource0 files in a way that makes sense for our app. Typically there are 10-20 FPGA register regions. User space does not access register regions that control DMA. > The swappable case mostly comes out of the /dev node. Once you have the > dev node it becomes a detail of the OS not the FPGA driver as to who may > open it, and how it is handed about. It might be an FPU manager daemon it > might not. Right, but the thing that scares me about the swappable case is the kernel side support.. The FPGA has to connect to the CPU in some way, it must have some address assigned, etc. Swapping needs to take care of all those details in some way. A fixed bus interface block and dynamic reconfiguration for the remainder is probably the way to manage that. But, that implies that even a family of swappable FPGAs will have a DT overlay associated with it. Ideally, I could see wanting to have a file format that combines the overlay and FPGA bitfile. A loader tool would use the /dev/ interface to setup both elements. That would be much more robust than the current scheme I see (eg Xilinx) using where the bitfile and DT bit live in completely different places and have to be perfectly matched. Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: skein: Remove all do{} while (0) loop from single statement.
Shirish,
Please don't toppost, I've corrected it below.
On Mon, Jan 12, 2015 at 11:14:57AM -0800, shirish gajera wrote:
> On Mon, Jan 12, 2015 at 6:15 AM, Jason Cooper wrote:
> > On Sun, Jan 11, 2015 at 03:41:05PM -0800, Shirish Gajera wrote:
> > > This patch fixes the checkpatch.pl warning:
> > >
> > > WARNING: Single statement macros should not use a do {} while (0) loop
> > >
> > > I remove do while from the single statement macro.
> > >
> > > Signed-off-by: Shirish Gajera
> > > ---
> > > drivers/staging/skein/skein_block.c | 31 +--
> > > 1 file changed, 9 insertions(+), 22 deletions(-)
> >
> > Several people have submitted patches for this checkpatch warning.
> > Please check the mailinglist archives and deconflict with the other
> > submitters.
>
> It did't see any other submitter in script.
>
> Is there any other way to check ?
The mailing list for the linux-staging tree is rather arcane to find,
it's not linux-staging@... Here's the link for joining:
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
And here's the archives:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/
hth,
Jason.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Thu, Jan 15, 2015 at 10:34:39AM -0600, atull wrote: > This is great! The way I had it working was using Pantelis' devicetree > configfs interface. I figured you were very close to this already in your overlay work.. > The DT fragment described the FPGA logic and included a filename > for firmware to load. In another branch of this thread, I see discussion > starting on what the overlay should look like and whether it could somehow > contain the DT itself. It is a novel idea, my concern would be that embedding the FPGA in the DT makes it permanent unswappable kernel memory. Not having the kernel hold the FPGA is best for many uses. Having the kernel hold the FPGA as a swppable file handle/mmap of some sort is next best (obviously the fs must be operating during resume) Unswappable kernel memory is the worst choice > Long ago this driver started out with a /dev interface. It didn't have > an ioctl yet at that point, but programming the fpga was by opening > the devnode and writing to it. Greg KH preferred sysfs or configfs > over adding another ioctl: I think to justify the ioctls you need a reason to have the context of a FD. sysfs is stateless, so if my process dies the kernel doesn't know. But now that we are talking about adding locking and ownership concepts a FD is the natural anchor for that in user space. Ie, if I open the dev node, program a FPGA and then crash the kernel doesn't attach drivers, and immediately de-programs the chip. Userspace has to make it all the way through to the DT bind before the FPGA lifetime would exceed the FD. > https://lkml.org/lkml/2013/10/8/677 I think Greg's reply makes sense in the context of the question being asked. Thinking of the FPGA as lockable ref counted kind of resource changes the question somewhat. Identifying the ioctls needed would probably clarify things. My rough start would be - Get status: programed, not programmed, error? Bitfile type? (eg Xilinx has nearly every permutation of bit/byte ordering) - Start Program with with some kind of context (ie this a new bit file, partial reconfiguration basis X, partial reconfiguration overlay on X) - for (;;) write() to do programming - Get Error to return detailed failure information (CRC error, auth error, etc) - Hand over to a DT overlay (how does this work?) Lock transfers from FD to kernel - .. something something VFIO .. ? Where start program is refused if the FPGA is already locked, and locks it Where start program -> close() returns the FPGA back to reset and unlocks Where start program -> hand over -> close() keeps the FPGA loaded with kernel drivers attached and fpga locked (remove the overlay to de-program and unlock) Not sure exactly how to tie together DT overlays with the FPGA state, but that seems the natural combination.. Not sure about partial reconfiguration - clearly the kernel needs to know and check that the bitfiles are of the correct family, I wonder if the approach should be to program a basis on the FPGA which then creates a new FPGA device in the system that can accept the partial reconfiguration - this way the locking makes sense, the basis is locked by the kernel and devices and the overlay remains lockable/swappable/whatever by a dedicated /dev/ node ?? Just thinking aloud, I've never had a use case for partial reconfiguration. Jason ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Thu, Jan 15, 2015 at 08:45:02PM +, One Thousand Gnomes wrote:
> > - Hand over to a DT overlay (how does this work?) Lock transfers
> > from FD to kernel
>
> That bit isn't stateful so I would actually have expected something in
> the kernel ABI along the lines of
>
>request_fpga(blah)
>
> which does
>
> if in use by user
> EBUSY
> lock it (all user opens will fail)
>
> and
>
> release_fpga(blah)
I am imagining two ways to start a kernel FPGA, the in-kernel method
triggered by a DT node:
fpga = request_and_lock_fpga(of_get_fpga_controller(dev->of_node))
fw = request_firmat(of_get_fpga_firmware(dev->of_node));
fpga_program_fw(fpga, fw);
for_each_child_of_node(dev->of_node, child)
.. of_platform_bus_probe(child ... ) ..
.. somehow fpga and its lock transfer to dev->of_node ..
The problem with this is it assumes the FPGA is ready to go
immediately after fpga_program_fw. There are a few platforms that can
manage this, but many others require at least some kind of startup
sequence - eg wait for clocking PLLs to lock, do low level setup, etc.
For very common cases (like Zynq can have a pretty common setup scheme
for the PL side) the DT binding can guide the kernel to run the right
code, and the code can live in the kernel because it is simple and
broadly useful.
For wild cases I'd like to just punt the setup code to user space. It
is safer and simpler to run that complexity in a user process than in
the kernel.
Maybe there is a better way to handle this, but I have been under the
impression that these days it is frowned on for the kernel to wait for
userspace?
So my idea is to use the user space method to also load a 'kernel'
fpga, the process follows the kernel flow:
fd = open("/dev/fpga0"); // request_and_lock_fpga
ioctl(fd,START_PROGRAMMING); // fpga_program_fw
write(fd,fw,fw_size);
// Arbitary complexity here
userspace_setup_fpga();
icotl(fd,BIND_DT_OVERLAY, .. ?? ..) // for_each_child_of_node
This is what the state is about, if the setup fails I expect the
kernel to go and unlock and deprogram the FPGA if fd is closed. Only a
success on BIND_DT_OVERLAY will make the FPGA permanent beyond closing
fd.
Pantelis: I think this explains why a fd and ioctls. configfs, sysfs,
etc lack the FD context to do the cleanup.
Essentially, I think a running FPGA should always be attached to some
context that is the user - either the user is in-kernel (a DT of_node)
or the user is in userspace (the fd).
The invarient is - if there is no user then the kernel automatically
makes the FPGA deprogrammed.
Having a device that is potentially attached to the CPU bus running
'rouge' is dangerous. We can't realistically deprogram it safely if we
don't know what it is doing. Eg deprogramming in the middle of a DMA
operation between the CPU and FPGA will often crash the entire system.
The only way to provide reasonable safe guards is to have a clear
chain of ownership. When the kernel takes ownership of the FPGA it
also takes ownership of any cleanup required prior to deprogram.
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: use exact allocation for dma coherent memory
On Mon, Jun 17, 2019 at 10:33:42AM +0200, Christoph Hellwig wrote:
> > drivers/infiniband/hw/cxgb4/qp.c
> >129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
> >130 {
> >131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> > sq->memsize,
> >132 &(sq->dma_addr), GFP_KERNEL);
> >133 if (!sq->queue)
> >134 return -ENOMEM;
> >135 sq->phys_addr = virt_to_phys(sq->queue);
> >136 dma_unmap_addr_set(sq, mapping, sq->dma_addr);
> >137 return 0;
> >138 }
> >
> > Is this a bug?
>
> Yes. This will blow up badly on many platforms, as sq->queue
> might be vmapped, ioremapped, come from a pool without page backing.
Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..
Potnuri, you should fix this..
You probably need to use dma_mmap_from_dev_coherent() in the mmap ?
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/3][v4.9.y] coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping
On Tue, Jun 25, 2019 at 02:33:04AM +0530, Ajay Kaher wrote:
> This patch is the extension of following upstream commit to fix
> the race condition between get_task_mm() and core dumping
> for IB->mlx4 and IB->mlx5 drivers:
>
> commit 04f5866e41fb ("coredump: fix race condition between
> mmget_not_zero()/get_task_mm() and core dumping")'
>
> Thanks to Jason for pointing this.
>
> Signed-off-by: Ajay Kaher
> ---
> drivers/infiniband/hw/mlx4/main.c | 4 +++-
> drivers/infiniband/hw/mlx5/main.c | 3 +++
> 2 files changed, 6 insertions(+), 1 deletion(-)
Looks OK
Reviewed-by: Jason Gunthorpe
Thanks
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
On Fri, May 25, 2018 at 05:32:52PM -0700, Greg Thelen wrote:
> On Fri, May 25, 2018 at 2:32 PM Arnd Bergmann wrote:
>
> > Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
> > on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> > link error when another driver using it is built-in. The
> > INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> > a 'bool' symbol that does not force anything to be a module in turn.
>
> > fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> > smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> > net/9p/trans_rdma.o: In function `rdma_request':
> > trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> > net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> > trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> > trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
>
> > Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig
> dependencies")
> > Signed-off-by: Arnd Bergmann
>
> Acked-by: Greg Thelen
>
> Sorry for the 9533b292a7ac problem.
> At this point the in release cycle, I think Arnd's revert is best.
>
> If there is interest, I've put a little thought into an alternative fix:
> making INFINIBAND_ADDR_TRANS tristate. But it's nontrivial.
> So I prefer this simple revert for now.
Is that a normal thing to do?
> Doug: do you need anything from me on this?
I can take the revert..
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
On Fri, May 25, 2018 at 11:29:59PM +0200, Arnd Bergmann wrote:
> Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
> on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> link error when another driver using it is built-in. The
> INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> a 'bool' symbol that does not force anything to be a module in turn.
>
> fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_request':
> trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
>
> Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig dependencies")
> Signed-off-by: Arnd Bergmann
> Acked-by: Greg Thelen
> ---
> The patch that introduced the problem has been queued in the
> rdma-fixes/for-rc tree. Please revert the patch before sending
> the branch to Linus.
> ---
> drivers/infiniband/ulp/srpt/Kconfig | 2 +-
> drivers/nvme/host/Kconfig | 2 +-
> drivers/nvme/target/Kconfig | 2 +-
> drivers/staging/lustre/lnet/Kconfig | 2 +-
> fs/cifs/Kconfig | 2 +-
> net/9p/Kconfig | 2 +-
> net/rds/Kconfig | 2 +-
> net/sunrpc/Kconfig | 2 +-
> 8 files changed, 8 insertions(+), 8 deletions(-)
Applied to for-rc, thanks
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vc04_services: remove set but not used 'local_entity_uc'
Fix the following gcc warning: drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:2356:16: warning: variable ‘local_entity_uc’ set but not used [-Wunused-but-set-variable] int local_uc, local_entity_uc; ^~~ Reported-by: Hulk Robot Signed-off-by: Jason Yan --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c index a1ea9777a444..2d3e114f4a66 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c @@ -2353,7 +2353,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service, enum vchiq_status ret = VCHIQ_SUCCESS; char entity[16]; int *entity_uc; - int local_uc, local_entity_uc; + int local_uc; if (!arm_state) goto out; @@ -2377,7 +2377,7 @@ vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service, write_lock_bh(&arm_state->susp_res_lock); local_uc = ++arm_state->videocore_use_count; - local_entity_uc = ++(*entity_uc); + ++(*entity_uc); vchiq_log_trace(vchiq_susp_log_level, "%s %s count %d, state count %d", -- 2.17.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: remove some variables in hal_btcoex.c
Fix the following gcc warning:
drivers/staging/rtl8723bs/hal/hal_btcoex.c:45:26: warning: ‘ioStaString’
defined but not used [-Wunused-const-variable=]
static const char *const ioStaString[] = {
^~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:38:26: warning:
‘h2cStaString’ defined but not used [-Wunused-const-variable=]
static const char *const h2cStaString[] = {
^~~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:33:26: warning:
‘BtLinkRoleString’ defined but not used [-Wunused-const-variable=]
static const char *const BtLinkRoleString[] = {
^~~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:23:26: warning:
‘BtSpecString’ defined but not used [-Wunused-const-variable=]
static const char *const BtSpecString[] = {
^~~~
drivers/staging/rtl8723bs/hal/hal_btcoex.c:15:26: warning:
‘BtProfileString’ defined but not used [-Wunused-const-variable=]
static const char *const BtProfileString[] = {
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/hal/hal_btcoex.c | 43 --
1 file changed, 43 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
index d5793e4614bf..a6ed1bb9945e 100644
--- a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
+++ b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
@@ -12,49 +12,6 @@
#include
/* Global variables */
-static const char *const BtProfileString[] = {
- "NONE",
- "A2DP",
- "PAN",
- "HID",
- "SCO",
-};
-
-static const char *const BtSpecString[] = {
- "1.0b",
- "1.1",
- "1.2",
- "2.0+EDR",
- "2.1+EDR",
- "3.0+HS",
- "4.0",
-};
-
-static const char *const BtLinkRoleString[] = {
- "Master",
- "Slave",
-};
-
-static const char *const h2cStaString[] = {
- "successful",
- "h2c busy",
- "rf off",
- "fw not read",
-};
-
-static const char *const ioStaString[] = {
- "success",
- "can not IO",
- "rf off",
- "fw not read",
- "wait io timeout",
- "invalid len",
- "idle Q empty",
- "insert waitQ fail",
- "unknown fail",
- "wrong level",
- "h2c stopped",
-};
BTC_COEXIST GLBtCoexist;
static u8 GLBtcWiFiInScanState;
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: remove defined but not used 'dB_Invert_Table'
Fix the following gcc warning:
drivers/staging/rtl8723bs/hal/odm.c:10:18: warning: ‘dB_Invert_Table’
defined but not used [-Wunused-const-variable=]
static const u16 dB_Invert_Table[8][12] = {
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/hal/odm.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/odm.c
b/drivers/staging/rtl8723bs/hal/odm.c
index aa6631ee4ea7..f2a9e95a1563 100644
--- a/drivers/staging/rtl8723bs/hal/odm.c
+++ b/drivers/staging/rtl8723bs/hal/odm.c
@@ -7,19 +7,6 @@
#include "odm_precomp.h"
-static const u16 dB_Invert_Table[8][12] = {
- {1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4},
- {4, 5, 6, 6, 7, 8, 9, 10, 11, 13, 14, 16},
- {18, 20, 22, 25, 28, 32, 35, 40, 45, 50, 56, 63},
- {71, 79, 89, 100, 112, 126, 141, 158, 178, 200, 224, 251},
- {282, 316, 355, 398, 447, 501, 562, 631, 708, 794, 891, 1000},
- {1122, 1259, 1413, 1585, 1778, 1995, 2239, 2512, 2818, 3162, 3548,
3981},
- {4467, 5012, 5623, 6310, 7079, 7943, 8913, 1, 11220, 12589, 14125,
-15849},
- {17783, 19953, 22387, 25119, 28184, 31623, 35481, 39811, 44668, 50119,
-56234, 65535}
- };
-
/* Global var */
u32 OFDMSwingTable[OFDM_TABLE_SIZE] = {
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: mt7621-pinctrl: Use correct pointer type argument for sizeof
Fix the following coccicheck warning: drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c:223:14-36: WARNING: Use correct pointer type argument for sizeof Signed-off-by: Jason Yan --- drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c index d0f06790d38f..8883f2a8ea57 100644 --- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c +++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c @@ -220,7 +220,7 @@ static int rt2880_pinmux_index(struct rt2880_priv *p) /* allocate our function and group mapping index buffers */ f = p->func = devm_kcalloc(p->dev, p->func_count, - sizeof(struct rt2880_pmx_func), + sizeof(struct rt2880_pmx_func *), GFP_KERNEL); gpio_func.groups = devm_kcalloc(p->dev, p->group_count, sizeof(int), GFP_KERNEL); -- 2.21.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-pinctrl: Use correct pointer type argument for sizeof
在 2020/4/20 20:19, Dan Carpenter 写道: On Mon, Apr 20, 2020 at 08:37:55PM +0800, Jason Yan wrote: Fix the following coccicheck warning: drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c:223:14-36: WARNING: Use correct pointer type argument for sizeof Signed-off-by: Jason Yan --- drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c index d0f06790d38f..8883f2a8ea57 100644 --- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c +++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c @@ -220,7 +220,7 @@ static int rt2880_pinmux_index(struct rt2880_priv *p) /* allocate our function and group mapping index buffers */ f = p->func = devm_kcalloc(p->dev, p->func_count, - sizeof(struct rt2880_pmx_func), + sizeof(struct rt2880_pmx_func *), Yes. This fixes a bug. We were allocating too much data. But the prefered style is: sizeof(*p->func), Please could you resend? Sure, I will cook a new one. regards, dan carpenter . ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: mt7621-pinctrl: Use correct pointer type argument for sizeof
Fix the following coccicheck warning: drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c:223:14-36: WARNING: Use correct pointer type argument for sizeof Signed-off-by: Jason Yan --- drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c index d0f06790d38f..caaf9e34f1ee 100644 --- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c +++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c @@ -220,7 +220,7 @@ static int rt2880_pinmux_index(struct rt2880_priv *p) /* allocate our function and group mapping index buffers */ f = p->func = devm_kcalloc(p->dev, p->func_count, - sizeof(struct rt2880_pmx_func), + sizeof(*p->func), GFP_KERNEL); gpio_func.groups = devm_kcalloc(p->dev, p->group_count, sizeof(int), GFP_KERNEL); -- 2.21.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: mt7621-pinctrl: Use correct pointer type argument for sizeof
Fix the following coccicheck warning: drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c:223:14-36: WARNING: Use correct pointer type argument for sizeof Signed-off-by: Jason Yan --- v2->v3: Add this description of v1->v2. v1->v2: Use sizeof(*p->func) instead of sizeof(struct rt2880_pmx_func *) suggested by Dan Carpenter. drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c index d0f06790d38f..caaf9e34f1ee 100644 --- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c +++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c @@ -220,7 +220,7 @@ static int rt2880_pinmux_index(struct rt2880_priv *p) /* allocate our function and group mapping index buffers */ f = p->func = devm_kcalloc(p->dev, p->func_count, - sizeof(struct rt2880_pmx_func), + sizeof(*p->func), GFP_KERNEL); gpio_func.groups = devm_kcalloc(p->dev, p->group_count, sizeof(int), GFP_KERNEL); -- 2.21.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: mt7621-pinctrl: Use correct pointer type argument for sizeof
在 2020/4/20 21:07, Greg KH 写道: On Mon, Apr 20, 2020 at 08:41:51PM +0800, Jason Yan wrote: Fix the following coccicheck warning: drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c:223:14-36: WARNING: Use correct pointer type argument for sizeof Signed-off-by: Jason Yan --- drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) What changed from v1? Always put that below the --- line. Please fix up and send a v3. OK. thanks, greg k-h . ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: remove set but not used 'pregistrypriv'
Fix the following gcc warning:
drivers/staging/rtl8723bs/hal/sdio_halinit.c:547:24: warning: variable
‘pregistrypriv’ set but not used [-Wunused-but-set-variable]
struct registry_priv *pregistrypriv;
^
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/hal/sdio_halinit.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
index 7853af53051d..e42d8c18e1ae 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
@@ -544,13 +544,9 @@ static void _InitRetryFunction(struct adapter *padapter)
static void HalRxAggr8723BSdio(struct adapter *padapter)
{
- struct registry_priv *pregistrypriv;
u8 valueDMATimeout;
u8 valueDMAPageCount;
-
- pregistrypriv = &padapter->registrypriv;
-
valueDMATimeout = 0x06;
valueDMAPageCount = 0x06;
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: remove set but not used 'pregistrypriv'
Sorry, it has already been fixed by YueHaibing. Please ignore this.
在 2020/4/26 17:43, Jason Yan 写道:
Fix the following gcc warning:
drivers/staging/rtl8723bs/hal/sdio_halinit.c:547:24: warning: variable
‘pregistrypriv’ set but not used [-Wunused-but-set-variable]
struct registry_priv *pregistrypriv;
^
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/hal/sdio_halinit.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
index 7853af53051d..e42d8c18e1ae 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
@@ -544,13 +544,9 @@ static void _InitRetryFunction(struct adapter *padapter)
static void HalRxAggr8723BSdio(struct adapter *padapter)
{
- struct registry_priv *pregistrypriv;
u8 valueDMATimeout;
u8 valueDMAPageCount;
-
- pregistrypriv = &padapter->registrypriv;
-
valueDMATimeout = 0x06;
valueDMAPageCount = 0x06;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/7] staging: rtl8723bs: core: remove set but not used 'pwrpriv'
Fix the following gcc warning:
drivers/staging/rtl8723bs/core/rtw_mlme.c:1100:24: warning: variable
‘pwrpriv’ set but not used [-Wunused-but-set-variable]
struct pwrctrl_priv *pwrpriv;
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index d7a58af76ea0..abf60c92c1ac 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -1097,9 +1097,6 @@ inline void rtw_indicate_scan_done(struct adapter
*padapter, bool aborted)
(!adapter_to_pwrctl(padapter)->bInSuspend) &&
(!check_fwstate(&padapter->mlmepriv,
WIFI_ASOC_STATE|WIFI_UNDER_LINKING))) {
- struct pwrctrl_priv *pwrpriv;
-
- pwrpriv = adapter_to_pwrctl(padapter);
rtw_set_ips_deny(padapter, 0);
_set_timer(&padapter->mlmepriv.dynamic_chk_timer, 1);
}
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/7] staging: rtl8723bs: core: remove set but not used 'algthm'
Fix the following gcc warning:
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1087:33: warning: variable
‘algthm’ set but not used [-Wunused-but-set-variable]
unsigned int seq, len, status, algthm, offset;
^~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 8f9da1d49343..5adc3dad8d7c 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1084,7 +1084,7 @@ unsigned int OnAuth(struct adapter *padapter, union
recv_frame *precv_frame)
unsigned int OnAuthClient(struct adapter *padapter, union recv_frame
*precv_frame)
{
- unsigned intseq, len, status, algthm, offset;
+ unsigned intseq, len, status, offset;
unsigned char *p;
unsigned intgo2asoc = 0;
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
@@ -1103,7 +1103,6 @@ unsigned int OnAuthClient(struct adapter *padapter, union
recv_frame *precv_fram
offset = (GetPrivacy(pframe)) ? 4 : 0;
- algthm = le16_to_cpu(*(__le16 *)((SIZE_PTR)pframe + WLAN_HDR_A3_LEN +
offset));
seq = le16_to_cpu(*(__le16 *)((SIZE_PTR)pframe + WLAN_HDR_A3_LEN +
offset + 2));
status = le16_to_cpu(*(__le16 *)((SIZE_PTR)pframe + WLAN_HDR_A3_LEN +
offset + 4));
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/7] staging: rtl8723bs: core: remove set but not used 'listen_interval'
Fix the following gcc warning:
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1173:18: warning: variable
‘listen_interval’ set but not used [-Wunused-but-set-variable]
u16 capab_info, listen_interval;
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 5adc3dad8d7c..d6d7198dfe45 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1169,7 +1169,7 @@ unsigned int OnAuthClient(struct adapter *padapter, union
recv_frame *precv_fram
unsigned int OnAssocReq(struct adapter *padapter, union recv_frame
*precv_frame)
{
- u16 capab_info, listen_interval;
+ u16 capab_info;
struct rtw_ieee802_11_elems elems;
struct sta_info *pstat;
unsigned char reassoc, *p, *pos, *wpa_ie;
@@ -1215,8 +1215,6 @@ unsigned int OnAssocReq(struct adapter *padapter, union
recv_frame *precv_frame)
capab_info = RTW_GET_LE16(pframe + WLAN_HDR_A3_LEN);
/* capab_info = le16_to_cpu(*(unsigned short *)(pframe +
WLAN_HDR_A3_LEN)); */
- /* listen_interval = le16_to_cpu(*(unsigned short *)(pframe +
WLAN_HDR_A3_LEN+2)); */
- listen_interval = RTW_GET_LE16(pframe + WLAN_HDR_A3_LEN+2);
left = pkt_len - (sizeof(struct ieee80211_hdr_3addr) + ie_offset);
pos = pframe + (sizeof(struct ieee80211_hdr_3addr) + ie_offset);
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/7] staging: rtl8723bs: core: remove set but not used 'pframe'
Fix the following gcc warning:
drivers/staging/rtl8723bs/core/rtw_mlme.c:2920:6: warning: variable
‘pframe’ set but not used [-Wunused-but-set-variable]
u8 *pframe;
^~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index abf60c92c1ac..e65c5a870b46 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -2914,12 +2914,11 @@ void rtw_append_exented_cap(struct adapter *padapter,
u8 *out_ie, uint *pout_len
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct ht_priv *phtpriv = &pmlmepriv->htpriv;
u8 cap_content[8] = {0};
- u8 *pframe;
if (phtpriv->bss_coexist)
SET_EXT_CAPABILITY_ELE_BSS_COEXIST(cap_content, 1);
- pframe = rtw_set_ie(out_ie + *pout_len, EID_EXTCapability, 8,
cap_content, pout_len);
+ rtw_set_ie(out_ie + *pout_len, EID_EXTCapability, 8, cap_content,
pout_len);
}
inline void rtw_set_to_roam(struct adapter *adapter, u8 to_roam)
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/7] Staging: rtl8723bs: core: remove set but not used 'ptxservq'
Fix the following gcc warning:
drivers/staging/rtl8723bs/core/rtw_sta_mgt.c:556:19: warning: variable
‘ptxservq’ set but not used [-Wunused-but-set-variable]
struct tx_servq *ptxservq;
^~~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/core/rtw_sta_mgt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
b/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
index 09d2ca30d653..e3f56c6cc882 100644
--- a/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
@@ -553,7 +553,6 @@ u32 rtw_init_bcmc_stainfo(struct adapter *padapter)
{
struct sta_info *psta;
- struct tx_servq *ptxservq;
u32 res = _SUCCESS;
NDIS_802_11_MAC_ADDRESS bcast_addr = {0xff, 0xff, 0xff, 0xff, 0xff,
0xff};
@@ -571,7 +570,6 @@ u32 rtw_init_bcmc_stainfo(struct adapter *padapter)
/* default broadcast & multicast use macid 1 */
psta->mac_id = 1;
- ptxservq = &(psta->sta_xmitpriv.be_q);
exit:
return _SUCCESS;
}
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/7] staging: rtl8723bs: os_dep: remove set but not used 'size'
And also remove the NULL check before kfree() because kfree() can handle
NULL pointers correctly.
Fix the following gcc warning:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:157:6: warning:
variable ‘size’ set but not used [-Wunused-but-set-variable]
u32 size = 0;
^~~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 1ba85a43f05a..b037868fbf22 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -154,17 +154,6 @@ static struct ieee80211_supported_band *rtw_spt_band_alloc(
static void rtw_spt_band_free(struct ieee80211_supported_band *spt_band)
{
- u32 size = 0;
-
- if (!spt_band)
- return;
-
- if (spt_band->band == NL80211_BAND_2GHZ)
- {
- size = sizeof(struct ieee80211_supported_band)
- + sizeof(struct ieee80211_channel)*RTW_2G_CHANNELS_NUM
- + sizeof(struct ieee80211_rate)*RTW_G_RATES_NUM;
- }
kfree(spt_band);
}
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/7] staging: rtl8723bs: os_dep: remove set but not used 'uintRet'
Fix the following gcc warning:
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:2564:22: warning:
variable ‘uintRet’ set but not used [-Wunused-but-set-variable]
unsigned int uintRet = 0;
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 5059b874080e..902ac8169948 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -2561,14 +2561,16 @@ static int rtw_wps_start(struct net_device *dev,
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct iw_point *pdata = &wrqu->data;
u32 u32wps_start = 0;
-unsigned int uintRet = 0;
if ((true == padapter->bDriverStopped) || (true ==
padapter->bSurpriseRemoved) || (NULL == pdata)) {
ret = -EINVAL;
goto exit;
}
- uintRet = copy_from_user((void *)&u32wps_start, pdata->pointer, 4);
+ if (copy_from_user((void *)&u32wps_start, pdata->pointer, 4)) {
+ ret = -EFAULT;
+ goto exit;
+ }
if (u32wps_start == 0)
u32wps_start = *extra;
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/7] staging: rtl8723bs: some code cleanup
Fix some warnings of '-Wunused-but-set-variable'. Jason Yan (7): staging: rtl8723bs: os_dep: remove set but not used 'uintRet' staging: rtl8723bs: os_dep: remove set but not used 'size' Staging: rtl8723bs: core: remove set but not used 'ptxservq' staging: rtl8723bs: core: remove set but not used 'algthm' staging: rtl8723bs: core: remove set but not used 'listen_interval' staging: rtl8723bs: core: remove set but not used 'pwrpriv' staging: rtl8723bs: core: remove set but not used 'pframe' drivers/staging/rtl8723bs/core/rtw_mlme.c | 6 +- drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 7 ++- drivers/staging/rtl8723bs/core/rtw_sta_mgt.c | 2 -- drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 11 --- drivers/staging/rtl8723bs/os_dep/ioctl_linux.c| 6 -- 5 files changed, 7 insertions(+), 25 deletions(-) -- 2.21.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/7] staging: rtl8723bs: os_dep: remove set but not used 'size'
在 2020/4/28 20:28, Greg KH 写道:
On Mon, Apr 27, 2020 at 11:23:37AM +0800, Jason Yan wrote:
And also remove the NULL check before kfree() because kfree() can handle
NULL pointers correctly.
Fix the following gcc warning:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:157:6: warning:
variable ‘size’ set but not used [-Wunused-but-set-variable]
u32 size = 0;
^~~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 1ba85a43f05a..b037868fbf22 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -154,17 +154,6 @@ static struct ieee80211_supported_band *rtw_spt_band_alloc(
static void rtw_spt_band_free(struct ieee80211_supported_band *spt_band)
{
- u32 size = 0;
-
- if (!spt_band)
- return;
-
- if (spt_band->band == NL80211_BAND_2GHZ)
- {
- size = sizeof(struct ieee80211_supported_band)
- + sizeof(struct ieee80211_channel)*RTW_2G_CHANNELS_NUM
- + sizeof(struct ieee80211_rate)*RTW_G_RATES_NUM;
- }
kfree(spt_band);
}
This function can now be removed and replaced with the call to kfree(),
right? Can you send a follow-on patch to do that?
Sure.
thanks,
greg k-h
.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: os_dep: remove rtw_spt_band_free()
Now that rtw_spt_band_free() is only a direct wrapper of kfree, we can
remove it and just use kfree().
Signed-off-by: Jason Yan
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index b037868fbf22..478e10d708e9 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -152,11 +152,6 @@ static struct ieee80211_supported_band *rtw_spt_band_alloc(
return spt_band;
}
-static void rtw_spt_band_free(struct ieee80211_supported_band *spt_band)
-{
- kfree(spt_band);
-}
-
static const struct ieee80211_txrx_stypes
rtw_cfg80211_default_mgmt_stypes[NUM_NL80211_IFTYPES] = {
[NL80211_IFTYPE_ADHOC] = {
@@ -3476,7 +3471,7 @@ void rtw_wdev_free(struct wireless_dev *wdev)
if (!wdev)
return;
- rtw_spt_band_free(wdev->wiphy->bands[NL80211_BAND_2GHZ]);
+ kfree(wdev->wiphy->bands[NL80211_BAND_2GHZ]);
wiphy_free(wdev->wiphy);
--
2.21.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: remove conversion to bool in halbtcoutsrc_Get()
Fix the following coccicheck warning: drivers/staging/rtl8723bs/hal/hal_btcoex.c:410:59-64: WARNING: conversion to bool not needed here Signed-off-by: Jason Yan --- drivers/staging/rtl8723bs/hal/hal_btcoex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/hal/hal_btcoex.c b/drivers/staging/rtl8723bs/hal/hal_btcoex.c index a6ed1bb9945e..3705a60a0546 100644 --- a/drivers/staging/rtl8723bs/hal/hal_btcoex.c +++ b/drivers/staging/rtl8723bs/hal/hal_btcoex.c @@ -407,7 +407,7 @@ static u8 halbtcoutsrc_Get(void *pBtcContext, u8 getType, void *pOutBuf) break; case BTC_GET_BL_WIFI_ENABLE_ENCRYPTION: - *pu8 = padapter->securitypriv.dot11PrivacyAlgrthm == 0 ? false : true; + *pu8 = padapter->securitypriv.dot11PrivacyAlgrthm != 0; break; case BTC_GET_BL_WIFI_UNDER_B_MODE: -- 2.21.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] x86, hyperv: bypass the timer_irq_works() check
On 01/26/2014 12:42 PM, Jason Wang wrote: > On 01/25/2014 05:20 AM, H. Peter Anvin wrote: >> On 01/23/2014 10:02 PM, Jason Wang wrote: >>> This patch bypass the timer_irq_works() check for hyperv guest since: >>> >>> - It was guaranteed to work. >>> - timer_irq_works() may fail sometime due to the lpj calibration were >>> inaccurate >>> in a hyperv guest or a buggy host. >>> >>> In the future, we should get the tsc frequency from hypervisor and use >>> preset >>> lpj instead. >>> >>> Cc: K. Y. Srinivasan >>> Cc: Haiyang Zhang >>> Signed-off-by: Jason Wang >> This should be in -stable, right? >> >> -hpa >> >> > Oh, right. > > Cc: Ping, need I resend the patch or it's ok for you to apply? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net,v2] hyperv: Fix the carrier status setting
On 02/11/2014 02:15 AM, Haiyang Zhang wrote:
> Without this patch, the "cat /sys/class/net/ethN/operstate" shows
> "unknown", and "ethtool ethN" shows "Link detected: yes", when VM
> boots up with or without vNIC connected.
>
> This patch fixed the problem.
>
> Signed-off-by: Haiyang Zhang
> Reviewed-by: K. Y. Srinivasan
> ---
> drivers/net/hyperv/netvsc_drv.c | 24 +++-
> 1 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 7756118..18916f7 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -88,8 +88,12 @@ static int netvsc_open(struct net_device *net)
> {
> struct net_device_context *net_device_ctx = netdev_priv(net);
> struct hv_device *device_obj = net_device_ctx->device_ctx;
> + struct netvsc_device *nvdev;
> + struct rndis_device *rdev;
> int ret = 0;
>
> + netif_carrier_off(net);
> +
> /* Open up the device */
> ret = rndis_filter_open(device_obj);
> if (ret != 0) {
> @@ -99,6 +103,11 @@ static int netvsc_open(struct net_device *net)
>
> netif_start_queue(net);
>
> + nvdev = hv_get_drvdata(device_obj);
> + rdev = nvdev->extension;
> + if (!rdev->link_state)
What if the link status interrupt comes here at this time?
> + netif_carrier_on(net);
> +
> return ret;
> }
>
> @@ -229,15 +238,17 @@ void netvsc_linkstatus_callback(struct hv_device
> *device_obj,
> struct net_device *net;
> struct net_device_context *ndev_ctx;
> struct netvsc_device *net_device;
> + struct rndis_device *rdev;
>
> net_device = hv_get_drvdata(device_obj);
> + rdev = net_device->extension;
> +
> + rdev->link_state = status != 1;
> +
> net = net_device->ndev;
>
> - if (!net) {
> - netdev_err(net, "got link status but net device "
> - "not initialized yet\n");
> + if (!net || net->reg_state != NETREG_REGISTERED)
> return;
> - }
>
> if (status == 1) {
> netif_carrier_on(net);
> @@ -414,9 +425,6 @@ static int netvsc_probe(struct hv_device *dev,
> if (!net)
> return -ENOMEM;
>
> - /* Set initial state */
> - netif_carrier_off(net);
> -
> net_device_ctx = netdev_priv(net);
> net_device_ctx->device_ctx = dev;
> hv_set_drvdata(dev, net);
> @@ -443,8 +451,6 @@ static int netvsc_probe(struct hv_device *dev,
> }
> memcpy(net->dev_addr, device_info.mac_adr, ETH_ALEN);
>
> - netif_carrier_on(net);
> -
> ret = register_netdev(net);
> if (ret != 0) {
> pr_err("Unable to register netdev.\n");
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net,v3] hyperv: Fix the carrier status setting
On 02/13/2014 08:54 AM, Haiyang Zhang wrote:
> Without this patch, the "cat /sys/class/net/ethN/operstate" shows
> "unknown", and "ethtool ethN" shows "Link detected: yes", when VM
> boots up with or without vNIC connected.
>
> This patch fixed the problem.
>
> Signed-off-by: Haiyang Zhang
> Reviewed-by: K. Y. Srinivasan
> ---
> drivers/net/hyperv/netvsc_drv.c | 53
> ---
> 1 files changed, 38 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 7756118..7141a19 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -88,8 +88,12 @@ static int netvsc_open(struct net_device *net)
> {
> struct net_device_context *net_device_ctx = netdev_priv(net);
> struct hv_device *device_obj = net_device_ctx->device_ctx;
> + struct netvsc_device *nvdev;
> + struct rndis_device *rdev;
> int ret = 0;
>
> + netif_carrier_off(net);
> +
> /* Open up the device */
> ret = rndis_filter_open(device_obj);
> if (ret != 0) {
> @@ -99,6 +103,11 @@ static int netvsc_open(struct net_device *net)
>
> netif_start_queue(net);
>
> + nvdev = hv_get_drvdata(device_obj);
> + rdev = nvdev->extension;
> + if (!rdev->link_state)
> + netif_carrier_on(net);
> +
Maybe you can just schedule the work here and then you can drop the
rtnl_lock in netvsc_link_change() ?
> return ret;
> }
>
> @@ -229,23 +238,24 @@ void netvsc_linkstatus_callback(struct hv_device
> *device_obj,
> struct net_device *net;
> struct net_device_context *ndev_ctx;
> struct netvsc_device *net_device;
> + struct rndis_device *rdev;
>
> net_device = hv_get_drvdata(device_obj);
> + rdev = net_device->extension;
> +
> + rdev->link_state = status != 1;
> +
> net = net_device->ndev;
>
> - if (!net) {
> - netdev_err(net, "got link status but net device "
> - "not initialized yet\n");
> + if (!net || net->reg_state != NETREG_REGISTERED)
> return;
> - }
>
> + ndev_ctx = netdev_priv(net);
> if (status == 1) {
> - netif_carrier_on(net);
> - ndev_ctx = netdev_priv(net);
> schedule_delayed_work(&ndev_ctx->dwork, 0);
> schedule_delayed_work(&ndev_ctx->dwork, msecs_to_jiffies(20));
> } else {
> - netif_carrier_off(net);
> + schedule_delayed_work(&ndev_ctx->dwork, 0);
> }
> }
>
> @@ -388,17 +398,35 @@ static const struct net_device_ops device_ops = {
> * current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, add
> * another netif_notify_peers() into a delayed work, otherwise GARP packet
> * will not be sent after quick migration, and cause network disconnection.
> + * Also, we update the carrier status here.
> */
> -static void netvsc_send_garp(struct work_struct *w)
> +static void netvsc_link_change(struct work_struct *w)
> {
> struct net_device_context *ndev_ctx;
> struct net_device *net;
> struct netvsc_device *net_device;
> + struct rndis_device *rdev;
> + bool notify;
> +
> + rtnl_lock();
>
> ndev_ctx = container_of(w, struct net_device_context, dwork.work);
> net_device = hv_get_drvdata(ndev_ctx->device_ctx);
> + rdev = net_device->extension;
> net = net_device->ndev;
> - netdev_notify_peers(net);
> +
> + if (rdev->link_state) {
> + netif_carrier_off(net);
> + notify = false;
> + } else {
> + netif_carrier_on(net);
> + notify = true;
> + }
> +
> + rtnl_unlock();
> +
> + if (notify)
> + netdev_notify_peers(net);
> }
>
Looks like this forces arp_notify here. Is it expected?
Other looks good.
>
> @@ -414,13 +442,10 @@ static int netvsc_probe(struct hv_device *dev,
> if (!net)
> return -ENOMEM;
>
> - /* Set initial state */
> - netif_carrier_off(net);
> -
> net_device_ctx = netdev_priv(net);
> net_device_ctx->device_ctx = dev;
> hv_set_drvdata(dev, net);
> - INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_send_garp);
> + INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
> INIT_WORK(&net_device_ctx->work, do_set_multicast);
>
> net->netdev_ops = &device_ops;
> @@ -443,8 +468,6 @@ static int netvsc_probe(struct hv_device *dev,
> }
> memcpy(net->dev_addr, device_info.mac_adr, ETH_ALEN);
>
> - netif_carrier_on(net);
> -
> ret = register_netdev(net);
> if (ret != 0) {
> pr_err("Unable to register netdev.\n");
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net,v3] hyperv: Fix the carrier status setting
On 02/13/2014 11:04 PM, Haiyang Zhang wrote:
>
>> -Original Message-
>> From: Jason Wang [mailto:jasow...@redhat.com]
>> Sent: Wednesday, February 12, 2014 10:52 PM
>> To: Haiyang Zhang; da...@davemloft.net; net...@vger.kernel.org
>> Cc: KY Srinivasan; o...@aepfle.de; linux-ker...@vger.kernel.org; driverdev-
>> de...@linuxdriverproject.org
>> Subject: Re: [PATCH net,v3] hyperv: Fix the carrier status setting
>>
>> On 02/13/2014 08:54 AM, Haiyang Zhang wrote:
>>> Without this patch, the "cat /sys/class/net/ethN/operstate" shows
>>> "unknown", and "ethtool ethN" shows "Link detected: yes", when VM
>>> boots up with or without vNIC connected.
>>>
>>> This patch fixed the problem.
>>>
>>> Signed-off-by: Haiyang Zhang
>>> Reviewed-by: K. Y. Srinivasan
>>> ---
>>> drivers/net/hyperv/netvsc_drv.c | 53
>> ---
>>> 1 files changed, 38 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/net/hyperv/netvsc_drv.c
>>> b/drivers/net/hyperv/netvsc_drv.c index 7756118..7141a19 100644
>>> --- a/drivers/net/hyperv/netvsc_drv.c
>>> +++ b/drivers/net/hyperv/netvsc_drv.c
>>> @@ -88,8 +88,12 @@ static int netvsc_open(struct net_device *net) {
>>> struct net_device_context *net_device_ctx = netdev_priv(net);
>>> struct hv_device *device_obj = net_device_ctx->device_ctx;
>>> + struct netvsc_device *nvdev;
>>> + struct rndis_device *rdev;
>>> int ret = 0;
>>>
>>> + netif_carrier_off(net);
>>> +
>>> /* Open up the device */
>>> ret = rndis_filter_open(device_obj);
>>> if (ret != 0) {
>>> @@ -99,6 +103,11 @@ static int netvsc_open(struct net_device *net)
>>>
>>> netif_start_queue(net);
>>>
>>> + nvdev = hv_get_drvdata(device_obj);
>>> + rdev = nvdev->extension;
>>> + if (!rdev->link_state)
>>> + netif_carrier_on(net);
>>> +
>> Maybe you can just schedule the work here and then you can drop the
>> rtnl_lock in netvsc_link_change() ?
> The rtnl_lock will still be necessary in the netvsc_link_change(), because
> we want to prevent it getting wrong rdev pointer when netvsc_change_mtu
> is removing/adding rndis device.
Ok.
>>> +
>>> + if (notify)
>>> + netdev_notify_peers(net);
>>> }
>>>
>> Looks like this forces arp_notify here. Is it expected?
> Yes, this is expected. It's required after live migration.
>
> Thanks,
> - Haiyang
Yes, this does not change the current behaviour. (arp_notify is
meaningless for netvsc).
Acked-by: Jason Wang
The patch is also needed for stable.
Thanks
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND] x86, hyperv: bypass the timer_irq_works() check
This patch bypass the timer_irq_works() check for hyperv guest since:
- It was guaranteed to work.
- timer_irq_works() may fail sometime due to the lpj calibration were inaccurate
in a hyperv guest or a buggy host.
In the future, we should get the tsc frequency from hypervisor and use preset
lpj instead.
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: sta...@vger.kernel.org
Acked-by: K. Y. Srinivasan
Signed-off-by: Jason Wang
---
arch/x86/kernel/cpu/mshyperv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 9f7ca26..832d05a 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
@@ -105,6 +106,11 @@ static void __init ms_hyperv_init_platform(void)
if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
+
+#ifdef CONFIG_X86_IO_APIC
+ no_timer_check = 1;
+#endif
+
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
--
1.8.3.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hyperv: Move state setting for link query
On 03/04/2014 07:54 AM, Haiyang Zhang wrote:
> It moves the state setting for query into rndis_filter_receive_response().
> All callbacks including query-complete and status-callback are synchronized
> by channel->inbound_lock. This prevents pentential race between them.
This still looks racy to me. The problem is workqueue is not
synchronized with those here.
Consider the following case in netvsc_link_change():
if (rdev->link_state) {
... receive interrupt ...
rndis_filter_receice_response() which changes rdev->link_state
...
netif_carrier_off()
}
And also it need to schedule a work otherwise the link status is out of
sync.
> Signed-off-by: Haiyang Zhang
> ---
> drivers/net/hyperv/rndis_filter.c | 21 -
> 1 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/hyperv/rndis_filter.c
> b/drivers/net/hyperv/rndis_filter.c
> index f0cc8ef..6a9f602 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -240,6 +240,22 @@ static int rndis_filter_send_request(struct rndis_device
> *dev,
> return ret;
> }
>
> +static void rndis_set_link_state(struct rndis_device *rdev,
> + struct rndis_request *request)
> +{
> + u32 link_status;
> + struct rndis_query_complete *query_complete;
> +
> + query_complete = &request->response_msg.msg.query_complete;
> +
> + if (query_complete->status == RNDIS_STATUS_SUCCESS &&
> + query_complete->info_buflen == sizeof(u32)) {
> + memcpy(&link_status, (void *)((unsigned long)query_complete +
> +query_complete->info_buf_offset), sizeof(u32));
> + rdev->link_state = link_status != 0;
> + }
> +}
> +
> static void rndis_filter_receive_response(struct rndis_device *dev,
> struct rndis_message *resp)
> {
> @@ -269,6 +285,10 @@ static void rndis_filter_receive_response(struct
> rndis_device *dev,
> sizeof(struct rndis_message) + RNDIS_EXT_LEN) {
> memcpy(&request->response_msg, resp,
> resp->msg_len);
> + if (request->request_msg.ndis_msg_type ==
> + RNDIS_MSG_QUERY && request->request_msg.msg.
> + query_req.oid == RNDIS_OID_GEN_MEDIA_CONNECT_STATUS)
> + rndis_set_link_state(dev, request);
> } else {
> netdev_err(ndev,
> "rndis response buffer overflow "
> @@ -617,7 +637,6 @@ static int rndis_filter_query_device_link_status(struct
> rndis_device *dev)
> ret = rndis_filter_query_device(dev,
> RNDIS_OID_GEN_MEDIA_CONNECT_STATUS,
> &link_status, &size);
> - dev->link_state = (link_status != 0) ? true : false;
>
> return ret;
> }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hyperv: Move state setting for link query
On 03/05/2014 12:57 AM, Haiyang Zhang wrote:
>
>> -Original Message-
>> From: Jason Wang [mailto:jasow...@redhat.com]
>> Sent: Monday, March 3, 2014 10:10 PM
>> To: Haiyang Zhang; da...@davemloft.net; net...@vger.kernel.org
>> Cc: KY Srinivasan; o...@aepfle.de; linux-ker...@vger.kernel.org; driverdev-
>> de...@linuxdriverproject.org
>> Subject: Re: [PATCH net-next] hyperv: Move state setting for link query
>>
>> On 03/04/2014 07:54 AM, Haiyang Zhang wrote:
>>> It moves the state setting for query into rndis_filter_receive_response().
>>> All callbacks including query-complete and status-callback are
>>> synchronized by channel->inbound_lock. This prevents pentential race
>> between them.
>>
>> This still looks racy to me. The problem is workqueue is not synchronized
>> with
>> those here.
>>
>> Consider the following case in netvsc_link_change():
>>
>> if (rdev->link_state) {
>> ... receive interrupt ...
>> rndis_filter_receice_response() which changes rdev->link_state
>> ...
>> netif_carrier_off()
>> }
>>
>> And also it need to schedule a work otherwise the link status is out of sync.
> The rndis_filter_query_device_link_status() makes the query and wait for the
> complete message, including set state, before returning.
>
> The rndis_filter_query_device_link_status() is called from
> rndis_filter_device_add(),
> which is called from either netvsc_change_mtu() or netvsc_probe().
>
> The change_mtu() and netvsc_link_change() are synchronized by rtnl_lock().
> In netvsc_probe(), the status query & complete happens before
> register_netdev(), and
> the netvsc_linkstatus_callback() schedules the work only after netdevice is
> registered.
> So, there are no race in either case.
>
> The carrier_on/off work will be scheduled when netvsc_open() is called. Then,
> the status will be updated based on the latest link_state.
>
> Thanks,
> - Haiyang
>
I see. Then if the link status is changing during mtu changing in guest.
Looks like we may miss a link status updating?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 09/22] staging: crypto: skein: use u8, u64 vice uint*_t
Signed-off-by: Jason Cooper --- drivers/staging/skein/include/skeinApi.h | 8 drivers/staging/skein/include/threefishApi.h | 22 +++--- drivers/staging/skein/skeinApi.c | 22 +++--- drivers/staging/skein/threefish1024Block.c | 18 +- drivers/staging/skein/threefish256Block.c| 18 +- drivers/staging/skein/threefish512Block.c| 18 +- drivers/staging/skein/threefishApi.c | 20 ++-- 7 files changed, 63 insertions(+), 63 deletions(-) diff --git a/drivers/staging/skein/include/skeinApi.h b/drivers/staging/skein/include/skeinApi.h index 548c639431de..4ad294f7945d 100755 --- a/drivers/staging/skein/include/skeinApi.h +++ b/drivers/staging/skein/include/skeinApi.h @@ -173,7 +173,7 @@ OTHER DEALINGS IN THE SOFTWARE. * @return * SKEIN_SUCESS of SKEIN_FAIL */ -int skeinMacInit(struct skein_ctx* ctx, const uint8_t *key, size_t keyLen, +int skeinMacInit(struct skein_ctx* ctx, const u8 *key, size_t keyLen, size_t hashBitLen); /** @@ -188,7 +188,7 @@ OTHER DEALINGS IN THE SOFTWARE. * @return * Success or error code. */ -int skeinUpdate(struct skein_ctx *ctx, const uint8_t *msg, +int skeinUpdate(struct skein_ctx *ctx, const u8 *msg, size_t msgByteCnt); /** @@ -204,7 +204,7 @@ OTHER DEALINGS IN THE SOFTWARE. * @param msgBitCnt * Length of the message in @b bits. */ -int skeinUpdateBits(struct skein_ctx *ctx, const uint8_t *msg, +int skeinUpdateBits(struct skein_ctx *ctx, const u8 *msg, size_t msgBitCnt); /** @@ -222,7 +222,7 @@ OTHER DEALINGS IN THE SOFTWARE. * Success or error code. * @see skeinReset */ -int skeinFinal(struct skein_ctx* ctx, uint8_t* hash); +int skeinFinal(struct skein_ctx* ctx, u8* hash); /** * @} diff --git a/drivers/staging/skein/include/threefishApi.h b/drivers/staging/skein/include/threefishApi.h index 4c1cd81f30c4..194e313b6b62 100644 --- a/drivers/staging/skein/include/threefishApi.h +++ b/drivers/staging/skein/include/threefishApi.h @@ -72,7 +72,7 @@ * @param tweak * Pointer to the two tweak words (word has 64 bits). */ -void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size stateSize, uint64_t* keyData, uint64_t* tweak); +void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size stateSize, u64* keyData, u64* tweak); /** * Encrypt Threefisch block (bytes). @@ -89,7 +89,7 @@ * @param out * Pointer to cipher buffer. */ -void threefishEncryptBlockBytes(struct threefish_key* keyCtx, uint8_t* in, uint8_t* out); +void threefishEncryptBlockBytes(struct threefish_key* keyCtx, u8* in, u8* out); /** * Encrypt Threefisch block (words). @@ -108,7 +108,7 @@ * @param out * Pointer to cipher buffer. */ -void threefishEncryptBlockWords(struct threefish_key* keyCtx, uint64_t* in, uint64_t* out); +void threefishEncryptBlockWords(struct threefish_key* keyCtx, u64* in, u64* out); /** * Decrypt Threefisch block (bytes). @@ -125,7 +125,7 @@ * @param out * Pointer to plaintext buffer. */ -void threefishDecryptBlockBytes(struct threefish_key* keyCtx, uint8_t* in, uint8_t* out); +void threefishDecryptBlockBytes(struct threefish_key* keyCtx, u8* in, u8* out); /** * Decrypt Threefisch block (words). @@ -144,14 +144,14 @@ * @param out * Pointer to plaintext buffer. */ -void threefishDecryptBlockWords(struct threefish_key* keyCtx, uint64_t* in, uint64_t* out); +void threefishDecryptBlockWords(struct threefish_key* keyCtx, u64* in, u64* out); -void threefishEncrypt256(struct threefish_key* keyCtx, uint64_t* input, uint64_t* output); -void threefishEncrypt512(struct threefish_key* keyCtx, uint64_t* input, uint64_t* output); -void threefishEncrypt1024(struct threefish_key* keyCtx, uint64_t* input, uint64_t* output); -void threefishDecrypt256(struct threefish_key* keyCtx, uint64_t* input, uint64_t* output); -void threefishDecrypt512(struct threefish_key* keyCtx, uint64_t* input, uint64_t* output); -void threefishDecrypt1024(struct threefish_key* keyCtx, uint64_t* input, uint64_t* output); +void threefishEncrypt256(struct threefish_key* keyCtx, u64* input, u64* output); +void threefishEncrypt512(struct threefish_key* keyCtx, u64* input, u64* output); +void threefishEncrypt1024(struct threefish_key* keyCtx, u64* input, u64* output); +void threefishDecrypt256(struct threefish_key* keyCtx, u64* input, u64* output); +void threefishDecrypt512(struct threefish_key* keyCtx, u64* input, u64* output); +void threefishDecrypt1024(struct threefish_key* keyCtx, u64* input, u64* output
[RFC PATCH 21/22] staging: crypto: skein: remove unnecessary line continuation
Signed-off-by: Jason Cooper
---
drivers/staging/skein/skein_block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/skein/skein_block.c
b/drivers/staging/skein/skein_block.c
index 707a21ae53c6..fd96ca0ad0ed 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -477,7 +477,7 @@ unsigned int Skein_512_Unroll_Cnt(void)
/* Skein1024 **/
#if !(SKEIN_USE_ASM & 1024)
-void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr, \
+void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr,
size_t blkCnt, size_t byteCntAdd)
{ /* do it in C, always looping (unrolled is bigger AND slower!) */
enum {
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 04/22] staging: crypto: skein: remove brg_*.h includes
Signed-off-by: Jason Cooper --- drivers/staging/skein/include/brg_endian.h | 148 - drivers/staging/skein/include/brg_types.h | 131 - drivers/staging/skein/include/skein_port.h | 6 +- 3 files changed, 2 insertions(+), 283 deletions(-) delete mode 100644 drivers/staging/skein/include/brg_endian.h delete mode 100644 drivers/staging/skein/include/brg_types.h diff --git a/drivers/staging/skein/include/brg_endian.h b/drivers/staging/skein/include/brg_endian.h deleted file mode 100644 index c03c7c5d1eb4.. --- a/drivers/staging/skein/include/brg_endian.h +++ /dev/null @@ -1,148 +0,0 @@ -/* - --- - Copyright (c) 2003, Dr Brian Gladman, Worcester, UK. All rights reserved. - - LICENSE TERMS - - The free distribution and use of this software in both source and binary - form is allowed (with or without changes) provided that: - - 1. distributions of this source code include the above copyright - notice, this list of conditions and the following disclaimer; - - 2. distributions in binary form include the above copyright - notice, this list of conditions and the following disclaimer - in the documentation and/or other associated materials; - - 3. the copyright holder's name is not used to endorse products - built using this software without specific written permission. - - ALTERNATIVELY, provided that this notice is retained in full, this product - may be distributed under the terms of the GNU General Public License (GPL), - in which case the provisions of the GPL apply INSTEAD OF those given above. - - DISCLAIMER - - This software is provided 'as is' with no explicit or implied warranties - in respect of its properties, including, but not limited to, correctness - and/or fitness for purpose. - --- - Issue 20/10/2006 -*/ - -#ifndef BRG_ENDIAN_H -#define BRG_ENDIAN_H - -#define IS_BIG_ENDIAN 4321 /* byte 0 is most significant (mc68k) */ -#define IS_LITTLE_ENDIAN 1234 /* byte 0 is least significant (i386) */ - -/* Include files where endian defines and byteswap functions may reside */ -#if defined( __FreeBSD__ ) || defined( __OpenBSD__ ) || defined( __NetBSD__ ) -# include -#elif defined( BSD ) && ( BSD >= 199103 ) || defined( __APPLE__ ) || \ - defined( __CYGWIN32__ ) || defined( __DJGPP__ ) || defined( __osf__ ) -# include -#elif defined( __linux__ ) || defined( __GNUC__ ) || defined( __GNU_LIBRARY__ ) -# if !defined( __MINGW32__ ) && !defined(AVR) -#include -#if !defined( __BEOS__ ) -# include -#endif -# endif -#endif - -/* Now attempt to set the define for platform byte order using any */ -/* of the four forms SYMBOL, _SYMBOL, __SYMBOL & __SYMBOL__, which */ -/* seem to encompass most endian symbol definitions */ - -#if defined( BIG_ENDIAN ) && defined( LITTLE_ENDIAN ) -# if defined( BYTE_ORDER ) && BYTE_ORDER == BIG_ENDIAN -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( BYTE_ORDER ) && BYTE_ORDER == LITTLE_ENDIAN -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( BIG_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( LITTLE_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -#if defined( _BIG_ENDIAN ) && defined( _LITTLE_ENDIAN ) -# if defined( _BYTE_ORDER ) && _BYTE_ORDER == _BIG_ENDIAN -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( _BYTE_ORDER ) && _BYTE_ORDER == _LITTLE_ENDIAN -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( _BIG_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( _LITTLE_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -#if defined( __BIG_ENDIAN ) && defined( __LITTLE_ENDIAN ) -# if defined( __BYTE_ORDER ) && __BYTE_ORDER == __BIG_ENDIAN -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( __BYTE_ORDER ) && __BYTE_ORDER == __LITTLE_ENDIAN -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( __BIG_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( __LITTLE_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -#if defined( __BIG_ENDIAN__ ) && defined( __LITTLE_ENDIAN__ ) -# if defined( __BYTE_ORDER__ ) && __BYTE_ORDER__ == __BIG_ENDIAN__ -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( __BYTE_ORDER__ ) && __BYTE_ORDER__ == __LITTLE_ENDIAN__ -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( __BIG_ENDIAN__ ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( __LITTLE_ENDIAN__ ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -/* if the platform byte order could not be determined, then
[RFC PATCH 18/22] staging: crypto: skein: wrap multi-line macros in do-while loops
Signed-off-by: Jason Cooper
---
drivers/staging/skein/skein_block.c | 66 -
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/skein/skein_block.c
b/drivers/staging/skein/skein_block.c
index 6e0f4a21aae3..707a21ae53c6 100644
--- a/drivers/staging/skein/skein_block.c
+++ b/drivers/staging/skein/skein_block.c
@@ -107,27 +107,36 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx,
const u8 *blkPtr,
/* run the rounds */
#define Round256(p0, p1, p2, p3, ROT, rNum) \
+do { \
X##p0 += X##p1; X##p1 = RotL_64(X##p1, ROT##_0); X##p1 ^= X##p0; \
X##p2 += X##p3; X##p3 = RotL_64(X##p3, ROT##_1); X##p3 ^= X##p2; \
+} while (0)
#if SKEIN_UNROLL_256 == 0
#define R256(p0, p1, p2, p3, ROT, rNum) /* fully unrolled */ \
+do { \
Round256(p0, p1, p2, p3, ROT, rNum) \
- Skein_Show_R_Ptr(BLK_BITS, &ctx->h, rNum, Xptr);
+ Skein_Show_R_Ptr(BLK_BITS, &ctx->h, rNum, Xptr); \
+} while (0)
#define I256(R) \
+do { \
/* inject the key schedule value */ \
X0 += ks[((R)+1) % 5]; \
X1 += ks[((R)+2) % 5] + ts[((R)+1) % 3]; \
X2 += ks[((R)+3) % 5] + ts[((R)+2) % 3]; \
X3 += ks[((R)+4) % 5] + (R)+1; \
- Skein_Show_R_Ptr(BLK_BITS, &ctx->h, SKEIN_RND_KEY_INJECT, Xptr);
+ Skein_Show_R_Ptr(BLK_BITS, &ctx->h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
#else /* looping version */
#define R256(p0, p1, p2, p3, ROT, rNum) \
+do { \
Round256(p0, p1, p2, p3, ROT, rNum) \
- Skein_Show_R_Ptr(BLK_BITS, &ctx->h, 4 * (r - 1) + rNum, Xptr);
+ Skein_Show_R_Ptr(BLK_BITS, &ctx->h, 4 * (r - 1) + rNum, Xptr); \
+} while (0)
#define I256(R) \
+do { \
/* inject the key schedule value */ \
X0 += ks[r+(R)+0]; \
X1 += ks[r+(R)+1] + ts[r+(R)+0]; \
@@ -136,12 +145,14 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx,
const u8 *blkPtr,
/* rotate key schedule */ \
ks[r + (R) + 4] = ks[r + (R) - 1]; \
ts[r + (R) + 2] = ts[r + (R) - 1]; \
- Skein_Show_R_Ptr(BLK_BITS, &ctx->h, SKEIN_RND_KEY_INJECT, Xptr);
+ Skein_Show_R_Ptr(BLK_BITS, &ctx->h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
for (r = 1; r < 2 * RCNT; r += 2 * SKEIN_UNROLL_256)
#endif
{
#define R256_8_rounds(R) \
+do { \
R256(0, 1, 2, 3, R_256_0, 8 * (R) + 1); \
R256(0, 3, 2, 1, R_256_1, 8 * (R) + 2); \
R256(0, 1, 2, 3, R_256_2, 8 * (R) + 3); \
@@ -151,7 +162,8 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx,
const u8 *blkPtr,
R256(0, 3, 2, 1, R_256_5, 8 * (R) + 6); \
R256(0, 1, 2, 3, R_256_6, 8 * (R) + 7); \
R256(0, 3, 2, 1, R_256_7, 8 * (R) + 8); \
- I256(2 * (R) + 1);
+ I256(2 * (R) + 1); \
+} while (0)
R256_8_rounds(0);
@@ -311,17 +323,22 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx,
const u8 *blkPtr,
Xptr);
/* run the rounds */
#define Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
+do { \
X##p0 += X##p1; X##p1 = RotL_64(X##p1, ROT##_0); X##p1 ^= X##p0; \
X##p2 += X##p3; X##p3 = RotL_64(X##p3, ROT##_1); X##p3 ^= X##p2; \
X##p4 += X##p5; X##p5 = RotL_64(X##p5, ROT##_2); X##p5 ^= X##p4; \
X##p6 += X##p7; X##p7 = RotL_64(X##p7, ROT##_3); X##p7 ^= X##p6; \
+} while (0)
#if SKEIN_UNROLL_512 == 0
#define R512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) /* unrolled */ \
+do { \
Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
- Skein_Show_R_Ptr(BLK_BITS, &ctx->h, rNum, Xptr);
+ Skein_Show_R_Ptr(BLK_BITS, &ctx->h, rNum, Xptr); \
+} while (0)
#define I512(R) \
+do { \
/* inject the key schedule value */ \
X0 += ks[((R) + 1) % 9]; \
X1 += ks[((R) + 2) % 9]; \
@@ -331,13 +348,17 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx,
const u8 *blkPtr,
X5 += ks[((R) + 6) % 9] + ts[((R) + 1) % 3]; \
X6 += ks[((R) + 7) % 9] + ts[((R) + 2) % 3]; \
X7 += ks[((R) + 8) % 9] + (R) + 1; \
- Skein_Show_R_Ptr(BLK_BITS, &ctx->h, SKEIN_RND_KEY_INJECT, Xptr);
+ Skein_Show_R_Ptr(BLK_BITS, &ctx->h, SKEIN_RND_KEY_INJECT, Xptr); \
+} while (0)
#else /* looping version */
#define R512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
+do { \
Round512(p0, p1, p2, p3, p4, p5, p6, p7, ROT, rNum) \
- Skein_Show_R_Ptr(BLK_BITS, &ctx->h, 4 * (r - 1) + rNum, Xptr);
+ Skein_Show_R_Ptr(BLK_BITS, &ctx->h, 4 * (r - 1) + rNum, Xptr); \
+} while (0)
#define I512(R) \
+do { \
/* inject the key schedule value */ \
X0 += ks[r + (R) + 0]; \
X1 += ks[r + (R) +
[RFC PATCH 10/22] staging: crypto: skein: fixup pointer whitespace
Signed-off-by: Jason Cooper --- drivers/staging/skein/include/skein.h| 18 +- drivers/staging/skein/include/skeinApi.h | 10 +- drivers/staging/skein/include/threefishApi.h | 22 +++--- drivers/staging/skein/skeinApi.c | 18 +- drivers/staging/skein/threefish1024Block.c | 4 ++-- drivers/staging/skein/threefish256Block.c| 4 ++-- drivers/staging/skein/threefish512Block.c| 4 ++-- drivers/staging/skein/threefishApi.c | 20 ++-- 8 files changed, 50 insertions(+), 50 deletions(-) diff --git a/drivers/staging/skein/include/skein.h b/drivers/staging/skein/include/skein.h index 77b712e73253..b7cd6c0cef2f 100644 --- a/drivers/staging/skein/include/skein.h +++ b/drivers/staging/skein/include/skein.h @@ -100,9 +100,9 @@ int Skein_256_Update(struct skein_256_ctx *ctx, const u8 *msg, size_t msgByteCn int Skein_512_Update(struct skein_512_ctx *ctx, const u8 *msg, size_t msgByteCnt); int Skein1024_Update(struct skein1024_ctx *ctx, const u8 *msg, size_t msgByteCnt); -int Skein_256_Final (struct skein_256_ctx *ctx, u8 * hashVal); -int Skein_512_Final (struct skein_512_ctx *ctx, u8 * hashVal); -int Skein1024_Final (struct skein1024_ctx *ctx, u8 * hashVal); +int Skein_256_Final (struct skein_256_ctx *ctx, u8 *hashVal); +int Skein_512_Final (struct skein_512_ctx *ctx, u8 *hashVal); +int Skein1024_Final (struct skein1024_ctx *ctx, u8 *hashVal); /* ** Skein APIs for "extended" initialization: MAC keys, tree hashing. @@ -127,17 +127,17 @@ int Skein1024_InitExt(struct skein1024_ctx *ctx, size_t hashBitLen, u64 treeInf ** Final_Pad: pad, do final block, but no OUTPUT type ** Output: do just the output stage */ -int Skein_256_Final_Pad(struct skein_256_ctx *ctx, u8 * hashVal); -int Skein_512_Final_Pad(struct skein_512_ctx *ctx, u8 * hashVal); -int Skein1024_Final_Pad(struct skein1024_ctx *ctx, u8 * hashVal); +int Skein_256_Final_Pad(struct skein_256_ctx *ctx, u8 *hashVal); +int Skein_512_Final_Pad(struct skein_512_ctx *ctx, u8 *hashVal); +int Skein1024_Final_Pad(struct skein1024_ctx *ctx, u8 *hashVal); #ifndef SKEIN_TREE_HASH #define SKEIN_TREE_HASH (1) #endif #if SKEIN_TREE_HASH -int Skein_256_Output (struct skein_256_ctx *ctx, u8 * hashVal); -int Skein_512_Output (struct skein_512_ctx *ctx, u8 * hashVal); -int Skein1024_Output (struct skein1024_ctx *ctx, u8 * hashVal); +int Skein_256_Output (struct skein_256_ctx *ctx, u8 *hashVal); +int Skein_512_Output (struct skein_512_ctx *ctx, u8 *hashVal); +int Skein1024_Output (struct skein1024_ctx *ctx, u8 *hashVal); #endif /* diff --git a/drivers/staging/skein/include/skeinApi.h b/drivers/staging/skein/include/skeinApi.h index 4ad294f7945d..2c52797918cf 100755 --- a/drivers/staging/skein/include/skeinApi.h +++ b/drivers/staging/skein/include/skeinApi.h @@ -123,7 +123,7 @@ OTHER DEALINGS IN THE SOFTWARE. * @return * SKEIN_SUCESS of SKEIN_FAIL */ -int skeinCtxPrepare(struct skein_ctx* ctx, enum skein_size size); +int skeinCtxPrepare(struct skein_ctx *ctx, enum skein_size size); /** * Initialize a Skein context. @@ -139,7 +139,7 @@ OTHER DEALINGS IN THE SOFTWARE. * SKEIN_SUCESS of SKEIN_FAIL * @see skeinReset */ -int skeinInit(struct skein_ctx* ctx, size_t hashBitLen); +int skeinInit(struct skein_ctx *ctx, size_t hashBitLen); /** * Resets a Skein context for further use. @@ -151,7 +151,7 @@ OTHER DEALINGS IN THE SOFTWARE. * @param ctx * Pointer to a pre-initialized Skein MAC context */ -void skeinReset(struct skein_ctx* ctx); +void skeinReset(struct skein_ctx *ctx); /** * Initializes a Skein context for MAC usage. @@ -173,7 +173,7 @@ OTHER DEALINGS IN THE SOFTWARE. * @return * SKEIN_SUCESS of SKEIN_FAIL */ -int skeinMacInit(struct skein_ctx* ctx, const u8 *key, size_t keyLen, +int skeinMacInit(struct skein_ctx *ctx, const u8 *key, size_t keyLen, size_t hashBitLen); /** @@ -222,7 +222,7 @@ OTHER DEALINGS IN THE SOFTWARE. * Success or error code. * @see skeinReset */ -int skeinFinal(struct skein_ctx* ctx, u8* hash); +int skeinFinal(struct skein_ctx *ctx, u8 *hash); /** * @} diff --git a/drivers/staging/skein/include/threefishApi.h b/drivers/staging/skein/include/threefishApi.h index 194e313b6b62..1f9e6e14f50b 100644 --- a/drivers/staging/skein/include/threefishApi.h +++ b/drivers/staging/skein/include/threefishApi.h @@ -72,7 +72,7 @@ * @param tweak * Pointer to the two tweak words (word has 64 bits). */ -void threefishSetKey(struct threefish_key* keyCtx, enum threefish_size stateSize, u64* keyData, u64* tweak); +void threefishSetKey(struct threefish_key *ke
[RFC PATCH 22/22] staging: crypto: skein: add TODO file
Signed-off-by: Jason Cooper --- drivers/staging/skein/TODO | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 drivers/staging/skein/TODO diff --git a/drivers/staging/skein/TODO b/drivers/staging/skein/TODO new file mode 100644 index ..f5c167a305ae --- /dev/null +++ b/drivers/staging/skein/TODO @@ -0,0 +1,11 @@ +skein/threefish TODO + + - rename camelcase vars + - rename camelcase functions + - rename files + - move macros into appropriate header files + - add / pass test vectors + - module support + +Please send patches to Jason Cooper in addition to the +staging tree mailinglist. -- 1.9.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 19/22] staging: crypto: skein: remove externs from .c files
Signed-off-by: Jason Cooper --- drivers/staging/skein/include/skein_block.h | 22 ++ drivers/staging/skein/skein.c | 10 +- 2 files changed, 23 insertions(+), 9 deletions(-) create mode 100644 drivers/staging/skein/include/skein_block.h diff --git a/drivers/staging/skein/include/skein_block.h b/drivers/staging/skein/include/skein_block.h new file mode 100644 index ..b15c079b5bd4 --- /dev/null +++ b/drivers/staging/skein/include/skein_block.h @@ -0,0 +1,22 @@ +/*** +** +** Implementation of the Skein hash function. +** +** Source code author: Doug Whiting, 2008. +** +** This algorithm and source code is released to the public domain. +** +/ +#ifndef _SKEIN_BLOCK_H_ +#define _SKEIN_BLOCK_H_ + +#include /* get the Skein API definitions */ + +void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr, + size_t blkCnt, size_t byteCntAdd); +void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr, + size_t blkCnt, size_t byteCntAdd); +void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr, + size_t blkCnt, size_t byteCntAdd); + +#endif diff --git a/drivers/staging/skein/skein.c b/drivers/staging/skein/skein.c index 0d8c70c02c6f..096b86bf9430 100644 --- a/drivers/staging/skein/skein.c +++ b/drivers/staging/skein/skein.c @@ -13,15 +13,7 @@ #include/* get the memcpy/memset functions */ #include /* get the Skein API definitions */ #include /* get precomputed IVs */ - -/*/ -/* External function to process blkCnt (nonzero) full block(s) of data. */ -void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr, - size_t blkCnt, size_t byteCntAdd); -void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr, - size_t blkCnt, size_t byteCntAdd); -void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr, - size_t blkCnt, size_t byteCntAdd); +#include /*/ /* 256-bit Skein */ -- 1.9.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 05/22] staging: crypto: skein: remove skein_port.h
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h | 14 +++-
drivers/staging/skein/include/skein_port.h | 108 -
drivers/staging/skein/skein.c | 21 --
3 files changed, 13 insertions(+), 130 deletions(-)
delete mode 100644 drivers/staging/skein/include/skein_port.h
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index 315cdcd14413..211aca1b1036 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -33,7 +33,19 @@ extern "C"
#endif
#include /* get size_t definition */
-#include/* get platform-specific definitions */
+
+typedef unsigned intuint_t; /* native unsigned integer */
+typedef uint8_t u08b_t; /* 8-bit unsigned integer */
+typedef uint64_tu64b_t; /* 64-bit unsigned integer */
+
+#ifndef RotL_64
+#define RotL_64(x,N)(((x) << (N)) | ((x) >> (64-(N
+#endif
+
+/* below two prototype assume we are handed aligned data */
+#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
+#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
+#define Skein_Swap64(w64) (w64)
enum
{
diff --git a/drivers/staging/skein/include/skein_port.h
b/drivers/staging/skein/include/skein_port.h
deleted file mode 100644
index e78c976dccc5..
--- a/drivers/staging/skein/include/skein_port.h
+++ /dev/null
@@ -1,108 +0,0 @@
-#ifndef _SKEIN_PORT_H_
-#define _SKEIN_PORT_H_
-/***
-**
-** Platform-specific definitions for Skein hash function.
-**
-** Source code author: Doug Whiting, 2008.
-**
-** This algorithm and source code is released to the public domain.
-**
-** Many thanks to Brian Gladman for his portable header files.
-**
-** To port Skein to an "unsupported" platform, change the definitions
-** in this file appropriately.
-**
-/
-
-typedef unsigned intuint_t; /* native unsigned integer */
-typedef uint8_t u08b_t; /* 8-bit unsigned integer */
-typedef uint64_tu64b_t; /* 64-bit unsigned integer */
-
-#ifndef RotL_64
-#define RotL_64(x,N)(((x) << (N)) | ((x) >> (64-(N
-#endif
-
-/*
- * Skein is "natively" little-endian (unlike SHA-xxx), for optimal
- * performance on x86 CPUs. The Skein code requires the following
- * definitions for dealing with endianness:
- *
- *SKEIN_NEED_SWAP: 0 for little-endian, 1 for big-endian
- *Skein_Put64_LSB_First
- *Skein_Get64_LSB_First
- *Skein_Swap64
- *
- * If SKEIN_NEED_SWAP is defined at compile time, it is used here
- * along with the portable versions of Put64/Get64/Swap64, which
- * are slow in general.
- *
- * Otherwise, an "auto-detect" of endianness is attempted below.
- * If the default handling doesn't work well, the user may insert
- * platform-specific code instead (e.g., for big-endian CPUs).
- *
- */
-#define SKEIN_NEED_SWAP (0)
-/* below two prototype assume we are handed aligned data */
-#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
-#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
-
-/*
- **
- * Provide any definitions still needed.
- **
- */
-#ifndef Skein_Swap64 /* swap for big-endian, nop for little-endian */
-#if SKEIN_NEED_SWAP
-#define Skein_Swap64(w64) \
- ( (( ((u64b_t)(w64)) & 0xFF) << 56) | \
-(u64b_t)(w64)) >> 8) & 0xFF) << 48) | \
-(u64b_t)(w64)) >>16) & 0xFF) << 40) | \
-(u64b_t)(w64)) >>24) & 0xFF) << 32) | \
-(u64b_t)(w64)) >>32) & 0xFF) << 24) | \
-(u64b_t)(w64)) >>40) & 0xFF) << 16) | \
-(u64b_t)(w64)) >>48) & 0xFF) << 8) | \
-(u64b_t)(w64)) >>56) & 0xFF) ) )
-#else
-#define Skein_Swap64(w64) (w64)
-#endif
-#endif /* ifndef Skein_Swap64 */
-
-
-#ifndef Skein_Put64_LSB_First
-voidSkein_Put64_LSB_First(u08b_t *dst,const u64b_t *src,size_t bCnt)
-#ifdef SKEIN_PORT_CODE /* instantiate the function code here? */
-{ /* this version is fully portable (big-endian or little-endian), but
slow */
-size_t n;
-
-for (n=0;n>3] >> (8*(n&7)));
-}
-#else
-;/* output only the function prototype */
-#endif
-#endif /* ifndef Skein_Put64_LSB_First */
-
-
-#ifndef Skein_Get64_LSB_First
-voidSkein_Get64_LSB_First(u64b_t *dst,const u08b_t *src,size_t wCnt)
-#ifdef SKEIN_PORT_CODE /* instanti
[RFC PATCH 16/22] staging: crypto: skein: fix do/while brace formatting
Signed-off-by: Jason Cooper --- drivers/staging/skein/skein_block.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/staging/skein/skein_block.c b/drivers/staging/skein/skein_block.c index 780b4936f783..6e0f4a21aae3 100644 --- a/drivers/staging/skein/skein_block.c +++ b/drivers/staging/skein/skein_block.c @@ -215,8 +215,7 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr, Skein_Show_Round(BLK_BITS, &ctx->h, SKEIN_RND_FEED_FWD, ctx->X); ts[1] &= ~SKEIN_T1_FLAG_FIRST; - } - while (--blkCnt); + } while (--blkCnt); ctx->h.T[0] = ts[0]; ctx->h.T[1] = ts[1]; } @@ -434,8 +433,7 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr, Skein_Show_Round(BLK_BITS, &ctx->h, SKEIN_RND_FEED_FWD, ctx->X); ts[1] &= ~SKEIN_T1_FLAG_FIRST; - } - while (--blkCnt); + } while (--blkCnt); ctx->h.T[0] = ts[0]; ctx->h.T[1] = ts[1]; } @@ -717,8 +715,7 @@ void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr, \ ts[1] &= ~SKEIN_T1_FLAG_FIRST; blkPtr += SKEIN1024_BLOCK_BYTES; - } - while (--blkCnt); + } while (--blkCnt); ctx->h.T[0] = ts[0]; ctx->h.T[1] = ts[1]; } -- 1.9.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 20/22] staging: crypto: skein: remove braces from single-statement block
Signed-off-by: Jason Cooper
---
drivers/staging/skein/skeinApi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/skein/skeinApi.c b/drivers/staging/skein/skeinApi.c
index f0015d5b10f5..dd109bf6f7b9 100644
--- a/drivers/staging/skein/skeinApi.c
+++ b/drivers/staging/skein/skeinApi.c
@@ -188,9 +188,9 @@ int skeinUpdateBits(struct skein_ctx *ctx, const u8 *msg,
msgBitCnt == 0, SKEIN_FAIL);
/* if number of bits is a multiple of bytes - that's easy */
- if ((msgBitCnt & 0x7) == 0) {
+ if ((msgBitCnt & 0x7) == 0)
return skeinUpdate(ctx, msg, msgBitCnt >> 3);
- }
+
skeinUpdate(ctx, msg, (msgBitCnt >> 3) + 1);
/*
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 01/22] scripts: objdiff: detect object code changes between two commits
objdiff is useful when doing large code cleanups. For example, when
removing checkpatch warnings and errors from new drivers in the staging
tree.
objdiff can be used in conjunction with a git rebase to confirm that
each commit made no changes to the resulting object code. It has the
same return values as diff(1).
This was written specifically to support adding the skein and threefish
cryto drivers to the staging tree. I needed a programmatic way to
confirm that commits changing >90% of the lines didn't inadvertently
change the code.
Signed-off-by: Jason Cooper
---
scripts/objdiff | 126
1 file changed, 126 insertions(+)
create mode 100755 scripts/objdiff
diff --git a/scripts/objdiff b/scripts/objdiff
new file mode 100755
index ..9e1ad8df2d07
--- /dev/null
+++ b/scripts/objdiff
@@ -0,0 +1,126 @@
+#!/bin/bash
+
+# objdiff - a small script for validating that a commit or series of commits
+# didn't change object code.
+#
+# Copyright 2014, Jason Cooper
+#
+# Licensed under the terms of the GNU GPL version 2
+
+# usage example:
+#
+# $ git checkout COMMIT_A
+# $
+# $ ./scripts/objdiff record path/to/*.o
+#
+# $ git checkout COMMIT_B
+# $
+# $ ./scripts/objdiff record path/to/*.o
+#
+# $ ./scripts/objdiff diff COMMIT_A COMMIT_B
+# $
+
+# And to clean up (everything is in /tmp/objdiff-*)
+# $ ./scripts/objdiff clean all
+
+usage() {
+ echo "Usage: $0 "
+ echo " record"
+ echo " diff "
+ echo " clean all | "
+ exit 1
+}
+
+dorecord() {
+ [ $# -eq 0 ] && usage
+
+ FILES="$*"
+
+ CMT="`git rev-parse --short HEAD`"
+
+ OBJDUMP="${CROSS_COMPILE}objdump"
+ OBJDIFFD="/tmp/objdiff-$CMT"
+
+ [ ! -d "$OBJDIFFD" ] && mkdir -p "$OBJDIFFD"
+
+ for f in $FILES; do
+ dn="${f%/*}"
+ bn="${f##*/}"
+
+ [ ! -d "$OBJDIFFD/$dn" ] && mkdir -p "$OBJDIFFD/$dn"
+
+ # remove addresses for a more clear diff
+ #
http://dummdida.tumblr.com/post/60924060451/binary-diff-between-libc-from-scientificlinux-and
+ $OBJDUMP -D "$f" | sed "s/^[[:space:]]\+[0-9a-f]\+//" \
+ >"$OBJDIFFD/$dn/$bn"
+
+ # force rebuild
+ rm -f "$f"
+ done
+}
+
+dodiff() {
+ [ $# -ne 2 ] && usage
+
+ SRC="`git rev-parse --short $1`"
+ DST="`git rev-parse --short $2`"
+
+ DIFF="`which colordiff`"
+
+ if [ ${#DIFF} -eq 0 ] || [ ! -x "$DIFF" ]; then
+ DIFF="`which diff`"
+ fi
+
+ SRCD="/tmp/objdiff-$SRC"
+ DSTD="/tmp/objdiff-$DST"
+
+ if [ ! -d "$SRCD" ]; then
+ echo "ERROR: $SRCD doesn't exist"
+ exit 1
+ fi
+
+ if [ ! -d "$DSTD" ]; then
+ echo "ERROR: $DSTD doesn't exist"
+ exit 1
+ fi
+
+ $DIFF -Nurd $SRCD $DSTD
+}
+
+doclean() {
+ [ $# -eq 0 ] && usage
+ [ $# -gt 1 ] && usage
+
+ if [ "x$1" = "xall" ]; then
+ rm -rf /tmp/objdiff-*
+ else
+ CMT="`git rev-parse --short $1`"
+
+ if [ -d "/tmp/objdiff-$CMT" ]; then
+ rm -rf /tmp/objdiff-$CMT
+ else
+ echo "$CMT not found"
+ fi
+ fi
+}
+
+[ $# -eq 0 ] &&usage
+
+case "$1" in
+ record)
+ shift
+ dorecord $*
+ ;;
+ diff)
+ shift
+ dodiff $*
+ ;;
+ clean)
+ shift
+ doclean $*
+ ;;
+ *)
+ echo "Unrecognized command '$1'"
+ exit 1
+ ;;
+esac
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 14/22] staging: crypto: skein: remove trailing whitespace
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h| 16 +-
drivers/staging/skein/include/skeinApi.h | 44 ++--
drivers/staging/skein/include/threefishApi.h | 40 -
drivers/staging/skein/skeinBlockNo3F.c | 6 ++--
drivers/staging/skein/skein_block.c | 20 ++---
5 files changed, 63 insertions(+), 63 deletions(-)
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index 906bcee41c39..dd9a210cf5dd 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -9,7 +9,7 @@
** This algorithm and source code is released to the public domain.
**
***
-**
+**
** The following compile-time switches may be defined to control some
** tradeoffs between speed, code size, error checking, and security.
**
@@ -20,8 +20,8 @@
**[default: no callouts (no overhead)]
**
** SKEIN_ERR_CHECK-- how error checking is handled inside Skein
-**code. If not defined, most error checking
-**is disabled (for performance). Otherwise,
+**code. If not defined, most error checking
+**is disabled (for performance). Otherwise,
**the switch value is interpreted as:
**0: use assert() to flag errors
**1: return SKEIN_FAIL to flag errors
@@ -109,12 +109,12 @@ int Skein1024_Final(struct skein1024_ctx *ctx, u8
*hashVal);
** After an InitExt() call, just use Update/Final calls as with Init().
**
** Notes: Same parameters as _Init() calls, plus treeInfo/key/keyBytes.
-** When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL,
+** When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL,
** the results of InitExt() are identical to calling Init().
** The function Init() may be called once to "precompute" the IV for
** a given hashBitLen value, then by saving a copy of the context
** the IV computation may be avoided in later calls.
-** Similarly, the function InitExt() may be called once per MAC key
+** Similarly, the function InitExt() may be called once per MAC key
** to precompute the MAC IV, then a copy of the context saved and
** reused for each new MAC computation.
**/
@@ -142,7 +142,7 @@ int Skein1024_Output(struct skein1024_ctx *ctx, u8
*hashVal);
/*
** "Internal" Skein definitions
-**-- not needed for sequential hashing API, but will be
+**-- not needed for sequential hashing API, but will be
** helpful for other uses of Skein (e.g., tree hash mode).
**-- included here so that they can be shared between
** reference and optimized code.
@@ -269,8 +269,8 @@ int Skein1024_Output(struct skein1024_ctx *ctx, u8
*hashVal);
/*
** Skein block function constants (shared across Ref and Opt code)
**/
-enum
- {
+enum
+ {
/* Skein_256 round rotation constants */
R_256_0_0 = 14, R_256_0_1 = 16,
R_256_1_0 = 52, R_256_1_1 = 57,
diff --git a/drivers/staging/skein/include/skeinApi.h
b/drivers/staging/skein/include/skeinApi.h
index 0d7d59eff460..ace931a67c23 100644
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -36,46 +36,46 @@ OTHER DEALINGS IN THE SOFTWARE.
* of Skein. The design and the way to use the functions follow the openSSL
* design but at the same time take care of some Skein specific behaviour
* and possibilities.
- *
+ *
* The functions enable applications to create a normal Skein hashes and
* message authentication codes (MAC).
- *
+ *
* Using these functions is simple and straight forward:
- *
+ *
* @code
- *
+ *
* #include
- *
+ *
* ...
* struct skein_ctx ctx; // a Skein hash or MAC context
- *
+ *
* // prepare context, here for a Skein with a state size of 512 bits.
* skeinCtxPrepare(&ctx, Skein512);
- *
+ *
* // Initialize the context to set the requested hash length in bits
* // here request a output hash size of 31 bits (Skein supports variable
* // output sizes even very strange sizes)
* skeinInit(&ctx, 31);
- *
+ *
* // Now update Skein with any number of message bits. A function that
* // takes a number of bytes is also available.
* skeinUpdateBits(&ctx, message, msgLength);
- *
+ *
* // Now get the result of the Skein hash. The output buffer must be
* // large enough to hold the re
[RFC PATCH 06/22] staging: crypto: skein: remove __cplusplus and an unneeded stddef.h
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h| 11 ---
drivers/staging/skein/include/skeinApi.h | 9 -
drivers/staging/skein/include/threefishApi.h | 9 -
3 files changed, 29 deletions(-)
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index 211aca1b1036..b1e55b08d150 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -27,13 +27,6 @@
**1: return SKEIN_FAIL to flag errors
**
***/
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-
-#include /* get size_t definition */
-
typedef unsigned intuint_t; /* native unsigned integer */
typedef uint8_t u08b_t; /* 8-bit unsigned integer */
typedef uint64_tu64b_t; /* 64-bit unsigned integer */
@@ -322,8 +315,4 @@ enum
#define SKEIN1024_ROUNDS_TOTAL (8*SKEIN_ROUNDS) + 5) % 10) + 5))
#endif
-#ifdef __cplusplus
-}
-#endif
-
#endif /* ifndef _SKEIN_H_ */
diff --git a/drivers/staging/skein/include/skeinApi.h
b/drivers/staging/skein/include/skeinApi.h
index 734d27b79f01..f55c67e81f2b 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -81,11 +81,6 @@ OTHER DEALINGS IN THE SOFTWARE.
#include
#include
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-
/**
* Which Skein size to use
*/
@@ -229,10 +224,6 @@ extern "C"
*/
int skeinFinal(SkeinCtx_t* ctx, uint8_t* hash);
-#ifdef __cplusplus
-}
-#endif
-
/**
* @}
*/
diff --git a/drivers/staging/skein/include/threefishApi.h
b/drivers/staging/skein/include/threefishApi.h
index dae270cf71d3..aaecfe822142 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -33,11 +33,6 @@
#define KeyScheduleConst 0x1BD11BDAA9FC1A22L
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-
/**
* Which Threefish size to use
*/
@@ -157,10 +152,6 @@ extern "C"
void threefishDecrypt256(ThreefishKey_t* keyCtx, uint64_t* input,
uint64_t* output);
void threefishDecrypt512(ThreefishKey_t* keyCtx, uint64_t* input,
uint64_t* output);
void threefishDecrypt1024(ThreefishKey_t* keyCtx, uint64_t* input,
uint64_t* output);
-#ifdef __cplusplus
-}
-#endif
-
/**
* @}
*/
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 07/22] staging: crypto: skein: remove unneeded typedefs
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h| 73 ++---
drivers/staging/skein/include/skeinApi.h | 4 +-
drivers/staging/skein/include/skein_iv.h | 26
drivers/staging/skein/include/threefishApi.h | 6 +-
drivers/staging/skein/skein.c| 96 ++--
drivers/staging/skein/skeinApi.c | 24 +++
drivers/staging/skein/skeinBlockNo3F.c | 30 -
drivers/staging/skein/skein_block.c | 54
drivers/staging/skein/threefishApi.c | 8 +--
9 files changed, 159 insertions(+), 162 deletions(-)
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index b1e55b08d150..12c5c8d612b0 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -27,9 +27,6 @@
**1: return SKEIN_FAIL to flag errors
**
***/
-typedef unsigned intuint_t; /* native unsigned integer */
-typedef uint8_t u08b_t; /* 8-bit unsigned integer */
-typedef uint64_tu64b_t; /* 64-bit unsigned integer */
#ifndef RotL_64
#define RotL_64(x,N)(((x) << (N)) | ((x) >> (64-(N
@@ -70,28 +67,28 @@ typedef struct
{
size_t hashBitLen; /* size of hash result, in bits */
size_t bCnt;/* current byte count in buffer
b[] */
-u64b_t T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt,
T[1]=flags */
+u64 T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt,
T[1]=flags */
} Skein_Ctxt_Hdr_t;
typedef struct /* 256-bit Skein hash context
structure */
{
Skein_Ctxt_Hdr_t h; /* common header context
variables */
-u64b_t X[SKEIN_256_STATE_WORDS];/* chaining variables */
-u08b_t b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
+u64 X[SKEIN_256_STATE_WORDS];/* chaining variables */
+u8 b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
} Skein_256_Ctxt_t;
typedef struct /* 512-bit Skein hash context
structure */
{
Skein_Ctxt_Hdr_t h; /* common header context
variables */
-u64b_t X[SKEIN_512_STATE_WORDS];/* chaining variables */
-u08b_t b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
+u64 X[SKEIN_512_STATE_WORDS];/* chaining variables */
+u8 b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
} Skein_512_Ctxt_t;
typedef struct /* 1024-bit Skein hash context
structure */
{
Skein_Ctxt_Hdr_t h; /* common header context
variables */
-u64b_t X[SKEIN1024_STATE_WORDS];/* chaining variables */
-u08b_t b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
+u64 X[SKEIN1024_STATE_WORDS];/* chaining variables */
+u8 b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
} Skein1024_Ctxt_t;
/* Skein APIs for (incremental) "straight hashing" */
@@ -99,13 +96,13 @@ int Skein_256_Init (Skein_256_Ctxt_t *ctx, size_t
hashBitLen);
int Skein_512_Init (Skein_512_Ctxt_t *ctx, size_t hashBitLen);
int Skein1024_Init (Skein1024_Ctxt_t *ctx, size_t hashBitLen);
-int Skein_256_Update(Skein_256_Ctxt_t *ctx, const u08b_t *msg, size_t
msgByteCnt);
-int Skein_512_Update(Skein_512_Ctxt_t *ctx, const u08b_t *msg, size_t
msgByteCnt);
-int Skein1024_Update(Skein1024_Ctxt_t *ctx, const u08b_t *msg, size_t
msgByteCnt);
+int Skein_256_Update(Skein_256_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int Skein_512_Update(Skein_512_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int Skein1024_Update(Skein1024_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
-int Skein_256_Final (Skein_256_Ctxt_t *ctx, u08b_t * hashVal);
-int Skein_512_Final (Skein_512_Ctxt_t *ctx, u08b_t * hashVal);
-int Skein1024_Final (Skein1024_Ctxt_t *ctx, u08b_t * hashVal);
+int Skein_256_Final (Skein_256_Ctxt_t *ctx, u8 * hashVal);
+int Skein_512_Final (Skein_512_Ctxt_t *ctx, u8 * hashVal);
+int Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * hashVal);
/*
** Skein APIs for "extended" initialization: MAC keys, tree hashing.
@@ -121,26 +118,26 @@ int Skein1024_Final (Skein1024_Ctxt_t *ctx, u08b_t *
hashVal);
** to precompute the MAC IV, then a copy of the context saved and
** reused for each new MAC computation.
**/
-int Skein_256_InitExt(Skein_256_Ctxt_t *ctx, size_t hashBitLen, u64b_t
treeInfo, const u08b_t *key, size_t keyBytes);
-int Skein_512_InitExt(Skein_51
[RFC PATCH 00/22] staging: add skein/threefish crypto algos
Greg, all,
Attached is a series I've sat on for the past month and a half.
I'm hoping that by posting it in it's incomplete state, it will either a)
motivate me to finish hooking into the crypto API, or b) motivate someone else
to pitch in. ;-)
>From patch 3, all commits build successfully. In addition, using the script I
added in patch 1, I can confirm that no object code was harmed in this process.
I'm under no time crunch with this, and I add to it as I find time. If Greg
wants to take it for v3.15, great. Otherwise is fine as well. It's been a
while since I watched the inner workings of the staging tree, so I'm not
familiar with how strict it is recently.
Barring a few false-positives, this series makes the code checkpatch-clean, but
it is not ready for mainline as yet. In particular, I really don't like the
adhoc macro definitions, nor the camelCase.
The plan is to get skein and threefish registered into the crypto API, build as
modules, and then move it to crypto/.
To facilitate tinkering with this, One can pull from the following:
git://git.infradead.org/users/jcooper/linux.git tags/staging-skein-3.14-rc1
This is based on v3.14-rc1, and is prone to rebasing based on comments.
thx,
Jason.
Jason Cooper (22):
scripts: objdiff: detect object code changes between two commits
staging: crypto: skein: import code from Skein3Fish.git
staging: crypto: skein: allow building statically
staging: crypto: skein: remove brg_*.h includes
staging: crypto: skein: remove skein_port.h
staging: crypto: skein: remove __cplusplus and an unneeded stddef.h
staging: crypto: skein: remove unneeded typedefs
staging: crypto: skein: remove all typedef {struct,enum}
staging: crypto: skein: use u8, u64 vice uint*_t
staging: crypto: skein: fixup pointer whitespace
staging: crypto: skein: cleanup whitespace around operators/punc.
staging: crypto: skein: dos2unix, remove executable perms
staging: crypto: skein: fix leading whitespace
staging: crypto: skein: remove trailing whitespace
staging: crypto: skein: cleanup >80 character lines
staging: crypto: skein: fix do/while brace formatting
staging: crypto: skein: fix brace placement errors
staging: crypto: skein: wrap multi-line macros in do-while loops
staging: crypto: skein: remove externs from .c files
staging: crypto: skein: remove braces from single-statement block
staging: crypto: skein: remove unnecessary line continuation
staging: crypto: skein: add TODO file
drivers/staging/Kconfig |2 +
drivers/staging/Makefile |1 +
drivers/staging/skein/Kconfig| 32 +
drivers/staging/skein/Makefile | 13 +
drivers/staging/skein/TODO | 11 +
drivers/staging/skein/include/skein.h| 344 ++
drivers/staging/skein/include/skeinApi.h | 230 ++
drivers/staging/skein/include/skein_block.h | 22 +
drivers/staging/skein/include/skein_iv.h | 186 +
drivers/staging/skein/include/threefishApi.h | 164 +
drivers/staging/skein/skein.c| 880 +
drivers/staging/skein/skeinApi.c | 237 ++
drivers/staging/skein/skeinBlockNo3F.c | 175 +
drivers/staging/skein/skein_block.c | 770
drivers/staging/skein/threefish1024Block.c | 4900 ++
drivers/staging/skein/threefish256Block.c| 1137 ++
drivers/staging/skein/threefish512Block.c| 2223
drivers/staging/skein/threefishApi.c | 79 +
scripts/objdiff | 126 +
19 files changed, 11532 insertions(+)
create mode 100644 drivers/staging/skein/Kconfig
create mode 100644 drivers/staging/skein/Makefile
create mode 100644 drivers/staging/skein/TODO
create mode 100644 drivers/staging/skein/include/skein.h
create mode 100644 drivers/staging/skein/include/skeinApi.h
create mode 100644 drivers/staging/skein/include/skein_block.h
create mode 100644 drivers/staging/skein/include/skein_iv.h
create mode 100644 drivers/staging/skein/include/threefishApi.h
create mode 100644 drivers/staging/skein/skein.c
create mode 100644 drivers/staging/skein/skeinApi.c
create mode 100644 drivers/staging/skein/skeinBlockNo3F.c
create mode 100644 drivers/staging/skein/skein_block.c
create mode 100644 drivers/staging/skein/threefish1024Block.c
create mode 100644 drivers/staging/skein/threefish256Block.c
create mode 100644 drivers/staging/skein/threefish512Block.c
create mode 100644 drivers/staging/skein/threefishApi.c
create mode 100755 scripts/objdiff
--
1.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 08/22] staging: crypto: skein: remove all typedef {struct, enum}
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h| 58 ++--
drivers/staging/skein/include/skeinApi.h | 32 +++
drivers/staging/skein/include/threefishApi.h | 32 +++
drivers/staging/skein/skein.c| 42 ++--
drivers/staging/skein/skeinApi.c | 16
drivers/staging/skein/skeinBlockNo3F.c | 12 +++---
drivers/staging/skein/skein_block.c | 6 +--
drivers/staging/skein/threefish1024Block.c | 4 +-
drivers/staging/skein/threefish256Block.c| 4 +-
drivers/staging/skein/threefish512Block.c| 4 +-
drivers/staging/skein/threefishApi.c | 10 ++---
11 files changed, 110 insertions(+), 110 deletions(-)
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index 12c5c8d612b0..77b712e73253 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -63,46 +63,46 @@ enum
#define SKEIN_512_BLOCK_BYTES ( 8*SKEIN_512_STATE_WORDS)
#define SKEIN1024_BLOCK_BYTES ( 8*SKEIN1024_STATE_WORDS)
-typedef struct
+struct skein_ctx_hdr
{
size_t hashBitLen; /* size of hash result, in bits */
size_t bCnt;/* current byte count in buffer
b[] */
u64 T[SKEIN_MODIFIER_WORDS]; /* tweak words: T[0]=byte cnt,
T[1]=flags */
-} Skein_Ctxt_Hdr_t;
+};
-typedef struct /* 256-bit Skein hash context
structure */
+struct skein_256_ctx /* 256-bit Skein hash
context structure */
{
-Skein_Ctxt_Hdr_t h; /* common header context
variables */
+struct skein_ctx_hdr h; /* common header context
variables */
u64 X[SKEIN_256_STATE_WORDS];/* chaining variables */
u8 b[SKEIN_256_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
-} Skein_256_Ctxt_t;
+};
-typedef struct /* 512-bit Skein hash context
structure */
+struct skein_512_ctx /* 512-bit Skein hash
context structure */
{
-Skein_Ctxt_Hdr_t h; /* common header context
variables */
+struct skein_ctx_hdr h; /* common header context
variables */
u64 X[SKEIN_512_STATE_WORDS];/* chaining variables */
u8 b[SKEIN_512_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
-} Skein_512_Ctxt_t;
+};
-typedef struct /* 1024-bit Skein hash context
structure */
+struct skein1024_ctx /* 1024-bit Skein hash
context structure */
{
-Skein_Ctxt_Hdr_t h; /* common header context
variables */
+struct skein_ctx_hdr h; /* common header context
variables */
u64 X[SKEIN1024_STATE_WORDS];/* chaining variables */
u8 b[SKEIN1024_BLOCK_BYTES];/* partial block buffer (8-byte
aligned) */
-} Skein1024_Ctxt_t;
+};
/* Skein APIs for (incremental) "straight hashing" */
-int Skein_256_Init (Skein_256_Ctxt_t *ctx, size_t hashBitLen);
-int Skein_512_Init (Skein_512_Ctxt_t *ctx, size_t hashBitLen);
-int Skein1024_Init (Skein1024_Ctxt_t *ctx, size_t hashBitLen);
+int Skein_256_Init (struct skein_256_ctx *ctx, size_t hashBitLen);
+int Skein_512_Init (struct skein_512_ctx *ctx, size_t hashBitLen);
+int Skein1024_Init (struct skein1024_ctx *ctx, size_t hashBitLen);
-int Skein_256_Update(Skein_256_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
-int Skein_512_Update(Skein_512_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
-int Skein1024_Update(Skein1024_Ctxt_t *ctx, const u8 *msg, size_t msgByteCnt);
+int Skein_256_Update(struct skein_256_ctx *ctx, const u8 *msg, size_t
msgByteCnt);
+int Skein_512_Update(struct skein_512_ctx *ctx, const u8 *msg, size_t
msgByteCnt);
+int Skein1024_Update(struct skein1024_ctx *ctx, const u8 *msg, size_t
msgByteCnt);
-int Skein_256_Final (Skein_256_Ctxt_t *ctx, u8 * hashVal);
-int Skein_512_Final (Skein_512_Ctxt_t *ctx, u8 * hashVal);
-int Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 * hashVal);
+int Skein_256_Final (struct skein_256_ctx *ctx, u8 * hashVal);
+int Skein_512_Final (struct skein_512_ctx *ctx, u8 * hashVal);
+int Skein1024_Final (struct skein1024_ctx *ctx, u8 * hashVal);
/*
** Skein APIs for "extended" initialization: MAC keys, tree hashing.
@@ -118,26 +118,26 @@ int Skein1024_Final (Skein1024_Ctxt_t *ctx, u8 *
hashVal);
** to precompute the MAC IV, then a copy of the context saved and
** reused for each new MAC computation.
**/
-int Skein_256_InitExt(Skein_256_Ctxt_t *ctx, size_t hashBitLen, u64 treeInfo,
const u8 *key, size_t keyBytes);
-int Skein_512_InitExt(Skein_512_Ctxt_t *ctx, size_t hashBitLen, u64 tree
[RFC PATCH 17/22] staging: crypto: skein: fix brace placement errors
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h| 30 -
drivers/staging/skein/include/skein_iv.h | 65 --
drivers/staging/skein/skein.c| 111 ++-
3 files changed, 74 insertions(+), 132 deletions(-)
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index f92dc40711d1..0a2abcecd2f7 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -37,12 +37,11 @@
#define Skein_Get64_LSB_First(dst64, src08, wCnt) memcpy(dst64, src08,
8*(wCnt))
#define Skein_Swap64(w64) (w64)
-enum
- {
+enum {
SKEIN_SUCCESS = 0, /* return codes from Skein calls */
SKEIN_FAIL= 1,
SKEIN_BAD_HASHLEN = 2
- };
+};
#define SKEIN_MODIFIER_WORDS (2) /* number of modifier (tweak) words */
@@ -63,33 +62,29 @@ enum
#define SKEIN_512_BLOCK_BYTES (8*SKEIN_512_STATE_WORDS)
#define SKEIN1024_BLOCK_BYTES (8*SKEIN1024_STATE_WORDS)
-struct skein_ctx_hdr
- {
+struct skein_ctx_hdr {
size_t hashBitLen; /* size of hash result, in bits */
size_t bCnt; /* current byte count in buffer b[] */
u64 T[SKEIN_MODIFIER_WORDS]; /* tweak: T[0]=byte cnt, T[1]=flags */
- };
+};
-struct skein_256_ctx /* 256-bit Skein hash context structure */
- {
+struct skein_256_ctx { /* 256-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64 X[SKEIN_256_STATE_WORDS]; /* chaining variables */
u8 b[SKEIN_256_BLOCK_BYTES]; /* partial block buf (8-byte aligned) */
- };
+};
-struct skein_512_ctx /* 512-bit Skein hash context structure */
- {
+struct skein_512_ctx { /* 512-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64 X[SKEIN_512_STATE_WORDS]; /* chaining variables */
u8 b[SKEIN_512_BLOCK_BYTES]; /* partial block buf (8-byte aligned) */
- };
+};
-struct skein1024_ctx /* 1024-bit Skein hash context structure */
- {
+struct skein1024_ctx { /* 1024-bit Skein hash context structure */
struct skein_ctx_hdr h; /* common header context variables */
u64 X[SKEIN1024_STATE_WORDS]; /* chaining variables */
u8 b[SKEIN1024_BLOCK_BYTES]; /* partial block buf (8-byte aligned) */
- };
+};
/* Skein APIs for (incremental) "straight hashing" */
int Skein_256_Init(struct skein_256_ctx *ctx, size_t hashBitLen);
@@ -296,8 +291,7 @@ int Skein1024_Output(struct skein1024_ctx *ctx, u8
*hashVal);
/*
** Skein block function constants (shared across Ref and Opt code)
**/
-enum
- {
+enum {
/* Skein_256 round rotation constants */
R_256_0_0 = 14, R_256_0_1 = 16,
R_256_1_0 = 52, R_256_1_1 = 57,
@@ -335,7 +329,7 @@ enum
R1024_6_4 = 19, R1024_6_5 = 42, R1024_6_6 = 44, R1024_6_7 = 25,
R1024_7_0 = 9, R1024_7_1 = 48, R1024_7_2 = 35, R1024_7_3 = 52,
R1024_7_4 = 23, R1024_7_5 = 31, R1024_7_6 = 37, R1024_7_7 = 20
- };
+};
#ifndef SKEIN_ROUNDS
#define SKEIN_256_ROUNDS_TOTAL (72)/* # rounds for diff block sizes */
diff --git a/drivers/staging/skein/include/skein_iv.h
b/drivers/staging/skein/include/skein_iv.h
index a77c44d3..8dd5e4d88a1d 100644
--- a/drivers/staging/skein/include/skein_iv.h
+++ b/drivers/staging/skein/include/skein_iv.h
@@ -20,44 +20,39 @@
#define MK_64 SKEIN_MK_64
/* blkSize = 256 bits. hashSize = 128 bits */
-const u64 SKEIN_256_IV_128[] =
- {
+const u64 SKEIN_256_IV_128[] = {
MK_64(0xE906, 0x964D7260),
MK_64(0x883DAAA7, 0x7C8D811C),
MK_64(0x10080DF4, 0x91960F7A),
MK_64(0xCCF7DDE5, 0xB45BC1C2)
- };
+};
/* blkSize = 256 bits. hashSize = 160 bits */
-const u64 SKEIN_256_IV_160[] =
- {
+const u64 SKEIN_256_IV_160[] = {
MK_64(0x14202314, 0x72825E98),
MK_64(0x2AC4E9A2, 0x5A77E590),
MK_64(0xD47A5856, 0x8838D63E),
MK_64(0x2DD2E496, 0x8586AB7D)
- };
+};
/* blkSize = 256 bits. hashSize = 224 bits */
-const u64 SKEIN_256_IV_224[] =
- {
+const u64 SKEIN_256_IV_224[] = {
MK_64(0xC6098A8C, 0x9AE5EA0B),
MK_64(0x876D5686, 0x08C5191C),
MK_64(0x99CB88D7, 0xD7F53884),
MK_64(0x384BDDB1, 0xAEDDB5DE)
- };
+};
/* blkSize = 256 bits. hashSize = 256 bits */
-const u64 SKEIN_256_IV_256[] =
- {
+const u64 SKEIN_256_IV_256[] = {
MK_64(0xFC9DA860, 0xD048B449),
MK_64(0x2FCA6647, 0x9FA7D833),
MK_64(0xB33BC389, 0x6656840F),
MK_64(0x6A54E920, 0xFDE8DA69)
- };
+};
/* blkSize = 512 bits. hashSize = 128 bits */
-const u64 SKEIN_
[RFC PATCH 03/22] staging: crypto: skein: allow building statically
These are the minimum changes required to get the code to build
statically in the kernel. It's necessary to do this first so that we
can empirically determine that future cleanup patches aren't changing
the generated object code.
Signed-off-by: Jason Cooper
---
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/skein/CMakeLists.txt | 27 -
drivers/staging/skein/Kconfig| 32
drivers/staging/skein/Makefile | 13 +++
drivers/staging/skein/include/brg_types.h| 57
drivers/staging/skein/include/skein.h| 10 -
drivers/staging/skein/include/skeinApi.h | 2 +-
drivers/staging/skein/include/skein_port.h | 16 +---
drivers/staging/skein/include/threefishApi.h | 2 +-
drivers/staging/skein/skein.c| 2 +-
drivers/staging/skein/skeinApi.c | 4 +-
drivers/staging/skein/skeinBlockNo3F.c | 2 +-
drivers/staging/skein/skein_block.c | 2 +-
drivers/staging/skein/threefish1024Block.c | 3 +-
drivers/staging/skein/threefish256Block.c| 3 +-
drivers/staging/skein/threefish512Block.c| 3 +-
drivers/staging/skein/threefishApi.c | 3 +-
18 files changed, 59 insertions(+), 125 deletions(-)
delete mode 100755 drivers/staging/skein/CMakeLists.txt
create mode 100644 drivers/staging/skein/Kconfig
create mode 100644 drivers/staging/skein/Makefile
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 99375f0a9440..fbcbe833dc89 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -146,4 +146,6 @@ source "drivers/staging/dgnc/Kconfig"
source "drivers/staging/dgap/Kconfig"
+source "drivers/staging/skein/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index ddc3c4a5d39d..2dee51d1a483 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS)+= xillybus/
obj-$(CONFIG_DGNC) += dgnc/
obj-$(CONFIG_DGAP) += dgap/
obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/
+obj-$(CONFIG_CRYPTO_SKEIN) += skein/
diff --git a/drivers/staging/skein/CMakeLists.txt
b/drivers/staging/skein/CMakeLists.txt
deleted file mode 100755
index 604aaa394cb1..
--- a/drivers/staging/skein/CMakeLists.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-cmake_minimum_required (VERSION 2.6)
-
-include_directories (${CMAKE_CURRENT_SOURCE_DIR}/include)
-
-# set(skeinBlock_src skein_block.c)
-set(skeinBlock_src skeinBlockNo3F.c)
-
-set(skein_src
-${skeinBlock_src}
-skein.c
-skeinApi.c
-)
-
-set(threefish_src
-threefishApi.c
-threefish256Block.c
-threefish512Block.c
-threefish1024Block.c
-)
-set(s3f_src ${skein_src} ${threefish_src})
-
-add_library(skein3fish SHARED ${s3f_src})
-set_target_properties(skein3fish PROPERTIES VERSION ${VERSION} SOVERSION
${SOVERSION})
-target_link_libraries(skein3fish ${LIBS})
-
-install(TARGETS skein3fish DESTINATION ${LIBDIRNAME})
-
diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
new file mode 100644
index ..8f5a72a90ced
--- /dev/null
+++ b/drivers/staging/skein/Kconfig
@@ -0,0 +1,32 @@
+config CRYPTO_SKEIN
+ bool "Skein digest algorithm"
+ depends on (X86 || UML_X86) && 64BIT
+ select CRYPTO_THREEFISH
+ select CRYPTO_HASH
+ help
+ Skein secure hash algorithm is one of 5 finalists from the NIST SHA3
+ competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable. See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information. This module depends on the threefish block
+ cipher module.
+
+config CRYPTO_THREEFISH
+ bool "Threefish tweakable block cipher"
+ depends on (X86 || UML_X86) && 64BIT
+ select CRYPTO_ALGAPI
+ help
+ Threefish cipher algorithm is the tweakable block cipher underneath
+ the Skein family of secure hash algorithms. Skein is one of 5
+ finalists from the NIST SHA3 competition.
+
+ Skein is optimized for modern, 64bit processors and is highly
+ customizable. See:
+
+ http://www.skein-hash.info/sites/default/files/skein1.3.pdf
+
+ for more information.
diff --git a/drivers/staging/skein/Makefile b/drivers/staging/skein/Makefile
new file mode 100644
index ..2bb386e1e58c
--- /dev/null
+++ b/drivers/staging/skein/Makefile
@@ -0,0 +1,13 @@
+#
+# Makefile for the skein secure hash algorithm
+#
+subdir-ccflags-y := -I$(src)/include/
+
+obj-$(CONFIG_CRYPTO_SKEIN) += skein.o \
+ skeinApi.o \
+
Re: [RFC PATCH 00/22] staging: add skein/threefish crypto algos
On Tue, Mar 11, 2014 at 09:32:32PM +, Jason Cooper wrote: > To facilitate tinkering with this, One can pull from the following: > > git://git.infradead.org/users/jcooper/linux.git tags/staging-skein-3.14-rc1 > > This is based on v3.14-rc1, and is prone to rebasing based on comments. Hmmm, apparently, I forgot to tell you *how* to tinker with this :) Once you've pulled in the series, $ make ARCH=x86_64 defconfig enable CRYPTO_SKEIN (implies CRYPTO_THREEFISH) under drivers/staging. $ git rebase -i v3.14-rc1 In the rebase config file: ### pick cc77327 scripts: objdiff: detect object code changes between two commits pick bdb4dad staging: crypto: skein: import code from Skein3Fish.git pick e3d822c staging: crypto: skein: allow building statically x kbuild.sh none x ./scripts/objdiff record drivers/staging/skein/*.o pick 227c819 staging: crypto: skein: remove brg_*.h includes x kbuild.sh none x ./scripts/objdiff record drivers/staging/skein/*.o x ./scripts/objdiff diff HEAD^ HEAD pick c175303 staging: crypto: skein: remove skein_port.h x kbuild.sh none x ./scripts/objdiff record drivers/staging/skein/*.o x ./scripts/objdiff diff HEAD^ HEAD pick a612f45 staging: crypto: skein: remove __cplusplus and an unneeded stddef.h x kbuild.sh none x ./scripts/objdiff record drivers/staging/skein/*.o x ./scripts/objdiff diff HEAD^ HEAD ... lather, rinse, repeat ... pick 4438372 staging: crypto: skein: remove unnecessary line continuation x kbuild.sh none x ./scripts/objdiff record drivers/staging/skein/*.o x ./scripts/objdiff diff HEAD^ HEAD pick 641f05d staging: crypto: skein: add TODO file x kbuild.sh none x ./scripts/objdiff record drivers/staging/skein/*.o x ./scripts/objdiff diff HEAD^ HEAD ... ### Save, quit, let it run (kbuild.sh is my local script for building the kernel) If it makes it to the end, then the object code never changed. Well, it works here. ;-) Once you're finished poking around (objdump output in is /tmp/objdiff-/): $ ./scripts/objdiff clean all Also, it looks like linux-crypto dropped several of the patches for being too large. Here's a link to the top of the series (choose the linuxdriverproject archive): https://lkml.kernel.org/r/cover.1394570067.git.ja...@lakedaemon.net hth, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 03/22] staging: crypto: skein: allow building statically
On Mon, Mar 17, 2014 at 02:52:52PM -0700, Greg KH wrote: > On Tue, Mar 11, 2014 at 09:32:35PM +0000, Jason Cooper wrote: > > These are the minimum changes required to get the code to build > > statically in the kernel. It's necessary to do this first so that we > > can empirically determine that future cleanup patches aren't changing > > the generated object code. > > > > Signed-off-by: Jason Cooper > > This doesn't apply to my latest tree :( Ah, ok. I'll rebase this series on the staging tree. > > --- a/drivers/staging/Makefile > > +++ b/drivers/staging/Makefile > > @@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS)+= xillybus/ > > obj-$(CONFIG_DGNC) += dgnc/ > > obj-$(CONFIG_DGAP) += dgap/ > > obj-$(CONFIG_MTD_SPINAND_MT29F)+= mt29f_spinand/ > > +obj-$(CONFIG_CRYPTO_SKEIN) += skein/ > > Care to align these up with the way this file is formatted? Of course, not sure what happened there (well, other than the obvious :-P) > And I have no objection to taking the drivers/staging/ patches, the > script looks useful, but I can't take it through the staging tree, > sorry. Ok, I'll pull that out as a separate branch. Do you mind taking a series that depends on a topic branch from another tree? We do it a lot in arm-soc, but I'm not sure how popular that is elsewhere. It's purely an audit/testing dependency, but it would be nice to have it available in the history if someone wants to audit the changes. I have one change I'd like to do to the objdiff script. I'd like it to assume 'HEAD^ HEAD' when the user executes './scripts/objdiff diff'. I'll respin both and submit a v1. Thanks for the review. thx, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 05/21] staging: crypto: skein: remove __cplusplus and an unneeded stddef.h
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h| 11 ---
drivers/staging/skein/include/skeinApi.h | 9 -
drivers/staging/skein/include/threefishApi.h | 9 -
3 files changed, 29 deletions(-)
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index 211aca1b1036..b1e55b08d150 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -27,13 +27,6 @@
**1: return SKEIN_FAIL to flag errors
**
***/
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-
-#include /* get size_t definition */
-
typedef unsigned intuint_t; /* native unsigned integer */
typedef uint8_t u08b_t; /* 8-bit unsigned integer */
typedef uint64_tu64b_t; /* 64-bit unsigned integer */
@@ -322,8 +315,4 @@ enum
#define SKEIN1024_ROUNDS_TOTAL (8*SKEIN_ROUNDS) + 5) % 10) + 5))
#endif
-#ifdef __cplusplus
-}
-#endif
-
#endif /* ifndef _SKEIN_H_ */
diff --git a/drivers/staging/skein/include/skeinApi.h
b/drivers/staging/skein/include/skeinApi.h
index 734d27b79f01..f55c67e81f2b 100755
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -81,11 +81,6 @@ OTHER DEALINGS IN THE SOFTWARE.
#include
#include
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-
/**
* Which Skein size to use
*/
@@ -229,10 +224,6 @@ extern "C"
*/
int skeinFinal(SkeinCtx_t* ctx, uint8_t* hash);
-#ifdef __cplusplus
-}
-#endif
-
/**
* @}
*/
diff --git a/drivers/staging/skein/include/threefishApi.h
b/drivers/staging/skein/include/threefishApi.h
index dae270cf71d3..aaecfe822142 100644
--- a/drivers/staging/skein/include/threefishApi.h
+++ b/drivers/staging/skein/include/threefishApi.h
@@ -33,11 +33,6 @@
#define KeyScheduleConst 0x1BD11BDAA9FC1A22L
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-
/**
* Which Threefish size to use
*/
@@ -157,10 +152,6 @@ extern "C"
void threefishDecrypt256(ThreefishKey_t* keyCtx, uint64_t* input,
uint64_t* output);
void threefishDecrypt512(ThreefishKey_t* keyCtx, uint64_t* input,
uint64_t* output);
void threefishDecrypt1024(ThreefishKey_t* keyCtx, uint64_t* input,
uint64_t* output);
-#ifdef __cplusplus
-}
-#endif
-
/**
* @}
*/
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 04/21] staging: crypto: skein: remove skein_port.h
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h | 14 +++-
drivers/staging/skein/include/skein_port.h | 108 -
drivers/staging/skein/skein.c | 21 --
3 files changed, 13 insertions(+), 130 deletions(-)
delete mode 100644 drivers/staging/skein/include/skein_port.h
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index 315cdcd14413..211aca1b1036 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -33,7 +33,19 @@ extern "C"
#endif
#include /* get size_t definition */
-#include/* get platform-specific definitions */
+
+typedef unsigned intuint_t; /* native unsigned integer */
+typedef uint8_t u08b_t; /* 8-bit unsigned integer */
+typedef uint64_tu64b_t; /* 64-bit unsigned integer */
+
+#ifndef RotL_64
+#define RotL_64(x,N)(((x) << (N)) | ((x) >> (64-(N
+#endif
+
+/* below two prototype assume we are handed aligned data */
+#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
+#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
+#define Skein_Swap64(w64) (w64)
enum
{
diff --git a/drivers/staging/skein/include/skein_port.h
b/drivers/staging/skein/include/skein_port.h
deleted file mode 100644
index e78c976dccc5..
--- a/drivers/staging/skein/include/skein_port.h
+++ /dev/null
@@ -1,108 +0,0 @@
-#ifndef _SKEIN_PORT_H_
-#define _SKEIN_PORT_H_
-/***
-**
-** Platform-specific definitions for Skein hash function.
-**
-** Source code author: Doug Whiting, 2008.
-**
-** This algorithm and source code is released to the public domain.
-**
-** Many thanks to Brian Gladman for his portable header files.
-**
-** To port Skein to an "unsupported" platform, change the definitions
-** in this file appropriately.
-**
-/
-
-typedef unsigned intuint_t; /* native unsigned integer */
-typedef uint8_t u08b_t; /* 8-bit unsigned integer */
-typedef uint64_tu64b_t; /* 64-bit unsigned integer */
-
-#ifndef RotL_64
-#define RotL_64(x,N)(((x) << (N)) | ((x) >> (64-(N
-#endif
-
-/*
- * Skein is "natively" little-endian (unlike SHA-xxx), for optimal
- * performance on x86 CPUs. The Skein code requires the following
- * definitions for dealing with endianness:
- *
- *SKEIN_NEED_SWAP: 0 for little-endian, 1 for big-endian
- *Skein_Put64_LSB_First
- *Skein_Get64_LSB_First
- *Skein_Swap64
- *
- * If SKEIN_NEED_SWAP is defined at compile time, it is used here
- * along with the portable versions of Put64/Get64/Swap64, which
- * are slow in general.
- *
- * Otherwise, an "auto-detect" of endianness is attempted below.
- * If the default handling doesn't work well, the user may insert
- * platform-specific code instead (e.g., for big-endian CPUs).
- *
- */
-#define SKEIN_NEED_SWAP (0)
-/* below two prototype assume we are handed aligned data */
-#define Skein_Put64_LSB_First(dst08,src64,bCnt) memcpy(dst08,src64,bCnt)
-#define Skein_Get64_LSB_First(dst64,src08,wCnt) memcpy(dst64,src08,8*(wCnt))
-
-/*
- **
- * Provide any definitions still needed.
- **
- */
-#ifndef Skein_Swap64 /* swap for big-endian, nop for little-endian */
-#if SKEIN_NEED_SWAP
-#define Skein_Swap64(w64) \
- ( (( ((u64b_t)(w64)) & 0xFF) << 56) | \
-(u64b_t)(w64)) >> 8) & 0xFF) << 48) | \
-(u64b_t)(w64)) >>16) & 0xFF) << 40) | \
-(u64b_t)(w64)) >>24) & 0xFF) << 32) | \
-(u64b_t)(w64)) >>32) & 0xFF) << 24) | \
-(u64b_t)(w64)) >>40) & 0xFF) << 16) | \
-(u64b_t)(w64)) >>48) & 0xFF) << 8) | \
-(u64b_t)(w64)) >>56) & 0xFF) ) )
-#else
-#define Skein_Swap64(w64) (w64)
-#endif
-#endif /* ifndef Skein_Swap64 */
-
-
-#ifndef Skein_Put64_LSB_First
-voidSkein_Put64_LSB_First(u08b_t *dst,const u64b_t *src,size_t bCnt)
-#ifdef SKEIN_PORT_CODE /* instantiate the function code here? */
-{ /* this version is fully portable (big-endian or little-endian), but
slow */
-size_t n;
-
-for (n=0;n>3] >> (8*(n&7)));
-}
-#else
-;/* output only the function prototype */
-#endif
-#endif /* ifndef Skein_Put64_LSB_First */
-
-
-#ifndef Skein_Get64_LSB_First
-voidSkein_Get64_LSB_First(u64b_t *dst,const u08b_t *src,size_t wCnt)
-#ifdef SKEIN_PORT_CODE /* instanti
[PATCH V2 03/21] staging: crypto: skein: remove brg_*.h includes
Signed-off-by: Jason Cooper --- drivers/staging/skein/include/brg_endian.h | 148 - drivers/staging/skein/include/brg_types.h | 131 - drivers/staging/skein/include/skein_port.h | 6 +- 3 files changed, 2 insertions(+), 283 deletions(-) delete mode 100644 drivers/staging/skein/include/brg_endian.h delete mode 100644 drivers/staging/skein/include/brg_types.h diff --git a/drivers/staging/skein/include/brg_endian.h b/drivers/staging/skein/include/brg_endian.h deleted file mode 100644 index c03c7c5d1eb4.. --- a/drivers/staging/skein/include/brg_endian.h +++ /dev/null @@ -1,148 +0,0 @@ -/* - --- - Copyright (c) 2003, Dr Brian Gladman, Worcester, UK. All rights reserved. - - LICENSE TERMS - - The free distribution and use of this software in both source and binary - form is allowed (with or without changes) provided that: - - 1. distributions of this source code include the above copyright - notice, this list of conditions and the following disclaimer; - - 2. distributions in binary form include the above copyright - notice, this list of conditions and the following disclaimer - in the documentation and/or other associated materials; - - 3. the copyright holder's name is not used to endorse products - built using this software without specific written permission. - - ALTERNATIVELY, provided that this notice is retained in full, this product - may be distributed under the terms of the GNU General Public License (GPL), - in which case the provisions of the GPL apply INSTEAD OF those given above. - - DISCLAIMER - - This software is provided 'as is' with no explicit or implied warranties - in respect of its properties, including, but not limited to, correctness - and/or fitness for purpose. - --- - Issue 20/10/2006 -*/ - -#ifndef BRG_ENDIAN_H -#define BRG_ENDIAN_H - -#define IS_BIG_ENDIAN 4321 /* byte 0 is most significant (mc68k) */ -#define IS_LITTLE_ENDIAN 1234 /* byte 0 is least significant (i386) */ - -/* Include files where endian defines and byteswap functions may reside */ -#if defined( __FreeBSD__ ) || defined( __OpenBSD__ ) || defined( __NetBSD__ ) -# include -#elif defined( BSD ) && ( BSD >= 199103 ) || defined( __APPLE__ ) || \ - defined( __CYGWIN32__ ) || defined( __DJGPP__ ) || defined( __osf__ ) -# include -#elif defined( __linux__ ) || defined( __GNUC__ ) || defined( __GNU_LIBRARY__ ) -# if !defined( __MINGW32__ ) && !defined(AVR) -#include -#if !defined( __BEOS__ ) -# include -#endif -# endif -#endif - -/* Now attempt to set the define for platform byte order using any */ -/* of the four forms SYMBOL, _SYMBOL, __SYMBOL & __SYMBOL__, which */ -/* seem to encompass most endian symbol definitions */ - -#if defined( BIG_ENDIAN ) && defined( LITTLE_ENDIAN ) -# if defined( BYTE_ORDER ) && BYTE_ORDER == BIG_ENDIAN -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( BYTE_ORDER ) && BYTE_ORDER == LITTLE_ENDIAN -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( BIG_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( LITTLE_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -#if defined( _BIG_ENDIAN ) && defined( _LITTLE_ENDIAN ) -# if defined( _BYTE_ORDER ) && _BYTE_ORDER == _BIG_ENDIAN -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( _BYTE_ORDER ) && _BYTE_ORDER == _LITTLE_ENDIAN -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( _BIG_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( _LITTLE_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -#if defined( __BIG_ENDIAN ) && defined( __LITTLE_ENDIAN ) -# if defined( __BYTE_ORDER ) && __BYTE_ORDER == __BIG_ENDIAN -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( __BYTE_ORDER ) && __BYTE_ORDER == __LITTLE_ENDIAN -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( __BIG_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( __LITTLE_ENDIAN ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -#if defined( __BIG_ENDIAN__ ) && defined( __LITTLE_ENDIAN__ ) -# if defined( __BYTE_ORDER__ ) && __BYTE_ORDER__ == __BIG_ENDIAN__ -#define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -# elif defined( __BYTE_ORDER__ ) && __BYTE_ORDER__ == __LITTLE_ENDIAN__ -#define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -# endif -#elif defined( __BIG_ENDIAN__ ) -# define PLATFORM_BYTE_ORDER IS_BIG_ENDIAN -#elif defined( __LITTLE_ENDIAN__ ) -# define PLATFORM_BYTE_ORDER IS_LITTLE_ENDIAN -#endif - -/* if the platform byte order could not be determined, then
[PATCH V2 00/21] staging: add skein/threefish crypto algos
Greg, all,
Changes from RFC:
- dropped scripts/objdiff patch to be submitted separately
- rebased onto staging-next and resolved conflicts
-- updated original text to reflect the above --
Attached is a series I've sat on for the past month and a half.
I'm hoping that by posting it in it's incomplete state, it will either a)
motivate me to finish hooking into the crypto API, or b) motivate someone else
to pitch in. ;-)
>From patch 2, all commits build successfully. In addition, using the script
I've submitted separately (objdiff), I can confirm that no object code was
harmed in this process.
I'm under no time crunch with this, and I add to it as I find time. If Greg
wants to take it for v3.15, great. Otherwise is fine as well.
Barring a few false-positives, this series makes the code checkpatch-clean, but
it is not ready for mainline as yet. In particular, I really don't like the
adhoc macro definitions, nor the camelCase.
The plan is to get skein and threefish registered into the crypto API, build as
modules, and then move it to crypto/.
thx,
Jason.
Jason Cooper (21):
staging: crypto: skein: import code from Skein3Fish.git
staging: crypto: skein: allow building statically
staging: crypto: skein: remove brg_*.h includes
staging: crypto: skein: remove skein_port.h
staging: crypto: skein: remove __cplusplus and an unneeded stddef.h
staging: crypto: skein: remove unneeded typedefs
staging: crypto: skein: remove all typedef {struct,enum}
staging: crypto: skein: use u8, u64 vice uint*_t
staging: crypto: skein: fixup pointer whitespace
staging: crypto: skein: cleanup whitespace around operators/punc.
staging: crypto: skein: dos2unix, remove executable perms
staging: crypto: skein: fix leading whitespace
staging: crypto: skein: remove trailing whitespace
staging: crypto: skein: cleanup >80 character lines
staging: crypto: skein: fix do/while brace formatting
staging: crypto: skein: fix brace placement errors
staging: crypto: skein: wrap multi-line macros in do-while loops
staging: crypto: skein: remove externs from .c files
staging: crypto: skein: remove braces from single-statement block
staging: crypto: skein: remove unnecessary line continuation
staging: crypto: skein: add TODO file
drivers/staging/Kconfig |2 +
drivers/staging/Makefile |1 +
drivers/staging/skein/Kconfig| 32 +
drivers/staging/skein/Makefile | 13 +
drivers/staging/skein/TODO | 11 +
drivers/staging/skein/include/skein.h| 344 ++
drivers/staging/skein/include/skeinApi.h | 230 ++
drivers/staging/skein/include/skein_block.h | 22 +
drivers/staging/skein/include/skein_iv.h | 186 +
drivers/staging/skein/include/threefishApi.h | 164 +
drivers/staging/skein/skein.c| 880 +
drivers/staging/skein/skeinApi.c | 237 ++
drivers/staging/skein/skeinBlockNo3F.c | 175 +
drivers/staging/skein/skein_block.c | 770
drivers/staging/skein/threefish1024Block.c | 4900 ++
drivers/staging/skein/threefish256Block.c| 1137 ++
drivers/staging/skein/threefish512Block.c| 2223
drivers/staging/skein/threefishApi.c | 79 +
18 files changed, 11406 insertions(+)
create mode 100644 drivers/staging/skein/Kconfig
create mode 100644 drivers/staging/skein/Makefile
create mode 100644 drivers/staging/skein/TODO
create mode 100644 drivers/staging/skein/include/skein.h
create mode 100644 drivers/staging/skein/include/skeinApi.h
create mode 100644 drivers/staging/skein/include/skein_block.h
create mode 100644 drivers/staging/skein/include/skein_iv.h
create mode 100644 drivers/staging/skein/include/threefishApi.h
create mode 100644 drivers/staging/skein/skein.c
create mode 100644 drivers/staging/skein/skeinApi.c
create mode 100644 drivers/staging/skein/skeinBlockNo3F.c
create mode 100644 drivers/staging/skein/skein_block.c
create mode 100644 drivers/staging/skein/threefish1024Block.c
create mode 100644 drivers/staging/skein/threefish256Block.c
create mode 100644 drivers/staging/skein/threefish512Block.c
create mode 100644 drivers/staging/skein/threefishApi.c
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2 13/21] staging: crypto: skein: remove trailing whitespace
Signed-off-by: Jason Cooper
---
drivers/staging/skein/include/skein.h| 16 +-
drivers/staging/skein/include/skeinApi.h | 44 ++--
drivers/staging/skein/include/threefishApi.h | 40 -
drivers/staging/skein/skeinBlockNo3F.c | 6 ++--
drivers/staging/skein/skein_block.c | 20 ++---
5 files changed, 63 insertions(+), 63 deletions(-)
diff --git a/drivers/staging/skein/include/skein.h
b/drivers/staging/skein/include/skein.h
index 906bcee41c39..dd9a210cf5dd 100644
--- a/drivers/staging/skein/include/skein.h
+++ b/drivers/staging/skein/include/skein.h
@@ -9,7 +9,7 @@
** This algorithm and source code is released to the public domain.
**
***
-**
+**
** The following compile-time switches may be defined to control some
** tradeoffs between speed, code size, error checking, and security.
**
@@ -20,8 +20,8 @@
**[default: no callouts (no overhead)]
**
** SKEIN_ERR_CHECK-- how error checking is handled inside Skein
-**code. If not defined, most error checking
-**is disabled (for performance). Otherwise,
+**code. If not defined, most error checking
+**is disabled (for performance). Otherwise,
**the switch value is interpreted as:
**0: use assert() to flag errors
**1: return SKEIN_FAIL to flag errors
@@ -109,12 +109,12 @@ int Skein1024_Final(struct skein1024_ctx *ctx, u8
*hashVal);
** After an InitExt() call, just use Update/Final calls as with Init().
**
** Notes: Same parameters as _Init() calls, plus treeInfo/key/keyBytes.
-** When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL,
+** When keyBytes == 0 and treeInfo == SKEIN_SEQUENTIAL,
** the results of InitExt() are identical to calling Init().
** The function Init() may be called once to "precompute" the IV for
** a given hashBitLen value, then by saving a copy of the context
** the IV computation may be avoided in later calls.
-** Similarly, the function InitExt() may be called once per MAC key
+** Similarly, the function InitExt() may be called once per MAC key
** to precompute the MAC IV, then a copy of the context saved and
** reused for each new MAC computation.
**/
@@ -142,7 +142,7 @@ int Skein1024_Output(struct skein1024_ctx *ctx, u8
*hashVal);
/*
** "Internal" Skein definitions
-**-- not needed for sequential hashing API, but will be
+**-- not needed for sequential hashing API, but will be
** helpful for other uses of Skein (e.g., tree hash mode).
**-- included here so that they can be shared between
** reference and optimized code.
@@ -269,8 +269,8 @@ int Skein1024_Output(struct skein1024_ctx *ctx, u8
*hashVal);
/*
** Skein block function constants (shared across Ref and Opt code)
**/
-enum
- {
+enum
+ {
/* Skein_256 round rotation constants */
R_256_0_0 = 14, R_256_0_1 = 16,
R_256_1_0 = 52, R_256_1_1 = 57,
diff --git a/drivers/staging/skein/include/skeinApi.h
b/drivers/staging/skein/include/skeinApi.h
index 0d7d59eff460..ace931a67c23 100644
--- a/drivers/staging/skein/include/skeinApi.h
+++ b/drivers/staging/skein/include/skeinApi.h
@@ -36,46 +36,46 @@ OTHER DEALINGS IN THE SOFTWARE.
* of Skein. The design and the way to use the functions follow the openSSL
* design but at the same time take care of some Skein specific behaviour
* and possibilities.
- *
+ *
* The functions enable applications to create a normal Skein hashes and
* message authentication codes (MAC).
- *
+ *
* Using these functions is simple and straight forward:
- *
+ *
* @code
- *
+ *
* #include
- *
+ *
* ...
* struct skein_ctx ctx; // a Skein hash or MAC context
- *
+ *
* // prepare context, here for a Skein with a state size of 512 bits.
* skeinCtxPrepare(&ctx, Skein512);
- *
+ *
* // Initialize the context to set the requested hash length in bits
* // here request a output hash size of 31 bits (Skein supports variable
* // output sizes even very strange sizes)
* skeinInit(&ctx, 31);
- *
+ *
* // Now update Skein with any number of message bits. A function that
* // takes a number of bytes is also available.
* skeinUpdateBits(&ctx, message, msgLength);
- *
+ *
* // Now get the result of the Skein hash. The output buffer must be
* // large enough to hold the re
[PATCH V2 15/21] staging: crypto: skein: fix do/while brace formatting
Signed-off-by: Jason Cooper --- drivers/staging/skein/skein_block.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/staging/skein/skein_block.c b/drivers/staging/skein/skein_block.c index 780b4936f783..6e0f4a21aae3 100644 --- a/drivers/staging/skein/skein_block.c +++ b/drivers/staging/skein/skein_block.c @@ -215,8 +215,7 @@ void Skein_256_Process_Block(struct skein_256_ctx *ctx, const u8 *blkPtr, Skein_Show_Round(BLK_BITS, &ctx->h, SKEIN_RND_FEED_FWD, ctx->X); ts[1] &= ~SKEIN_T1_FLAG_FIRST; - } - while (--blkCnt); + } while (--blkCnt); ctx->h.T[0] = ts[0]; ctx->h.T[1] = ts[1]; } @@ -434,8 +433,7 @@ void Skein_512_Process_Block(struct skein_512_ctx *ctx, const u8 *blkPtr, Skein_Show_Round(BLK_BITS, &ctx->h, SKEIN_RND_FEED_FWD, ctx->X); ts[1] &= ~SKEIN_T1_FLAG_FIRST; - } - while (--blkCnt); + } while (--blkCnt); ctx->h.T[0] = ts[0]; ctx->h.T[1] = ts[1]; } @@ -717,8 +715,7 @@ void Skein1024_Process_Block(struct skein1024_ctx *ctx, const u8 *blkPtr, \ ts[1] &= ~SKEIN_T1_FLAG_FIRST; blkPtr += SKEIN1024_BLOCK_BYTES; - } - while (--blkCnt); + } while (--blkCnt); ctx->h.T[0] = ts[0]; ctx->h.T[1] = ts[1]; } -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
